The test cases are written on the basis of requirements and functionality of the software application. Writing test cases is one of the major and most important activities which any tester performs during entire testing cycle. The approach for writing good test cases will be to identify, define and analyze the requirements.
When you begin writing the test cases, there are few steps which you need to follow to ensure that you are writing good test cases. The first step is to identify purpose of testing. You need to understand requirements to be tested. The second step is to define the measurement criteria for testing which will include defining testing methods, test schedule and to plan for required skills and tools. The next step is to define how to perform testing. This will include defining Test Scenarios.
To write good test scenarios you should be well versed with familiar with the functional requirements. You need to know how software is used covering various operations. The test cases should be written to cover the functional as well as non-functional requirements. In addition, test cases should comply with the relevant rules of writing and norms.
Test Case Development Principles
Test case design principles include:
1) Specification principle: The test cases should be designed to try to fail the written software. They should be based primarily on written requirements specification and related technical specification documents. This can be achieved by scenario test cases and basic test cases.
2) Full coverage principle: Test cases should be written to provide full coverage of test points of the main functionality requirements based on requirement specifications and related technologies. The boundary test cases help in achieving the maximum coverage along with scenario test cases and basic test cases.
3) Comprehensive principle: Test cases should cover the scenarios for comprehensive testing and evaluation of the software application. This can be achieved via negative test cases.
Test case preparation should meet specific quantitative requirements which include the following:
(1) The higher priority level of function points and the functionality which will be often used by the users of the application, functionality related to the core of the system should have test cases which provide 100% coverage.
(2) The functionality related to system end-to-end functions and interfaces to other systems should have test cases which provide 100% coverage.
(3) Test cases which include normal input and normal business process testing such as including test of illegal data input and exception handling, and the normal operation of the system should account for 20% -30% of the total number of test cases.
(4) Test cases including localization characteristics and system localization testing should account for 20% -30% of the total number of test cases, unless focus of testing is only localization testing.
Test case execution
The first for tester should be to analyze goal of testing and define the test requirements coverage. The focus of testing should be on business objectives, business complexity, and the cost of failure. The technical complexities should not dictate the testing focus. Risk based testing approach provides a critical level of objectivity in determining what things to test by using a combination of business and technical requirements to prioritize the testing process. This ensures that the most important functions of an application are always tested first, regardless of how limited the testing time frame or scope might be.
In a perfect world, all applications would be completely tested, in all possible scenarios and environments, before the application is released into production (regardless of whether it takes weeks or months to complete 100 percent testing). However, with the limited time allotted for testing, usually testing group focus on testing the technical areas of an application that are most likely to fail, without considering how those areas match up with the most critical business requirements of that application.
The tester should define risk heuristics approach for performing testing. The prioritization should be based on the areas which could lead to finding defects. These areas include:
• Testing of new features as chances of failure in newly added features are high.
• Testing of features involving new technology and new concepts which can lead to new mistakes.
• Testing for features implemented by new developers on the team. During learning curve chances of committing mistakes due to ignorance are high.
• The changed code can break old code hence is a good target for tester to find defects.
• The last minute changes, rushed work and last minute code check-ins lead to mistakes.
Test case execution results
The test case coverage is a function of the ratio of test cases covering functional testing requirements. Test case execution rate is defined as the ratio of the total number of the test cases and test cases that has been executed.
The coverage of test cases should reach to 100%, that is, test cases must cover all of the test requirements. Test case execution rate is a measure of the efficiency of the tester. In general, when the test is completed, the rate of execution of the test cases should reach 100%. This 100% coverage can be achieved only after getting the build or latest code drop wherein all the defects are fixed and there are no defects in the application which will result into test interruption for specific functionality. The defects found can be traced back to the specific usecase and the requirement by traceability matrix.
Test case maintenance
The version of the software product keeps on changing with every software upgrade. With every new release the test suite gets impacted. Hence, the test suite is also required to be constantly updated and maintained to make it consistent with the changes in the product. The following reasons may lead to changes in test cases:
• Changes in the software requirements: Software requirements change could lead to changes in the functionality of the software application. Usually, change management process is followed to maintain the changes in the code, similarly testing team should follow the change management process to maintain the test suite.
• Changes in testing goal and requirements: Based on the changing market demands or latest technologies, it may be required to test software to ensure that it is working fine for the upgrades. For example, new mobile platform, new browser version compatibility testing. Thus, it may require updating the test suite to cover these scenarios.
• Missing test cases: During testing, the tester may come up with the scenarios for which the test case does not cover all the required functionality. Hence the corresponding test cases should be created.
• Production defects: After releasing the software in the production, the users may report defects. These defects may indicate certain areas or functionality of the application where testing is not comprehensive due to lack of sufficient test cases. This results in the need to supplement or modify test cases.
For maintenance of test suite, testing team should perform following steps:
• Remove obsolete test cases–The functionality change could lead to new requirements, thus making original part of the test cases no longer valid. Hence, with every change in requirements the test cases that are no longer valid should be removed from test suite.
• Remove redundant test cases – During design phase of test cases, there is a possibility to create two or more test cases performing similar testing. These test cases reduce the efficiency of the regression testing, thus regular removal of duplicate test cases from the test suite is important.
• Add new test cases- Due to the changes in requirements, with cases of omission of defect which are discovered after the release of version and in the situation wherein the original set of test cases does not completely cover the software requirements, the new test cases should be added to test suite.
|< Prev||Next >|