A test case is a document that describes an input, action or event and
an expected response, to determine if a feature of an application is
working correctly.
A test case should contain particulars such as test case identifier,
test case name, objective, test conditions/setup, input data
requirements, steps, and expected results.
The key issue under Test case designing is to identify a subset of all
possible Test Cases (set of data to be used as input) that have a high
probability of detecting errors.
Test Case-Definitions
IEEE Standard 610 (1990) defines test case as follows:
"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."
"Documentation specifying inputs, predicted results, and a set of
execution conditions for a test item."
According to Ron Patton (2001)
"Test cases are the specific inputs that you'll try and the procedures that you'll follow when you test the software."
Boris Beizer (1995)
"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."
Why We Need Test Cases?
• Provides a standardized set of baselines for each testing cycle
• Help "jump start" the testing for the inexperienced testers or for new team members
• Help define the scope of testing Stop asking "Did I miss anything?"
• Repeatability Help Repeat the same tests regardless of the tester
• Helps you to concentrate on the quality aspects of testing
• Help correctly estimate the effort for future regression test cycles
Types of Test Cases
• Positive Test Cases: Entering valid data into an application to determine if its processing results are correctly produced as defined in the requirement specification.
• Negative Test Cases: Entering incorrect data intentionally to determine if an application will recognize the data entered is invalid and take appropriate action
Elements of a Test Case
•The purpose of the test or description of what requirement is being tested
•Test Data
•The method of how it will be tested
•The setup to test: version of application under test, hardware, software, operating system, data files, security access, logical or physical data, prerequisites such as other tests, and any other setup information pertinent to the requirement(s) being tested
• Actions and expected results, or inputs and outputs
• Any proofs or attachments (optional)
• Requirement number
• For each section cover all possible scenario's for one field together.
Attributes of a Good Test Case
• Accurate: They test what their descriptions say they will test.
• Economical: They have only the steps or fields needed for their purpose.
• Repeatable, self-standing: A test case is a controlled experiment. It should get the same results every time no matter who tests it.
• Appropriate: A test case has to be appropriate for the testers and environment.
• Traceable: You have to know what requirement the case is testing.
Common Mistakes in Test Case Generation
• Making case too long
• Incomplete, incorrect or incoherent setup
• Leaving out a step
• Naming fields that changes or no longer exist
• Unclear whether tester or system does action
• Unclear what is a pass or fail result
• Test intent/objective is an action step, not an objective
• Test data drives the test object
• Test cases have unrealistic interdependencies.
Design Test Objective
Objective:
• To identify test procedure that show how the test cases will be identified
• To identify a set of verifiable test cases for the system requirements
Scope:
• Scope of Quality Assurance Test Case (QATC) extends to covering/testing the functional aspects of the application
• Unit testing and integration testing is not covered under this activity.
Design Test Case Activities Steps
● Analyze the Requirement
● Identify the Test Procedure
● Identify and Describe Test cases
● Identify test data
● Perform Workload Analysis (for performance testing only)
● Review and Assess Test Coverage
● Generate / Update Traceability Matrix
Identifying Test Conditions and Designing Tests
The process of identifying test conditions and designing tests consists of a number of steps :
• Designing tests by identifying test conditions
• Specifying test cases
• Specifying test procedures
• The process can be done in different ways, from very informal with little or no documentation, to very formal
• The level of formality depends on :
* Context of the testing
* Organization,
* Maturity of testing and development processes
* Time constraints
* People involved
Guidelines for Writing Test Cases
1. The Test Case objective should be Brief & Clear
2. The Test Case should correctly Verify the requirement
3. Expected result should specify the Behavior of the function being tested when we do certain action
4. Test Case should be Easy to determine the result
5. Test Case should be Maintainable
6. Test Case should be Manageable
Bad Practices
1. Test cases should NOT be Long and Invalid
2. Test cases should NOT be Complicated
3. Avoid writing Unobvious tests
4. Duplicate test cases to be avoided
5. Test cases should not be written with out Expected Results
6. Test Cases should be written with proper Header / Pre-Conditions
7. Test case should not be outdated
No comments:
Post a Comment