Test Case Documents
Designing good test cases is a complex art. The complexity comes from three sources:
§ Test cases help us discover information. Different types of tests are more effective for different classes of information.
§ Test cases can be "good" in a variety of ways. No test case will be good in all of them.
§ People tend to create test cases according to certain testing styles, such as domain testing or risk-based testing. Good domain tests are different from good risk-based tests.
What's a test case?
"A test case specifies the pretest state of the IUT and its environment, the test inputs or conditions, and the expected result. The expected result specifies what the IUT should produce from the test inputs. This specification includes messages generated by the IUT, exceptions, returned values, and resultant state of the IUT and its environment. Test cases may also specify initial and resulting conditions for other objects that constitute the IUT and its environment."
What's a scenario?
A scenario is a hypothetical story, used to help a person think through a complex problem or system.
Characteristics of Good Scenarios
A scenario test has five key characteristics. It is (a) a story that is (b) motivating, (c) credible, (d) complex, and (e) easy to evaluate.
The primary objective of test case design is to derive a set of tests that have the highest attitude of discovering defects in the software. Test cases are designed based on the analysis of requirements, use cases, and technical specifications, and they should be developed in parallel with the software development effort.
A test case describes a set of actions to be performed and the results that are expected. A test case should target specific functionality or aim to exercise a valid path through a use case. This should include invalid user actions and illegal inputs that are not necessarily listed in the use case. A test case is described depends on several factors, e.g. the number of test cases, the frequency with which they change, the level of automation employed, the skill of the testers, the selected testing methodology, staff turnover, and risk.
The test cases will have a generic format as below.
Test case ID - The test case id must be unique across the application
Test case description - The test case description must be very brief.
Test prerequisite - The test pre-requisite clearly describes what should be present in the system, before the test can be executes.
Test Inputs - The test input is nothing but the test data that is prepared to be fed to the system.
Test steps - The test steps are the step-by-step instructions on how to carry out the test.
Expected Results - The expected results are the ones that say what the system must give as output or how the system must react based on the test steps.
Actual Results – The actual results are the ones that say outputs of the action for the given inputs or how the system reacts for the given inputs.
Pass/Fail - If the Expected and Actual results are same then test is Pass otherwise Fail.
The test cases are classified into positive and negative test cases. Positive test cases are designed to prove that the system accepts the valid inputs and then process them correctly. Suitable techniques to design the positive test cases are Specification derived tests, Equivalence partitioning and State-transition testing. The negative test cases are designed to prove that the system rejects invalid inputs and does not process them. Suitable techniques to design the negative test cases are Error guessing, Boundary value analysis, internal boundary value testing and State-transition testing. The test cases details must be very clearly specified, so that a new person can go through the test cases step and step and is able to execute it. The test cases will be explained with specific examples in the following section.
For example consider online shopping application. At the user interface level the client request the web server to display the product details by giving email id and Username. The web server processes the request and will give the response. For this application we will design the unit, Integration and system test cases.
Figure 6.Web based application
Unit Test Cases (UTC)
These are very specific to a particular unit. The basic functionality of the unit is to be understood based on the requirements and the design documents. Generally, Design document will provide a lot of information about the functionality of a unit. The Design document has to be referred before UTC is written, because it provides the actual functionality of how the system must behave, for given inputs.
For example, In the Online shopping application, If the user enters valid Email id and Username values, let us assume that Design document says, that the system must display a product details and should insert the Email id and Username in database table. If user enters invalid values the system will display appropriate error message and will not store it in database.
Figure 7: Snapshot of Login Screen
Test Conditions for the fields in the Login screen
Email-It should be in this format (For Eg clickme@yahoo.com).
Username – It should accept only alphabets not greater than 6.Numerics and special type of characters are not allowed.
Test Prerequisite: The user should have access to Customer Login screen form screen
Negative Test Case
Project Name-Online shopping
Version-1.1
Module-Catalog
| Test # | Description | Test Inputs | Expected Results | Actual results | Pass/Fail |
| 1 | Check for inputting values in Email field | Username=Xavier
| Inputs should not be accepted. It should display message "Enter valid Email" |
|
|
| 2 | Check for inputting values in Email field | Email=john26#rediffmail.com Username=John
| Inputs should not be accepted. It should display message "Enter valid Email" |
|
|
| 3 | Check for inputting values in Username field | Username=Mark24
| Inputs should not be accepted. It should display message "Enter correct Username" |
|
|
Positive Test Case
| Test # | Description | Test Inputs | Expected Results | Actual results | Pass/Fail |
| 1 | Check for inputting values in Email field | Email=shan@yahoo.com Username=dave
| Inputs should be accepted. |
|
|
| 2 | Check for inputting values in Email field | Email=knki@rediffmail.com Username=john
| Inputs should be accepted. |
|
|
| 3 | Check for inputting values in Username field | Email=xav@yahoo.com Username=mark
| Inputs should be accepted. |
|
|
Integration Test Cases
Before designing the integration test cases the testers should go through the Integration test plan. It will give complete idea of how to write integration test cases. The main aim of integration test cases is that it tests the multiple modules together. By executing these test cases the user can find out the errors in the interfaces between the Modules.
For example, in online shopping, there will be Catalog and Administration module. In catalog section the customer can track the list of products and can buy the products online. In administration module the admin can enter the product name and information related to it.
Table3: Integration Test Cases
| Test # | Description | Test Inputs | Expected Results | Actual results | Pass/Fail |
| 1
| Check for Login Screen | Enter values in Email and UserName. For Eg: Email =shilpa@yahoo.com Username=shilpa | Inputs should be accepted. |
|
|
| Backend Verification | Select email, username from Cus; | The entered Email and Username should be displayed at sqlprompt. |
|
| |
| 2 | Check for Product Information | Click product information link | It should display complete details of the product |
|
|
| 3 | Check for admin screen | Enter values in Product Id and Product name fields. For Eg: Product Id-245 Product name-Norton Antivirus | Inputs should be accepted. |
|
|
| Backend verification | Select pid , pname from Product; | The entered Product id and Product name should be displayed at the sql prompt. |
|
|
NOTE: The tester has to execute above unit and Integration test cases after coding. And He/She has to fill the actual results and Pass/fail columns. If the test cases fail then defect report should be prepared.
System Test Cases: -
The system test cases meant to test the system as per the requirements; end-to end. This is basically to make sure that the application works as per SRS. In system test cases, (generally in system testing itself), the testers are supposed to act as an end user. So, system test cases normally do concentrate on the functionality of the system, inputs are fed through the system and each and every check is performed using the system itself. Normally, the verifications done by checking the database tables directly or running programs manually are not encouraged in the system test.
The system test must focus on functional groups, rather than identifying the program units. When it comes to system testing, it is assume that the interfaces between the modules are working fine (integration passed).
Ideally the test cases are nothing but a union of the functionalities tested in the unit testing and the integration testing. Instead of testing the system inputs outputs through database or external programs, everything is tested through the system itself. For example, in a online shopping application, the catalog and administration screens (program units) would have been independently unit tested and the test results would be verified through the database. In system testing, the tester will mimic as an end user and hence checks the application through its output.
There are occasions, where some/many of the integration and unit test cases are repeated in system testing also; especially when the units are tested with test stubs before and not actually tested with other real modules, during system testing those cases will be performed again with real modules/data in
No comments:
Post a Comment