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]
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
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.
