How Requirement Traceability Matrix is useful ?

A requirements traceability Matrix helps in:

1. Ensuring 100% test coverage
2. Showing requirement/document inconsistencies
3. Displaying the overall defect/execution status with focus on business requirements.
4. If a certain business and/or functional requirement were to change, a TM helps estimate or analyze the impact on the QA team’s work in terms of revisiting/reworking on the test cases.

What is traceability in Software testing?

Test conditions should be able to be linked back to their sources in the test basis, this is known as traceability.Traceability can be horizontal through all the test documentation for a given test level (e.g. system testing, from test conditions through test cases to test scripts) or it can be vertical through the layers of development documentation (e.g. from requirements to components).

Now, the question may arise is that Why is traceability important?  So, let’s have a look on the following examples:

• The requirements for a given function or feature have changed. Some of the fields now have different ranges that can be entered. Which tests were looking at those boundaries? They now need to be changed. How many tests will actually be affected by this change in the requirements? These questions can be answered easily if the requirements can easily be traced to the tests.

• A set of tests that has run OK in the past has now started creating serious problems. What functionality do these tests actually exercise? Traceability between the tests and the requirement being tested enables the functions or features affected to be identified more easily.

Before delivering a new release, we want to know whether or not we have tested all of the specified requirements in the requirements specification. We have the list of the tests that have passed – was every requirement tested?

What is Test Analysis? or How to identiify Test Conditions ?

Test analysis: identifying test conditions

• Test analysis is the process of looking at something that can be used to derive test information.  This basis for the tests is called the test basis.
• The test basis is the information we need in order to start the test analysis and   create our own test cases. Basically it’s a documentation on which test cases are based, such as requirements, design specifications, product risk analysis, architecture and interfaces.
• We can use the test basis documents to understand what the system should do once built. The test basis includes whatever the tests are based on. Sometimes tests can be based on experienced user’s knowledge of the system which may not be documented.
•  From testing perspective we look at the test basis in order to see what could be tested. These are the test conditions.  A test condition is simply something that we could test.
• While identifying the test conditions we want to identify as many conditions as we can and then we select about which one to take forward and combine into test cases. We could call them test possibilities.
• As we know that testing everything is an impractical goal, which is known as exhaustive testing. We cannot test everything we have to select a subset of all possible tests. In practice the subset we select may be a very small subset and yet it has to have a high probability of finding most of the defects in a system. Hence we need some intelligent thought process to guide our selection called test techniques. The test conditions that are chosen will depend on the test strategy or detailed test approach. For example, they might be based on risk, models of the system, etc.
• Once we have identified a list of test conditions, it is important to prioritize them, so that the most important test conditions are identified. Test conditions can be identified for test data as well as for test inputs and test outcomes, for example, different types of record, different sizes of records or fields in a record. Test conditions are documented in the IEEE 829 document called a Test Design Specification.

What are the uses of Static Testing ?

The uses of static testing are as follows:

• Since static testing can start early in the life cycle so early feedback on quality issues can be established.
• As the defects are getting detected at an early stage so the rework cost most often relatively low.
• Development productivity is likely to increase because of the less rework effort.
• Types of the defects that are easier to find during the static testing are: deviation from standards, missing requirements, design defects, non-maintainable code and inconsistent interface specifications.
• Static tests contribute to the increased awareness of quality issues.

What is Static Testing?

• Static testing is the testing of the software work products manually, or with a set of tools, but they are not executed.
• It starts early in the Life cycle and so it is done during the verification process.
• It does not need computer as the testing of program is done without executing the program. For example:  reviewing, walk through, inspection, etc.

What is Test Design Technique ?

By design we mean to create a plan for how to implement an idea and technique is a method or way for performing a task. So, Test Design is creating a set of inputs for given software that will provide a set of expected outputs.  The idea is to ensure that the system is working good enough and it can be released with as few problems as possible for the average user.

Broadly speaking there are two main categories of Test Design Techniques. They are:

1. Static Techniques
2. Dynamic Techniques

 Below is the tree structure of the testing techniques: