This is the second part of the series addressing test cases in which we are going to write on introduction and purpose of writing test cases. In our first part we wrote about background of test cases and need of writing test cases.
Introduction
Writing successful test cases is a skill which can be attained by some understanding and detailed study of the application on which test cases are being written. A software test case is a set of steps and expected results used to test an application. Usually test cases are created from the software requirements but this is not a hard and fast rule. (You will find more about the test case writing technique further in this document and our upcoming document of this series). Well written test cases can make the testing cycle smooth and efficient. It is imperative to write clear, understandable test cases that can be run against new functionality and regression testing, as well. A good test case is easy to run, consistent in the time it takes to run and it is easy to maintain.
It may take many test cases to determine that a requirement is fully satisfied. In order to fully test that all the requirements of an application are gathered, there should be at least one test case for each requirement unless a requirement has sub-requirements. When a requirement has sub-requirement, each sub-requirement should have at least one test case.
Written test cases should include a description of the module to be tested, and the preparation required to make sure that the test can be carried out. If the application is created without formal requirements then test cases can be written based on the accepted normal operation of programs of a similar category. In formal test cases we have known input and an expected output that worked out before the test is executed. The known input should test a precondition and the expected output should test a post-condition.
Under special conditions, there might be a need to run the test, produce results and then a team of testers would calculate if the results can be considered as a pass. The first test is taken as the base line for following (subsequent) test. Written test cases are usually collected into test sets.
What is a Test Case?
Definition:
“A test case has a component that describes an input, action or event and an expected response, to determine if a feature of an application is working correctly.”
Tester write test cases to verify and validate the software build. Test case shows what will be the expected and actual result before execution of the build. It shows what will be the input and output of every condition. It also shows how a layman user come to know about the application or can use the application.
In general speaking, a test case is a query that we ask over the application. We gain information about the stability of the application by making query to the specific area of the application under test. For example the application under test will pass or fail the test.
Purpose:
The purpose of writing test case is to identify and document the major functional parts of the product. Test case has to be changed if there is a major functional change in the system or business process flow.
Test case checks and validates the system flow according to requirement specifications, conformance with existing system and optimization of business process. Test cases help in creating and executing abnormal scenarios. Test cases also useful for validating system behavior and performance. For example a system needs user’s email address and password to login into the system. Test cases with different scenarios can help to validate that only the right person can login to the system. Test cases help to find and report bugs in the system.
Different test cases may furnish different test scenarios. Test case may be written to check the system’s functional requirements, system’s performance, system’s error handling, system’s security checks, system’s usability etc. The main purpose of Quality testing in a broad aspect is to create a bug free or zero defect product. Test case is one of the important aspects of that part.
Conclusion:
A good test case should be easy to “understand”, “reproduce”, “manage”, “reuse”, “validate expectations and customer needs, “ simulate real end user scenarios ”, and “ easy to expose bugs” ,etc.
In our upcoming post we shall debate on the main stakeholders in testing, and some misconceptions about “testers” as stakeholders.
