How to generate graphs for analyzing the testing process in test director?

The graphs that are created during the test director testing process let you keep a track of the progress of the test plan, test runs, defect tracking, requirements and so on. Such graphs can be generated at any point of time during the process and also from any of the test director modules. The graphs created by the test director are based up on the default setting however they can be customized by the user.

A project consists of data of different types. The graphs that you create using the test director can help you a big deal in analyzing the relationships between these different types of data. Each of the modules of the test director comes with a number of graph generating options. After you are done with generating the graph, you can customize its various properties so it comes out exactly as per your specifications and displays the information you want and in the way you want. 

Now we shall mention the steps following which you can generate a defects graph which will show the summary of the defects by status as well as priority levels. 

Steps for generating Defects Graph

Follow the steps:

1. Click on the defects tab to turn on the defects module of the test director. The defects module will be displayed in the defects grid.
2. Now for choosing a graph go to analysis menu, then graphs, then summary, then group by status option. This will open up a defects summary graph. This graph is grouped by status by default.
3. Next you need to clear the default filter. Clicking on the filter button will do the task for you. The filter dialog box will open up. You will see that the detected by field is set to the current user name by default. Here, click the clear button and the applied filter will be removed by the test director.
4. If you want to define a filter for viewing the defects with high to urgent priority then click the filter condition box for the priority field in the filter dialog box. Clicking on the browse button will open up the select filter condition dialog box’. Then select the required logical expression in the right pane and in the left pan select the level. Click OK to save the settings and close this dialog box.
5. Next for defining a filter for viewing the defects that are not closed click the filter condition box for the status field. Again open the select filter condition dialog box by clicking on the browse button. Select the ‘not’ logical expression and select closed in the left pane. Click OK to close this box and once again click OK to close the filter dialog box.
6. For setting the X axis of the graph select priority on the right side of the window for viewing the number of defects according to priority.
7. Clicking on the refresh button will refresh the graph i.e., a new graph will be displayed.
8. For displaying additional defect details click on a bar segment of the graph. A drill down results dialog box will display the defects related to that bar segment. Close this dialog box by clicking on the close button.
9. There are various graph views available such as the data grid view and pie chart. Clicking on the corresponding options will display the graph as a pie chart, grid and so on.
10. Close the graph and click on the back button to go back to the defects module. 

What is the relationship between a developer and a tester? Who is responsible for a good software quality?

Success of a project depends on the development team. The working efficiency of the team depends on its individual members and of course on the quality of the relationships that they are maintaining. By a good relation among the team members we mean the team spirit, comradeship and communication between them. All these qualities give rise to a good team.

In a software development cycle the relationship between a program developer and tester is very crucial. Since the two processes i.e., the development of the software system or application and its testing are inter- dependent on each other.

Successful completion of both these processes is crucial to any software development cycle.

POSITION OF A DEVELOPER?

The software developers fall under the following three categories:
1. Computer programmers
2. Software applications developers and
3. Software systems developers

- Software or a program developer as we know is the one who is concerned with the development of a software system or application.
- He/ she takes care of all the phases of the software development cycle.
- His/ her work includes research, planning development, designing and developing the software system or application.
- Sometimes it may also include the facets of testing the software.
- Program developers are at the center of the whole development process and are involved with management of the software project and its programming.

POSITION OF A TESTER
- He/ she is the person involved with the testing facets of a software system or application.
- Their job is to provide the details about the quality of the software system or application to the stake holders.
- He/ she is responsible for executing the software program with the intention of discovering bugs and errors in it.

RELATIONSHIP BETWEEN DEVELOPER AND TESTER
- The relationship between a tester and a developer should be excellent.
- It is obvious that both the software developers and the software testers work for improving the quality of the software.
- Quality of software includes the design of the software system, actual core implementation, requirements, gap analysis, specifications analysis, development of prototypes, feasibility analysis, documentation, testing, software pre release and post release activities and not to forget the maintenance of the entire software system or application.

But, it is often seen that the relationships between the developers and testers are not so good. This is probably because of the roles of these two.

- Their work often clashes.
- It is obvious that something in the process of development will certainly have bugs.
- It becomes important to decide if this bug is to be left or it is to be fixed. - At this point usually the relationship between the two worsens.
- After all, it is the duty of the testers to identify the bugs in the program.

Matters like these should not hamper the relationship between the developers and the testers as it is crucial for the development.

- Team work and better individual understanding is the best solution for this kind of problem.
- Maintain the quality of software is not just the responsibility of a software tester or developer.
- It is responsibility of the whole development team.
- Therefore every stake holder holds the responsibility for the quality of the software product from the programmer to the customer.

Testers are usually held responsible for the quality sine they are the one who are responsible for finding out the weaknesses of the software and the testers accuse the developers for putting up a bad code. This puts a bad impact on the whole development team since the team spirit is lost.

Does Quality Assurance remove the need for quality control?

Quality assurance and quality control are two of the most confused concepts. But let me state here that quality assurance and quality control are two different concepts.

"Software quality assurance is means of ensuring that proper processes and methods are being used in the development of software systems or application to ensure quality." There are many methods that are employed for quality assurance.

Now coming to the concept of quality control, it is a means used by the entities for the process of reviewing the quality of all the aspects of a software system or application under development.

FACTORS ON WHICH QUALITY CONTROL IS FOCUSED
Quality control is basically focused up on the following 3 factors:

1. Management elements like:
(a) record identification
(b) performance
(c) controls
(d) involved processes
(e) job management
(f) criteria for integration

2. Soft elements like:
(a) quality relationships among the team members
(b) confidence of the individual
(c) culture of the organization
(d) team spirit
(e) personnel integrity
(f) motivation

3. Competency elements like:
(a) qualifications of the workers
(b) skills
(c) experience
(d) knowledge

A typical quality control process involves the inspection of the software artifact before it is made available to the public. This process involves search for the bugs and errors as well.

WHAT ASPECTS DOES QUALITY ASSURANCE CHECK?

- System requirements
- Coding
- Code reviews
- Software design
- Source code control
- Process management
- Testing
- Configuration management
- Source code control
- Software release management

So we see that since there is a considerable difference between the two things, it means that quality assurance does not remove the need for quality control.

But, here another question arises :

“if quality assurance covers every aspect of the software development, then why do we need to look up the quality control?

- Quality control is needed even after quality assurance has been performed.
- In quality assurance, all the strategies, checklists, standards that are used in the software development cycle are defined whereas, in quality control all the processes checked by the quality assurance are implemented in order to ensure that the developed software system or application is of high quality.
- Quality control makes sure that the software product meets the expectations of the users.
- Quality control can be defined as a means to measure quality and quality assurance is a means to assure quality.
- The results obtained from quality control assessment can be utilized to make quality assurance processes better.
- Quality assurance and quality control together form a very powerful methodology to ensure that the software product is of very high quality and satisfies all the expectations of the targeted users.
- Quality control is a product oriented process whereas quality assurance is a process oriented process.
- The team of quality assurance ensures that the governing principles for software making are rightly implemented and the team of quality control is involved with the process of determining the efficacy levels of those principles and guidelines.

From the above points we can conclude that the two terms though sound same in meaning are not same in the least bit.

People often confuse between these two are ambiguous terms and have been different meanings. When we use both of these processes, quality is guaranteed. All the technologies and processes must be checked for their quality before starting working on the project by quality assurance and quality control processes.

Define the tracking progress for an object oriented project?

For a object oriented project, tracking becomes really difficult and establishing some meaningful milestones is also a difficult task as there are many things that are happening at once. For tracking an object oriented project, following milestones are considered to be completed when the below mentioned criteria are met:

Milestone for Object Oriented Analysis is considered completed when the following conditions are satisfied :
- Every class is defined and reviewed.
- Every class hierarchy are defined and reviewed.
- Class attributes are defined and reviewed.
- Class operations are defined and reviewed.
- Classes that are reused are noted.
- The relationships among classes are defined and reviewed.
- Behavioral model is created and reviewed.

Milestone for Object Oriented Design is considered completed when the following conditions are satisfied :
- Subsystems are defined and reviewed.
- Classes are allocated to sub systems.
- Classes allocated are reviewed.
- Tasks are allocated.
- Task allocated are reviewed.
- Design classes are created.
- These design classes are reviewed.
- Responsibilities are identified.
- Collaborations are identified.

Milestone for Object Oriented Programming is considered completed when the following conditions are satisfied :
- Classes from design model are implemented in code.
- Extracted classes are implemented.
- A prototype is built.

Milestone for Object Oriented Testing is considered completed when the following conditions are satisfied :
Debugging and testing occur in concert with one another. The status of debugging is often assessed by considering the type and number of bugs.
- The correctness of object oriented analysis and design model is reviewed.
- The completeness of object oriented analysis and design model is reviewed.
- Collaboration between class and responsibility is developed and reviewed.
- Test cases designed are conducted for each class.
- Class level tests are conducted for each class.
- Cluster testing is completed and classes are integrated.
- Tests related to system testing are established and completed.

Each of the milestone is revisited as object oriented process model is iterative in nature.

Project Scheduling - Relationship between people and effort

For a small project, requirements analysis, performing design, code generation and test conduction can be done by a single person but as the size of the project increases, more people get added. Adding people later in the project often has a disruptive effect on the project causing schedules to slip even further. If more people are added to a late project, be sure that you have assigned them work that is highly compartmentalized.

The people who are added later in the project should know the system properly. In addition to the time that it takes to learn the system, it also increases the number and complexity of communication paths. Every communication path requires additional effort and time.

Project schedules are elastic. It is possible to compress or extend a desired project completion date to some extent. If delivery can be delayed, the PNR curve indicates that project costs can be reduced substantially. As the project deadline becomes tighter and tighter, you reach a point at which the work cannot be completed on schedule, regardless of the number of people doing the work. The reality should be faced and a new delivery date should be defined.

Effort should also be distributed across the software process workflow. Recommended effort distribution is referred as 40-20-40 rule. Front end analysis and design and back end testing are allocated 40% of all effort while 20% of effort is allocated to coding. The characteristics of each project must dictate the distribution of effort. Requirement analysis may comprise 10-25 percent of project effort. Effort on analysis or prototyping should increase in direct proportion with project size and complexity.

What are different object oriented metrics in software measurement?

Object Oriented Metrics

Lines of code and Function point metrics can be used for object oriented projects but they do not provide enough granularity for schedule. Some object oriented metrics are as follows:

- Number of scenario scripts
A scenario script describes the interaction between user and application. It is directly related to application size and number of test cases developed to exercise the system.

- Number of key classes
Key classes are independent components. The number of key classes is the indication of the amount of effort that is required to develop the software and it also indicates the potential amount of reuse applied during system development. The key classes are directly related to problem domain.

- Number of support classes
Support classes are not directly related to problem domain. Support classes can be developed for key class. Number of support classes indicates amount of effort required to develop software and potential amount of reuse to be applied.

- Number of subsystems
Subsystem is gathering of classes supporting a function visible to the end user. A schedule is laid out in which work on subsystem is partitioned.

- Average number of support classes per key class
Estimation becomes easy and simplified if average number of support classes per key class is known.

As database grows, relationships between object oriented measures and project measures provides metrics for project estimation.

What is meant by Relationship-Navigation Analysis (RNA)?

Relationship navigation analysis (RNA) is a series of analysis steps to identify relationships among the elements that are left uncovered during the creation of the analysis model. There are five steps that constitutes the RNA approach:
- Stakeholder analysis establishes stakeholder hierarchy and identifies various user categories.
- Element analysis identifies content objects and functional elements that are in interest to end uses.
- Relationship analysis identifies the relationship among web application elements.
- Navigation analysis identifies the accessibility of elements by users.
- Evaluation analysis identifies the cost and benefit included.

RELATIONSHIP ANALYSIS
To assess analysis model elements to understand relationships among them, some guidelines are:
- the attributes identified for element.
- whether description about element exists and where?
- is element composed of other smaller elements?
- is element a member of larger collection of elements?
- does analysis class describe the element?
- in using the element, what are the pre and post conditions.
- is the element used in specific ordering of other elements?
- does the element appear in the same place?

The answers to above questions helps the web engineer to position the element in question within the web application and to establish relationships among elements.

NAVIGATION ANALYSIS
After relationship are identified among elements, the web engineer defines how the user category navigates from one element to another. The questions that would clear the navigation requirements are:
- how are navigation errors handled?
- should certain elements be easier to reach?
- should group element navigation be given priority over specific element navigation?
- should links be used for navigation?
- should there be a navigation log for users?
- should a navigation map or menu be established?
- for which user category an optimal navigation be designed?

How to assess alternative architectural designs?

There are many architectural alternatives that need to be assessed. There are different ways to assess the design:

Trade off Analysis Method
It establishes an iterative evaluation process for software architectures. It involves six steps:
- All the scenarios are collected.
- Requirements, constraints and environment description are elicited.
- Architectural styles or patterns chosen to address scenarios and requirements are described.
- Quality attributes are evaluated.
- The sensitivity of quality attributes to architectural attributes are identified.
- Critique candidate architectures using sensitivity analysis.

Architectural Complexity
In architectural complexity, the dependencies between the components are assessed within the architecture. Dependencies can be divided into:
- Sharing dependencies represent dependence relationship among consumers or producers.
- Flow dependencies represent dependence relationships between producers and consumers of resources.
- Constrained dependencies represent constraints on the flow of control among set of activities.

Architectural Description Languages
Architectural description language provides a semantic and syntax for describing a software architecture. It is a set of tools and notation that allows the design to be represented in an unambiguous and understandable fashion.

Introduction to Pattern-based design in software design?

Pattern based design is a technique that reuses the design elements. Each architectural pattern, design pattern, or idiom is cataloged, thoroughly documented and carefully considered as it is assessed for inclusion in a specific application.

A description of design pattern may consider a set of design forces. Design forces are those characteristics of the problem and attributes of the solution that constrain the way in which the design is developed. These design forces also describe the environment and conditions that must exist to make design pattern applicable.

Types of design patterns available are:
- Architectural patterns
The overall structure of software, relationship among subsystems and software components and rules are defined for relationship among elements of architecture.
- Design patterns
It addresses a specific element of design to solve some design problem, relationships among components or mechanisms for good communication among components.
- Idioms
These are language specific patterns. They implement the algorithmic element of a component. They can act as a specific interface protocol or a mechanism for communication among components.

What are the different data modeling concepts?

Data model is a conceptual representation of data structures. The data structures consist of data objects, relationship between data objects and rules that govern these operations. Often, analysis modeling begins with data modeling.
The inputs of data model comes from the planning and analysis stage. There are two outputs of the data model. First is an entity relationship diagram and second is a data document. The goal of the data model is to make sure that the all data objects required by the database are completely and accurately represented.

The different concepts of data modeling are:

- Data Objects are a representation of any composite information that is processed by software. A data object can be an external entity, thing, occurrence, event, role, an organizational unit, place or a structure. The description of the data object includes data object and its attributes. A data object contains only data.

- Data Attributes name a data object, describe its characteristics and sometimes make reference to another object. One or more attributes must be identified as a key which acts as an identifier.

- Relationships indicate the manner in which data objects are connected to one another.

- Cardinality of a relationship is the actual number of related occurences for each of the two entities. It defines the maximum number of objects participating in relationship. It does not indicate whether a data object should participate in relationship or not.

- Modality of a relationship can be 0 or 1. It is 1 if an occurrence of relationship is must. It is 0 if an occurrence of relationship is optional.

What are different characteristics of design patterns?

A design pattern is a general repeatable solution to a commonly occurring problem in software design.
- It is a proven solution to problems that keep recurring.
- They are reusable solutions to common problems.
- Design patterns are not frameworks.
- Design patterns are more abstract than frameworks.
- Design pattern cannot be directly implemented.
- Design patterns are more primitive than a framework.
- A design pattern cannot incorporate a framework.
- Patterns may be documented using one of several alternative templates.
- Design patterns can speed up the development process by providing tested, proven development paradigms.
- Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
- Patterns allow developers to communicate using well-known, well understood names for software interactions.

A pattern description includes the following elements:
- name of the pattern should be meaningful.
- context of the pattern represents the circumstances or preconditions.
- Problem description that pattern addresses should be provided.
- Solution is a description of the static and dynamic relationships amongthe components of the pattern.
The use of design patterns requires careful analysis of the problem that is to be
addressed and the context in which it occurs.

What is a System? What are general principles of system?

System is an:
- integrated set of inter-operable elements;
- it consists of group of entities or components;
- interacting together to form specific inter-relationships;
- organized by means of structure;
- working together to achieve a common goal.

In defining the system boundaries,a software engineer discovers the following:
- entities or group of entities that are related and organized in some way within the system, either they provide input, do activities or receive output;
- activities or actions that must be performed by the entities or group of entities in order to achieve the purpose of the system;
- a list of inputs;
- a list of outputs.
Entities that are involved in this system are the applicant, club staff and coach.

General Principles of Systems
- The more specialized a system, the less it is able to adapt to different circumstances.
- The larger the system is, the more resources must be devoted to its everyday maintenance
- Systems are always part of larger systems, and they can always bepartitioned into smaller systems

There are two types of systems, namely, man-made systems and automated systems. Man made systems will always have areas for correctness and improvements. These areas for correctness and improvements can be addressed by automated systems. Automated systems consists of computer hardware, computer software, people, procedures, data and information and the connectivity that allows the connection of one computer systemwith another computer system.

Introduction to Architecture Design - WebApp Architecture

The design process for identifying the subsystems making up a system and the
framework for sub-system control and communication is architectural design. An architectural design is :
- early stage in system design process.
- conducted in parallel with other design activities.
- establishes a link among goals established for web application, content, users visiting it, and the navigation criterion.
- identifying system components and their communications.

A web application is an application that is accessed over a network such as the Internet or an intranet.Web application architecture provides an infrastructure that enables a web based system to achieve its business objectives.
The Model View Controller (MVC) architecture decouples the user interface from web application functionality and information content.

The MVC design pattern divides applications into three components:
- The Model maintains the state and data that the application represents.
- The View allows the display of information about the model to the user. It contains all interface specific functions.
- The Controller allows the user to manipulate the application. It coordinates the flow of data between model and view.

Web application architecture is defined within the context of the development environment in which the application is to be implemented.

Introduction to Architecture Design - Content Architecture

The design process for identifying the subsystems making up a system and the
framework for sub-system control and communication is architectural design. An architectural design is :
- early stage in system design process.
- conducted in parallel with other design activities.
- establishes a link among goals established for web application, content, users visiting it, and the navigation criterion.
- identifying system components and their communications.

Content architecture emphasize on the fact how are the content objects structured for presentation and navigation. It focuses on overall hypermedia structure of the web application. It focuses on
- identifying links and relationships among content and documents.
- defining the structure of content.
- specifying consistent document requirements and attributes.

The design can choose from four different content structures:
- Linear Structures : a predictable sequence of interactions is common. The sequence of content presentation is predefined and linear in nature.
- Grid Structures : applied when the web application content can be organized categorically in two dimensions. This web application architecture is useful when highly regular content is encountered.
- Hierarchical Structures : it is the most common web application architecture. It is designed in a manner that enables flow of control horizontally, across vertical branches of the structure.
- Networked Structures : architectural components are designed so that they may pass control to virtually every other component in the system. It provides navigational flexibility but at the same time it can be a bit confusing to a user.
- Composite Structures : the overall architecture of the web application may be hierarchical, but part of the a structure may exhibit linear characteristics, while another part of the architecture may be networked.

Introduction to Content Design - Content Objects and Content Design Issues

Content design focuses on two different design issues, each addressed by individuals with different skill sets. In content design :
- a design representation is developed for content objects and
- mechanisms are represented that are required to initiate their relationships to one another.
- representation of information within a specific content object is concerned.

It is design activity that is conducted by copywriters, graphic designers, and others who generate the content to be used within a web application.

A content object is closely aligned with a data object. A content object has attributes that include content specific information and implementation specific attributes that are specified as part of design.
UML association and aggregation may be used to represent relationships between content objects.

Once all the content objects are modeled, the information that each object is to deliver must be authored and then formatted to best meet the customer's needs. Content authoring is the job of specialists who design the content object by providing an outline of information to be delivered and an indication of the types of generic content objects that will be used to deliver the information.

As content objects are designed, they are chunked to form web application pages. The number of content objects incorporated into a single page is a function of user needs, constraints imposed by download speed of internet connections, and restrictions imposed by the amount of scrolling that the user will tolerate.

Methods of black box testing - Graph based testing methods and Equivalence Partitioning

Black Box Testing is testing without knowledge of the internal workings of the item being tested. There are four black box testing methods:

Graph-based Testing Methods
Basic idea: A "cause" is an input condition, and an "effect" is a specific sequence of computations to be performed. A cause-effect graph is basically a directed graph that describes the logical combinations of causes and their relationship to the effects to be produced.
- Black-box methods based on the nature of the relationships (links) among the program objects (nodes), test cases are designed to traverse the entire graph.
- A graph is created between the objects and the relationships.
- From the graph, each object relationship is identified and test cases written accordingly to discover the errors.

Equivalence Partitioning
This method divides the input domain of a program into classes of data from which test cases can be derived. It reduces the number of test cases. The guidelines of Equivalence Partitioning are :
- If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
- If an input condition requires a specific value, then one valid and two invalid equivalence classes are defined.
- If an input condition specifies a member of a set, then one valid and one invalid equivalence class are defined.
- If an input condition is boolean, then one valid and one invalid equivalence class are defined.

Relationships And Relationship Sets

A relationship is an association between several entities.
A relationship set is a set of relationships of the same type.
A relationship type R among n entity types E1, E2,....., En defines a set of associations or a relationship set among entities from these types.
In ER diagrams, relationship types are displayed as diamond-shaped boxes, which are connected by straight lines to the rectangular boxes representing the participating entity types. The relationship name is displayed in the diamond-shaped box.

RELATIONSHIP DEGREE : The degree of a relationship type is the number of participating entity types. A relationship type of degree two is called binary, and one with degree three is called ternary.




ROLE NAMES and RECURSIVE RELATIONSHIPS :
Role names signifies the role that a participating entity from the entity type plays in each relationship instance, and helps to explain what the relationship means.
Role names are not necessary in relationship types where all the participating entity types are distinct, since each entity type name can be used as a role name. However, in some cases, the same entity type participates more than once in a relationship type in different roles. In such cases the role name becomes essential for distinguishing the meaning of each participation. Such relationships are called recursive relationships.


MAPPING CONSTRAINTS :
An E-R scheme may define certain constraints to which the contents of a database must conform.
* Mapping Cardinality : It expresses the number of entities to which another entity can be associated via a relationship. For binary relationship sets between entity sets A and B, the mapping cardinality must be one of:
1. One-to-one: An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A.
2. One-to-many: An entity in A is associated with any number in B. An entity in B is associated with at most one entity in A.
3. Many-to-one: An entity in A is associated with at most one entity in B. An entity in B is associated with any number in A.
4. Many-to-many: Entities in A and B are associated with any number from each other.
The appropriate mapping cardinality for a particular relationship set depends on the real world being modeled.
* Existence Dependencies: if the existence of entity X depends on the existence of entity Y, then X is said to be existence dependent on Y. (Or we say that Y is the dominant entity and X is the subordinate entity.)
For example,
o Consider account and transaction entity sets, and a relationship log between them.
o This is one-to-many from account to transaction.
o If an account entity is deleted, its associated transaction entities must also be deleted.
o Thus account is dominant and transaction is subordinate.