Test Case, Test Condition, Test Procedure, Test Control, Test Execution

As testers, we come across various terms related to our line of work. Here are a bunch of terms prefixed with the word "Test" that we seem to encounter fairly often. Let us quickly look at what these terms mean.

A Test Condition is an aspect or attribute of a system or component that can be verified using test cases. Example: a feature, GUI attributes, function, etc.

A Test Case is a set of input values, pre-conditions, expected results and post-conditions that are created to verify a particular test condition or objective. Example: to verify a specific requirement.

A Test Procedure is a document that specifies the sequence of actions involved in executing a test. The test procedure is also called as test script.

Test Control refers to a management task involving coming up with and application of corrective actions to bring a test project on track when deviations from plan have been observed as part of a monitoring exercise.

Test Execution, as the name suggests - is the process of running a test on the application or system under test. The output of test execution is the actual results which are compared with the expected results that are listed in the test case being executed.

Risks based Software Testing

What does risk mean ? Put simply, risk is something that could result in negative consequences in the future. Risk is viewed in terms of its impact and likelihood of occurrence. Risks in software testing may be broadly classified as product risks and project risks. Product risks relate directly to the software being tested, while project risks relate to the test project's management and control.

Product risks are also called quality risks and are those risks that mainly effect the product's quality. Example: a defect in the software that can cause it to corrupt data.

Project risks are also called planning risks and are those risks that mainly effect the successful completion of the project. Example: Lack of resources that could affect the completion of the project on time.

The importance of a risk is dependent on two main factors, viz. the impact of the risk if it occurs and the likelihood of the risk occurring. Likelihood of risk occurrence generally depends on technical factors pertaining to the product, such as the technologies used to develop and run the software. Example: network bandwidth, product architecture and design, technological limitations, etc. Impact of risk generally arises due to business aspects such as the financial implications should a risk occur, the loss of credibility, security or legal implications and so on.

Testing based on evaluation of risks, involves identifying the risks as part of an analysis exercise and then understanding the importance of each risk identified based on its likelihood and impact to guide the test efforts.

Acceptance, buddy, paired and exploratory testing types in brief

Here's a brief look at some of the testing types listed here

Acceptance Testing
  • black-box type tests
  • executed by customers / their representatives
  • small set of tests generally aligned towards real-life scenarios / use-cases
  • purpose primarily to verify if product meets acceptance criteria and not defect detection
  • tests can verify functional / non-functional requirements
Buddy Testing
  • a type of ad-hoc testing
  • usually comprises two buddies working together to identify defects
  • buddies with diverse backgrounds / perspectives enhance the degree of defects detected
  • developer + tester is a good buddy combination
  • generally performed during unit testing phase
Paired Testing 
  • involves pair of testers working on the same machine testing the product
  • a type of ad-hoc testing
  • helps in idea generation and exchange resulting in new perspectives during testing
Exploratory Testing
  • a type of ad-hoc testing
  • involves testing by exploring the product with set objectives and plan of action
  • uses some common methods to perform exploration e.g. guessing, use case scenarios, meetings with project team, questionnaires, past release defects analysis, etc.
  • can cover both functional areas as well as non-functional requirements around supported platforms and other environment variables, configuration attributes, etc.
  • can also involve teams comprising members of diverse backgrounds to explore specific areas of the product