Showing posts with label ISTQB. Show all posts
Showing posts with label ISTQB. Show all posts

Test performance indicator

A metric, in general high level, indicating to what extent a certain target value or criterion is met. Often related to test process improvement objectives, e.g. Defect Detection Percentage (DDP).

In simple English:
Any measure to reflect the quantity or quality of the testing done measured over a period of time. 

Day for example you are trying a new diet to reduce weight. You would weigh yourself before, during and after the diet to understand if the diet is working. 
Similarly when you start a testing project you decide on certain parameters to measure over a period of time. You would expect these parameters to help you judge if your testing process is working towards the goals you want it to achieve. 






Test policy

ISTQB Glossary  definition
A high level document describing the principles, approach and major objectives
of the organization regarding testing.

In Simple English,

How an organization views testing should be done and what is expected out of the testing. Combination of guidelines and 

Test run

ISTQB Glossary  definition 
"Execution of a test on a specific version of the test object."
In Simple English,


Every attempt you make to formally execute the steps of a test case is a test run.
Field Notes 


  • Test runs are formally tracked in test management tools most times
  • Test runs are applicable only to certain formal testing methods and not all.
  • Test methods like exploratory testing do not have a formal test run.

For Example:


Say, you are trying to test a login page.
One test case would be to to give a incorrect password and expect an error message which says "Error: In correct password entered.".

Now when you first test this page it say it says another error message "Error: User does not exist". You now have completed one test run and have observed an deviation from expected result.You would log this as an defect. Now you have just completed one test run.

Now after logging the defect you want to see if the defect is repeatable. You perform the steps of the test case one more time and see that the same defect occurs. Now you completed the second test run for this same test case.

Test run log

Testability review

ISTQB Glossary  definition 
"A detailed check of the test basis to determine whether the test basis is at an adequate quality level to act as an input document for the test process. " [After TMap]

In Simple English,
A review of all documents based on which you are going to test to check if they are good enough to start testing activities.
Field Notes 


  • Another way to say this would be: A review of requirement documents for completeness.
  • Even simpler to understand is the question you ask in a testability review, "Is requirements frozen?"
  • Remember, requirements do not limit to the functional requirements document of the software being build.
  • Requirements include other things like the style guide which defines do's and don't of how a screen can be designed, Performance expectations and internationalization requirement.
  • Broadly you can classify these requirements as below 
    • Stated and documented Functional Requirements
    • Stated and documented non functional requirements
    • stated and documented guidelines, legal limitations, compliance requirements.
    • Un stated yet expected non functional requirements like no spelling errors.
    • Stated and documented special requirements unique to the application being built

For Example:

        Say for example, you are asked to test an application. The first thing you would ask the team is "So, what is this application about?" and they might send you a requirements document. You review it and you find that the requirements document does not define the modes of payment accepted to buy a ticket. in this case the requirement document is not complete. 


Your testability review in this case would resulting in you deciding and declaring that the application is not testable as you do not have a established basis to test for

Not that even if the requirements document is complete and test basis is established it might fail the testability review if you find in the review that it is not approved or frozen yet.