Skip to main content

Designing Test Cases

Designing Test Cases

A test case is a detailed procedure that fully tests a feature or an aspect of a feature. Whereas the test plan describes what to test, a test case describes how to perform a particular test. You need to develop a test case for each test listed in the test plan.

A test case includes:
  • The purpose of the test.

  • Special hardware requirements, such as a modem.

  • Special software requirements, such as a tool.

  • Specific setup or configuration requirements.

  • A description of how to perform the test.

  • The expected results or success criteria for the test.

Test cases should be written by a team member who understands the function or technology being tested, and each test case should be submitted for peer review.

Organizations take a variety of approaches to documenting test cases; these range from developing detailed, recipe-like steps to writing general descriptions. In detailed test cases, the steps describe exactly how to perform the test. In descriptive test cases, the tester decides at the time of the test how to perform the test and what data to use.

Most organizations prefer detailed test cases because determining pass or fail criteria is usually easier with this type of case. In addition, detailed test cases are reproducible and are easier to automate than descriptive test cases. This is particularly important if you plan to compare the results of tests over time, such as when you are optimizing configurations. Detailed test cases are more time-consuming to develop and maintain. On the other hand, test cases that are open to interpretation are not repeatable and can require debugging, consuming time that would be better spent on testing.

Test Case Design

Test Case ID:
It is unique number given to test case in order to be identified.

Test description:
The description if test case you are going to test.

Revision history:
Each test case has to have its revision history in order to know when and by whom it is created or modified.

Function to be tested:
The name of function to be tested.

Environment:
It tells in which environment you are testing.

Test Setup:
Anything you need to set up outside of your application for example printers, network and so on.

Test Execution:
It is detailed description of every step of execution.

Expected Results:
The description of what you expect the function to do.

Actual Results:
pass / failed

If pass - What actually happen when you run the test.

If failed - put in description of what you've observed.

Comments

Do test cases needs to be prepared first or they are documented during the testing process. I an new to this concept.
QA Testing said…
It appears that you have done a very good job of listing all the steps in designing test cases. It seems that this step is only limited by the imagination and experience of the software tester.
Win8 said…
I can't wait to read far more from you. This is actually a tremendous web site.
Win8 said…
I can't wait to read far more from you. This is actually a tremendous web site.

Popular posts from this blog

Istqb,cste inforamtions and training centers in India

About istqb:
The ISTQB was officially founded as an International Testing Qualifications Board in Edinburgh in November 2002 and it is responsible for the "ISTQB Certified Tester", which is an international qualification scheme.

ISTQB is the parent body responsible for approving various national boards in addition to other tasks such as defining the syllabi for various certifications.
website url:
www.indiantestingboard.com FAQ :http://208.116.30.129/faq.htm

for examination and preparation and sample question papers available in below link

will be helpful for ISTQB http://india.istqb.org/resources.htm

http://www.geekinterview.com/quiz/Testing

join yahoo groups:
in this group you can ask your queries about istqb examinations and certification related doubts and sample papers to certified testers..foundation level and advance level question keep on raised by members.

ISTQB-India@ yahoogroups. com

CSTE information:

QAI, India, the premier knowledge corporation in the software engineerin…

Equivalence partitioning

Equivalence partitioning:
Equivalence partitioning is a method for deriving test cases. In this method, classes of input conditions called equivalence classes are identified such that each member of the class causes the same kind of processing and output to occur.

In this method, the tester identifies various equivalence classes for partitioning. A class is a set of input conditions that are is likely to be handled the same way by the system. If the system were to handle one case in the class erroneously, it would handle all cases erroneously.

Equivalence partitioning drastically cuts down the number of test cases required to test a system reasonably. It is an attempt to get a good 'hit rate', to find the most errors with the smallest number of test cases.

To use equivalence partitioning, you will need to perform four steps:
Determining conditions to be TestedDefining TestsDesigning test casesIdentifying Final set of Test Cases

Defining Tests

A number of items must be considered when…

Cyclomatic complexity

Cyclomatic complexity is a software metric (measurement). It was developed by Thomas McCabe and is used to measure the complexity of a program. It directly measures the number of linearly independent paths through a program's source code. It is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command.


Definition

M = E − N + 2P

where

M = cyclomatic complexity
E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components.

"M" is alternatively defined to be one larger than the number of decision points (if/case-statements, while-statements, etc) in a module (function, procedure, chart node, etc.), or more generally a system.

Separate subroutines are treated as being independent, disconnected components of the program's control flow graph.