What are the four phases of TestDirector ?

TestDirector use can be divided into four phases:
- Test Requirements Management
Requirements Manager is used to link the requirements with the tests to be carried out. Each requirement in the SRS has to be tested at least once. In SRS, the functional and performance requirements are specified. Functional requirements are generated from use-case scenarios. Performance requirements are dependent on the application.
- Test Planning
In test planning, the QA manager does a detailed planning and addresses the following issues:
- Hardware and software platforms.
- Various tests to be formed.
- Time schedule to conduct the tests.
- Roles and responsibility of the persons associated with the project.
- Procedure for running the test.
- Various test cases to be generated.
- Procedure for tracking the progress of testing.
- Documents to be generated during testing process.
- Criteria for completion of testing.
Test design is done during test planning phase which involves defining the sequence of steps to execute a test in manual testing. The test plan is communicated to all the test engineers and also the development team.
- Test Execution
The actual testing is carried out based on the test cases generated, either manually or automatically. In case of automated testing, the test scheduling is done as per plan. A history of all test runs is maintained and audit trail, to trace the history of tests and test runs, is also maintained. Test sets are created. A test set is a set of test cases. In addition execution logic is also set. The logic specifies what to do when a test fails in a series of tests.
- Test Results Analysis
In this phase, test results are analyzed i.e. which tests passed and which failed. For the tests that failed, an analysis is carried out as to why they failed. Bug is classified based on severity. A simple way of classification is critical, major, minor. A more detailed way of classification is:
- Cosmetic or GUI related.
- Inconsistent performance of application.
- Loss of functionality.
- System crash.
- Loss of data.
- Security Violation.
The bug report is stored in a database. The privileges to read, write, and update the database need to be decided by the QA manager. Based on the bug tracking and analysis tools, QA manager and the project manager can take the decision whether the software can be released to the customer or still more testing is required.

Requirements Management (REQM) Process Area in CMMi

The purpose of Requirements Management (REQM) is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products. It is an Engineering process area at Maturity Level 2.
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes.
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes.

REQM vs.RD

- REQM is about managing the set of requirements and keeping it consistent with the project’s plans whereas RD is about developing the requirements in a systematic way.
- REQM is a Maturity Level 2 process area whereas RD is a Maturity Level 3 process area.

Specific Practices by Goal

SG 1 Manage Requirements
The project maintains a current and approved set of requirements over the life of the project by managing all changes to the requirements, maintaining the relationships among the requirements, the project plans, and the work products, identifying inconsistencies among the requirements, the project plans, and the work products and taking corrective action.
- SP 1.1 Obtain an Understanding of Requirements.
The intent of this SP is to establish a criteria for the project to identify appropriate requirements providers, criteria for the evaluationand acceptance of requirements, and ensure through an analysis or reviewprocess that the established criteria are met.
- SP 1.2 Obtain Commitment to Requirements.
Once the understanding of the requirement is established through the SP1.1, this SP deals with agreements and commitmentsamong those who have to carry out the activities necessary to implement the requirements.
- SP 1.3 Manage Requirements Changes.
Once commitments to the requirements are established and plans have been made. The project will transform from planning mode to execution mode. During the project execution phase, changes to requirements may occur for a variety of reasons. As needs change and as work proceeds, additional requirements are derived and changes may have to be made to the existing requirements.
- SP 1.4 Maintain Bidirectional Traceability of Requirements.
he intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.
- SP 1.5 Identify Inconsistencies between Project Work and Requirements.
This SP focuses on maintaining consistency between requirements and project plans. I.e. the project plan should be revised, if changes to the requirements are identified to be impacting the schedule.

In a product development cycle, how to get engineering and product management on the same page

As mentioned in the previous post, one of the biggest problems in a product development cycle is the objective of ensuring that the engineering teams and product management are in agreement about the resource commitment. Product Management talks about getting new features in place, while engineering has to content with having to dedicate resources to efforts for handling infrastructural and legacy tasks.
What are some of the tasks that an engineering team has to do which are not related to new feature work:
1. Test features from earlier versions and fix issues in these
2. Incorporate new components - you could be incorporating common components (and once you are building a product, there are many features that can be done by utilizing common components such as disc burning engines, installer technologies such as MSI, Installshield, Visual Studio etc); over a period of time, such components need to be upgraded and there will need to be more testing required
3. Spending dedicated time to improve the quality. Companies with large products such as Microsoft, Apple, Adobe, etc defer a number of bugs in their products. Some of these bugs are deferred since they are not critical, and there is a need to release the products. However, over a period of time, it may turn out that the overall impact of these deferred bugs can be high, and may need to spend some dedicated time to fix these bugs.

Now, what needs to be done in such cases since there needs to be an agreement between the engineering teams and product managers.
First, before starting on a new cycle, the team needs to spend around a week (with multiple meetings) to work through what all is planned for the next cycle, and this includes discussing what needs to be the focus of the release. A good way to sort through the legacy features is to emphasize that legacy features are non-negotiable and need to be tested since they impact customers directly. In a number of cases, without this discussion, the Product Management team has not thought through the need to test legacy features and when this discussion happens, this issue will get cleared.
Secondly, when the discussions about the features for the cycle starts, the team will need to work through setting aside dedicated time for infrastructural items, and the engineering team will need to push a bit hard on this issue; and in most reasonable cases, there will be an agreement between the engineering and the product management team as long as the time needed for this infrastructural work does not take too long.
In all such cases, focusing on a mix of the needed technical architecture work and new features should help to resolve such issues.

Requirements Management

Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of. The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders.

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

The purpose of the Requirements Traceability Matrix is to help ensure the object of the requirements conforms to the requirements by associating each requirement with the object via the traceability matrix.
A traceability matrix is used to verify that all stated and derived requirements are allocated to system components and other deliverables.

- Features Traceability Table : It shows how requirements relate to important customer observable system/product features.
- Source Traceability Table : It identifies the source of each requirement.
- Dependency Traceability Table : It indicates how requirements are related to one another.
- Subsystem Traceability Table : it categorizes requirements by the subsystem that they govern.
- Interface Traceability Table : It shows how requirements relate to both internal and external system interfaces.