The goal of a matrix of this type is 1.

To make sure that the approved requirements are addressed/covered in all phases of development: From SRS to Development to Testing to Delivery. ======================================================================================= 2. That each document should be traceable: Written test cases should be traceable to its requirement specification. If there is new version then updated testcases should be traceable with that.

A traceability matrix is created by associating requirements with the work products that satisfy them. Tests are associated with the requirements on which they are based and the product tested to meet the requirement.

Above is a simple traceability matrix structure. There can be more things included in a traceability matrix than shown. In traceability, the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many.

Traceability requires unique identifiers for each requirement and product. Numbers for products are established in a configuration management (CM) plan.

Traceability ensures completeness, that all lower level requirements come from higher level requirements, and that all higher level requirements are allocated to lower level requirements. Traceability is also used to manage change and provides the basis for test planning.

Sample Traceability Matrix

A traceability matrix is a report from the requirements database or repository. What information the report contains depends on your need. Information requirements determine the associated information that you store with the requirements. Requirements management tools capture associated information or provide the capability to add it.

The examples show forward and backward tracing between user and system requirements. User requirement identifiers begin with "U" and system requirements with "S." Tracing S12 to its source makes it clear this requirement is erroneous: it must be eliminated, rewritten, or the traceability corrected.

For requirements tracing and resulting reports to work, the requirements must be of good quality. Requirements of poor quality transfer work to subsequent phases of the SDLC, increasing cost and schedule and creating disputes with the customer.

A variety of reports are necessary to manage requirements. Reporting needs should be determined at the start of the effort and documented in the requirements management plan.

======================================================================================

As a team leader you are responsible for project planning, scheduling, communicating your project status to your manager and most important task of assigning and monitoring the project work. Your main responsibility is to build a team to achieve your project goals. You need to focus on handling the challenges in your project so that your team and project will grow and perform well. As far as the standard testing process is considered, its depends on you what procedure you want to establish. Yes some people might blame me for this point but I prefer to establish my own processes that work for me. I dont stick to those old process definitions that are written and managed in some 90s and most of which might not applicable nowadays. Test lead is responsible for ensuring project plan changes are incorporated in test plan. You might write a test plan and test strategy (In some cases it might be written by senior test team member or even by project test manager) Ensure the work is going according to this test plan. Identify the risks and try to mitigate them. At the end of project testing life cycle ensure that all test objectives are accomplished and acceptance criteria is met.

Functional testing is the testing of a given applications function, that is, its relation to the user and (especially) to the rest of the system. Traditionally, functional testing is implemented by a team of testers, independent of the developers. While unit testing tests both what an application segment does (how it meets a part of the application specs) and how it does it (how it behaves towards the rest of the application), functional testing tests only the what . A functional test is not concerned with an applications internal details. Another way of stating this is that functional testing is the customers test. But even this is misleading. Developers need a benchmark during all development stages -- a developer-independent benchmark -- to tell them what they have and have not achieved. Functional testing begins as soon as there is a function to test and continues through the applications completion and first customer contact. The expression, the customers test, can be misleading in another way. Some people think of functional testing as mimicking a user and checking for expected output. But the real customer is not just someone feeding commands to the application. He or she is running the application on a system, simultaneously with other applications, with constant fluctuations in user load, etc. The application, of course, should be crashresistant in the face of these conditions. More and more, the user interface of our applications is supplied by pre-tested components, which produce few surprises once they are integrated correctly. On the other hand, we are constantly asked to write custom applications for systems of ever-increasing complexity. Therefore, the central functions tested by a functional test are increasingly system-related rather than user-related.

An automated testing tool, namely, TestComplete, will support functional testing by automating its repetitive aspects and producing results in a flexible, filtered form. In addition, TestComplete enhances its functional testing feature by supporting: