Requirements Traceability Matrix (RTM)

1. Requirements Traceability Matrix (RTM)

A document showing the relationship/mapping between Test Requirements and Test Cases.

Elements of RTM:

a. Requirements ID

b. Requirements Description

c. Test Case ID

d. Status [Open, Closed, Defer (Later), On hold]

2. Verification and Validation

Verification is the process confirming that something software meets its specification. Validation is the process confirming that it meets the user's requirements.

Difference between Verification and Validation:

Suppose, you are going to buy a pair of shoes having number 9 for you. You have chosen a pair and seen the tag with 9 written on it. This is verification, because your requirement was to buy a pair of shoes with 9 number.

But when you tried to wear it and found that shoe is not fitted into your feet. After inquery, you have found that company has tagged it 9 number by mistake. Actually it was 7 number shoe. This process is called Validation.

Example of Verification: Creating Traceability Matrix

Example of Validation: Executing Test Cases

3. Static and Dynamic Testing

Static black-box testing: Testing the specification is static black-box testing.

Two Types of Static black-box testing:

1. High-level review techniques

a. Research Existing Standards and Guidelines

b. Review and Test Similar Software

2. Low-level techniques

a. Specification Attributes Checklist (e.g. Spec must be complete, accurate, precise, consistent etc)

b. Specification Terminology Checklist (e.g. focus on the terms in Spec like "If…Then…(but missing Else)." or "Etc., And So Forth, And So On" etc)

Dynamic Black-Box Testing: Testing software without knowledge of code is dynamic black-box testing.

Static White-Box Testing: Static white-box testing is the process of carefully reviewing the software design, architecture, or code for bugs without executing it.

Three Types of Static White-Box Testing:

a. Peer Reviews: Peer Reviews are the least formal method. Peer reviews are often held with just the programmer who wrote the code and one or two other programmers or testers acting as reviewers.

b. Walkthroughs: In a Walkthrough, the programmer who wrote the code formally presents it to a small group of five or so other programmers and testers. The presenter reads through the code line by line, or function by function, explaining what the code does and why. The reviewers listen and question anything that looks suspicious.

c. Inspections: Inspections are the most formal type of reviews and more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The other participants are called inspectors.

Walkthrough:

1. It's a type of Semi Formal Review.

2. 2 to 7 People are attaining it.

3. Author is Presenter.

4. Lead by Author only.

5. Reviewers are not aware of the subject/topic.

Inspection:

1. It's totally a Formal Review.

2. 2 to 10 or more People attaining it.

3. Author is not presenter. Some one else is giving presentation.

4. Lead by Moderator.

5. Reviewers are aware & well prepared for the subject/topic.

6. Recorder is noting down everything. Like defects, changes, improvements etc.

Dynamic White-Box Testing: is a method of testing software that tests internal structures or workings of an application.

Difference between Dynamic White-Box Testing and Debugging:

The goal of dynamic white-box testing is to find bugs. The goal of debugging is to fix them.