What is Test Case



Test Case is a terminology related to Software Testing and Software Engineering. Test Case can be defined as set of “Actions”, “input data” and “Expected” results.

Test Case = Actions + Input Data + Expected results

Click on the above image to see full sized image.

A good Test Case is one which is more realistic, validates requirements and intends to find maximum defects.

Other Test Case Definitions:

IEEE defines Test Case as
A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

Boris Beizer defines a test as
A sequence of one or more subtests executed as a sequence because the outcome and/or final state of one subtest is the input and/or initial state of the next. The word ‘test’ is used to include subtests, tests proper, and test suites.

Test Case can be categorized as two types Informal Test Cases and Formal Test Cases.

Test Case Categories

Test Case Categories

Click on the above image to see full sized image.

 

1) Informal Test Cases: Characteristics of Informal Test Cases

  • Test Cases are usually not documented.
  • If Test Cases are documented then it will be very briefly documented, like one line description on what do and what to expect as outcome.
  • Test cases are applicable for applications that are quite common and simple to test like a “Calculator” application.
  • Tests are performed based on Test scenarios rather than specific Test Conditions.
  • When there is no formal documentation available and the person testing the software has very good knowledge of how the software is expected to function. Informal test Cases are also applicable for some of the software testing types like Sanity Testing, Usability Testing etc.
  • Test Cases are intended to cover more of Happy path/Positive conditions rather than Negative conditions.

2) Formal Test Cases: Characteristics of Formal Test Cases

  • Test Cases are detailed and well documented.
  • Test Cases usually have multiple or several Test steps, input data and expected output/result.
  • Test Cases cover Happy Path / Positive conditions and Negative conditions.
  • Test Cases are documented using a Test Management Software like Quality Center (QC) or Clear Quest IBM Clear Quest or any of the Standardized test case templates like excel or word.
  • Test cases are derived from Requirements, Design documents and Use Cases.
  • Test cases created are traceable with requirements using Requirements Traceability Matrix.
  • Test Cases design techniques like BVA (Boundary Value Analysis) , Equivalence Partitioning (EP) , Decision Tables , Error Guessing and Cause Effect Graph techniques.
  • Test Case is reviewed, by peer (peer review) or SME (SME review).
  • Test Cases are version controlled.
  • Test Cases change log is maintained. Every change to a Test Case has to be reviewed.
  • Test Execution is planned, tracked and Test Execution results are logged for each step of the Test Case.

How to write a Test Case or Test Cases ?

Test Cases have to be created systematically; otherwise one will end up creating redundant test cases or test steps and cannot ensure 100% requirement coverage.

So, what do we mean by creating test cases systematically? Refer to below Test Case creation diagram; and you will come to know what I am referring to. Before jumping to Test Case creation, one needs to identify Test Scenarios based on Requirements document, Use case diagrams and high level design documents. Once Test Scenarios are documented, reviewed and finalized, one can start identifying Test Conditions and Expected results for each of the Test Scenarios and Detailed design documents. Once Test Conditions and Expected results are documented, reviewed and finalized, Test Cases can be derived to cover one more related test conditions and expected results.

 

Writing Test Case, create Test Cases

Click on the above imageto see full sized image. 

Test case design and test case generation :


Below are some of the popular Test Case design and test case generation techniques. Test Case Design Techniques listed below tries to derive optimal test conditions and uncover unique class of errors, however there will be few common Test conditions derived when multiple Test Case design technique are used. Each of the below mentioned Test Case Technique is used to generate different Test conditions related to Boundary conditions, Error classes, multiple or complex decisions and conditions and where most of the defects lurk.

i. BVA (Boundary Value Analysis) : Boundary Value Analysis focuses on testing boundary conditions e.g.: If we have to derive test conditions to test a text box that accepts age between 18 and 100. Then test conditions would be 17, 18, 19, 50, 99,100 and 101. As you can see, test conditions focus on testing just below boundary, at boundary and over boundary.

ii. Equivalence Partitioning (EP) : Equivalence partitioning focuses deriving test conditions based on classes of data at a minimal of 2 classes i.e. Positive and error classes of data. e.g. If we have to test password text box, Positive class would be valid password and invalid class would be password in different case, incomplete password or different password.

iii. Decision Tables : Decision tables help in deriving test conditions where multiple decision variables like (if-else-if… conditions) are involved. Just as in below case of Bank interest calculation.

decission table = conditions, actions and rules

Decission Table

Click on the above image to see full sized image.

iv. Error Guessing : Error guessing technique helps to device Test conditions based on the domain knowledge, prior experience in testing of similar software or application(s) built on similar technology or prior experience in Software Testing. Error guessing technique is effective, when tester deriving Test Conditions is more experienced Software Tester, has good knowledge of Business domain and technology on which software is built.

v. Cause Effect Graph techniques : Cause (C) and Effect (E) diagram is analogous to Test Case “Action” and “Expected Result”, hence this technique is an effective tool to visualize and derive probable combinations of different test conditions and expected result.

Cause Effect Graph Notations
Cause Effect Graph Notations

Click on the above image to see full sized image.

Let us draw Cause and Effect Graph for “Rate of interest calculation”:

List of Causes represented by letter “C”:
C1: Age of depositor >= 18 and < 60
C2: Age of depositor >= 60
C3: Deposit Term is < 1 Year
C4: Deposit Term is >= 1 Year and < 2 Years
C5: Deposit Term is >= 2 Year and < 5 Years
C6: Deposit Term is > 5 Years

List of Effects represented by letter “E”:
E1: Rate of Interest is 8.5%
E2: Rate of Interest is 9.5%
E3: Rate of Interest is 10.0%
E4: Rate of Interest is 11.0%

Cause Effect Graph Example
Cause Effect Graph Example

Click on the above image to see full sized image. 

Points keep in mind prior-to or while writing Test Cases:

- Better Test Case: Objective of writing test cases should be to write better test cases that is intended to test software requirements in detail and also to find maximum number of defects.

- Document Sign off: Start writing Test Cases only when documents (Requirements/Design/Use Case) are signed off by all required Project Stakeholders (including clients if required as per Test Process followed). Otherwise you will end up in wasting lot of time in Test Case rework.

- Test Case Naming Convention: Name Test Cases that will identify objective of Test Case, like TC_Login_REQ1_3, as you can understand from Test Case name, Login page is being tested and requirements Req-01 and Req-03 are covered in the test case. Incase Test Case Naming convention is not already defined for your project then take initiative and get it defined.

- Keep Test Case Simple: Write Test Cases in simple plain language and do not use ambiguous or complicated statements.

- Detail Test Cases: Write Test Cases in detail and do not write generic statements like “Validate all the fields in Preview page”, instead explain which field has to be verified for what value.

- Embed Test Data: Provide details of the Test Data to be used for each of the Test Step.

- Track Test Case changes: Maintain Test Case history to capture changes made to Test Cases.

- Test Case Priority: Assign a priority for each of the Test Case created; this will help in identifying and tracking execution of higher priority test cases to be executed before executing medium or lower priority test cases. Defining priority also helps in building effective Smoke Test or regression test suites or helps in identifying test cases for Risk based Testing.

- Others will execute your test cases: Do not presume that you will be the only one who would be executing the test cases written by you. Write test cases presuming even others will execute them and hence test cases have to be detailed.

- Use Test Case Design Techniques: Always use Test Case design techniques (listed above) to derive test conditions.

- 100% Requirement Coverage is a must: Check and ensure 100% requirement coverage and track the requirements covered, test cases written should be tracked with a Requirements traceability matrix.

- Reusable Test Steps: Create reusable Test Steps and call it in other Test Cases, like Login, Logout and other common Test Steps can be made as reusable Test Steps and call it in other Test Cases. Incase there are changes in Login or Logout steps; you don’t have to change across many test cases. Test Case and Test suite maintenance becomes quicker and takes less effort. Test Management Software like Quality Center (QC) provides such facility to create reusable steps and call the reusable steps in other test cases. Hence Test Management software is more preferable over Test Case templates that are built in Excel or word.

- Test Case review is a must: Ensure all the test cases are reviewed by required stake holders (peer reviewed or SME reviewed or client review) based on the Test Process practiced in your project or company.

- Use Test Management software: Always, promote and use Test Management software like Quality Center (QC) or IBM Clear Quest. Software Test Management Software helps in maintaining traceability Matrix, its easier to map requirements to Test Cases to Defects and Viz. It is also convenient to plan test execution, maintain test log and these Test management software come with lot of ready to run reports and inbuilt reporting templates, which helps to generate quality reports quickly. Incase your Project or company is not in a position to fund for these tools then suggest usage of Open Source Test Management tools like Bugzilla Testopia which is a Test Case management software and extension of Bugzilla.

What is Test Case Template ?

Template is a stencil or a predefined layout that is used to ensure all the similar deliverables are formatted alike and capture same data irrespective of who creates the deliverable, its not longer person dependent instead its process dependent. Usage of template is part of stable and mature Test Process.
Even Test Management software provides Test Case Template and Defect Templates to define the data points to be captured or displayed on the forms.

MS Excel or Word Test Case templates are usual used when Test Management software is not available. Test Case template created in Excel is usually preferred as it’s more readable, also it allows usage of formals and cell auto formatting to highlight Test step and Test Case result. Excel Test Case template also makes Test Reporting easier by using formulas that can consolidate results of all the Test Cases, where with Test Case template created in word result consolidation has to be done manually. Refer to below templates created in Excel and word and see the differences and convenience for yourself.

Irrespective of which template is being used, Test Template or Test management software would capture below attributes related to Test Case.

Please download sample Test Case templates with examples ( Test Case for Login ) created in word an Excel.

Download (Test Case Template.docx) word Test Case template with example Test Case.

Download (Test Case Template.xlsx) Excel Test Case Template with example Test Case.

 

Screenshots of Excel Test Case Template:

Test Case
Test Case Summary and Result

 

Test Case

Test Case Objective, Dependencies and Pre-requisites

 

Test Case
Test Case

 

Test Case
Test Case History

 

Screenshots of Word Test Case Template:

 Test Case Template

Test Case Summary and Result
 
Test Case Template

Test Case Objective, Dependencies and Pre-requisites

 

Test Case Template
Test Case Template

 

Test Case Template
Test Case History

 

Fields of a Test Case Template :

  • Project Name: Name of the Project for which Test Case created and would be executed on.
  • Release Name: Name of the Release for which Test Case created and would be executed on.
  • Requirements Tested: List of all requirements tested in the Test Case.
  • Test Case Name: Name of the Test Case, should use a convention like TC-[Mod Name]_REQ[requirement numbers tested]
  • Test Case Objective: One of the key fields of Test Case template that explains the objective of the Test Case and what is being tested.
  • Test Case Pre-execution Steps: Describes of any actions to be performed before executing the test case.
  • Post Execution Clean-up Steps: Describes of any clean-up actions to be performed after execution of test case. Clean up activity can be any action that has to be performed on Test Environment, OS Configuration, Application settings, Test Data or Database to bring them back to state that was before execution of the test case. So that actions or changes brought in by execution of the test case does not influence results or outcome of remainder of the Test Cases to be executed.
  • Test Case Dependencies: Details on the dependencies on other Test Cases, Test Data, Test Environment, OS Configuration, Application Settings, Data and time, External Services, Stubbed Services etc.,
  • Test Case Priority: Priority of the Test Case to indicate the order of execution e.g. P1 (Critical), P2 (High), P3 (Medium), P4 (Low).
  • Test Case Complexity: Complexity of the test case will help in Test Case assignment during Test Planning phase. Simple and Medium complex test cases can be assigned to fresher or less experience Testers.
  • Test Case Created by: Name or the ID of the person who created the Test Case.
  • Test Case Created on Date: Date on which Test Case created. This field helps in deriving metrics like “Test Case creation rate” related to Test Creation phase.
  • Test Case Reviewed by: This field indicates Name or ID of person who reviewed Test Case. This field helps to know who reviewed and also to identify test cases reviewed and to be reviewed.
  • Test Case Review Date: This field indicates date on which Test Case reviewed. Incase a test case is reviewed for multiple times; it will contain last review date.
  • Planned Test Phase: This field indicates Test Phase on which Test Case is executed to be planned.
  • Actual Test Phase: This field in update at time of Test Case execution and indicates Test Phase during which Test Case was executed.
  • Planned Test Execution Start Date: Date on which Test case execution is planned to start.
  • Actual Test Start Date: Date on which Test Case execution was actually started.
  • Planned Test Execution End Date: Date on which Test Case is execution planned to be completed.
  • Actual Test Execution End Date: Date on which Test Case execution was actually completed.
  • Test Environment: Test Environment on which Test Case was executed.
  • Build Number (If applicable) : Build number on which Test Case was executed.
  • Test Result: Result of Test Case, will be “No Run” before execution, “In progress” during execution, “Blocked” incase test case cannot be executed due to an existing defect, “Pass” incase all the Test Steps of the Test Case have passed and “Fail” incase one or more Test Steps of the Test Case has Failed.
  • Step ID / Step No. : An identifier provided for each of the Test Case steps. Usually, numeric 1, 2, 3.
  • Test Step: Indicates one or more actions to be performed.
  • Input Data / Test Data: Provides details of the data to be used for testing the step.
  • Expected Result: Described what to expect for the action performed and input data.
  • Actual Result: Tester will key in observation based on what they observed.
  • Test Step Result: Indicates results of the Test Step, will be “Not Run” if Test Step is not run, “Blocked” if the test step was not executed due to an existing defect, “Fail” if output did not match with Expected result, “Pass” if output matched Expected result.
  • Defect#: Defect number associated with Failed Test Step.
  • Comments: Any additional notes or observations tester wants to document during Test Execution.
  • Test Case Change Log: Contains list of fields like “Change Summary”, “Reason for Change”, “Changed on Date”, “Changes reviewed by”, “Change review date” and “Comments”.

Other Interesting Articles:



5 comments ↓

#1 Amy on 01.25.13 at 2:30 am

You are an excellent writer, this is one of the best articles I have read till on any blog, thanks for sharing Test Case Template, it is really good, contains formulas that calculate number of passed and failed test steps. Well done.

#2 Rohan on 02.22.13 at 8:15 pm

if somebody wants to understand what test case is then this is the article to read.

#3 Shafeeq on 04.03.13 at 8:03 am

the one word to describe such a well written article is “SIMPLE”.
Thank you

#4 Maahi on 06.02.13 at 11:09 am

simple and very nice…

#5 Rohan on 07.12.13 at 12:52 pm

simple, yet very effective way of explaining stuff, great job

Leave a Comment

Comment moderation is enabled. Your comment may take some time to appear.









Page 1 of 11