135509-133967 - Testing Development Life Cycle
135509-133967 - Testing Development Life Cycle
135509-133967 - Testing Development Life Cycle
Prepared by
Associate 1 Emp num Project Email : Kirthiga Muthuswamy : 135509 : USAA Claims Testing : Kirthiga.muthuswamy@tcs.com
Confidentiality Statement
This paper is internal to TCS only and will not be used at places other than TCS offices. This will be discussed only with the TCS resources .Failure to adhere to these policies can be taken as Security violations .Copy rights to this document without the approval of TCS management is strictly prohibited. Printing is not allowed.
Abstract
The testing process is a key aspect of Software product quality and becomes very crucial in large re-engineering projects. The continuous monitoring of the testing process and its improvement using a phased approach of testing allows the establishment of an adequate level of confidence for the successful release of software products. This white paper details the various phases in the testing life cycle.
Confidential
CONTENTS
CONTENTS........................................................................................................................................................2 1.INTRODUCTION...........................................................................................................................................3 2.STRATEGY.....................................................................................................................................................4 3.PLANNING PHASE.......................................................................................................................................6 4.PREPARATION PHASE...............................................................................................................................7 Test Conditions...........................................................................................................................................7 Test Scenarios............................................................................................................................................8 Test Cases...................................................................................................................................................8 5.EXECUTION PHASE..................................................................................................................................11 6.IMPLEMENTATION PHASE ...................................................................................................................13 7.CONCLUSION..............................................................................................................................................14 8.REFERENCES..............................................................................................................................................15
Confidential
1. Introduction
Software testing is the process used to identify the correctness, completeness, security, and quality of developed computer software. Testing is a process of technical investigation, performed on behalf of stakeholders, that is intended to reveal quality-related information about the product with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding errors. Testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behavior of the product against a specification. An important point is that software testing should be distinguished from the separate discipline of software quality assurance, which encompasses all business process areas, not just testing.
Confidential
2. Strategy
The testing strategy is based on the following concepts
Platform based on which the software is built Line of business End User Demographics - For example Systems intended to be used by customer over internet versus the system used by internal enterprise. At a higher level the testing process can be divided into three phases: Planning, Preparation & Execution. Figure 1: Phases of Testing
Confidential
Testing Development Life Cycle Figure 2 : Testing in the context of the entire development process
Define Requirements
Perform Analysis
System test Release Test Prod Validation Test Performance Test Regression Test
Migration: Business demands and technology challenges sometimes create the need for
migration of applications or databases from one environment to another, either to improve operational efficiency or to manage risk .The test strategy that could be followed for a project involving migration includes: Analysis of the current environment and system. Ascertain migration options (What part of the data needs to be migrated). Analyze whether the migration affects the current system and coupling with other related components. Preparation of documents related to the field-to-field mapping of the fields being migrated.
Confidential
3. Planning Phase
The Planning phase provides an opportunity for the tester to determine what to test and how to test it. During the Planning phase, the system test plan is drafted where the decision on the number of testers and the number of testing artifacts which are to be delivered is taken. The testing artifacts created for system testing include: Test Conditions Test Cases Test Scenarios Number of test conditions = Total of all Stated Requirements. The output of the planning phase is a set of detailed test plans such as Unit test plan, Integration test Plan, System test Plan, and Regression test plan. Table 1: Planning Phase-Best Practices Number of testers required depends on the number of test conditions to be developed and executed. The test condition development should be categorized based on the functionalities being tested The development effort for each category of Test condition/Test Case must include: *Test condition/Test case creation *Test condition/Test case review *Test condition/Test case update
Confidential
4. Preparation Phase Highlights Create Test Artifacts Peer Review Business Review Update Test Artifacts
Test Conditions The first step is identification of TEST CONDITIONS from the various requirement artifacts, such as: Use Cases Business Rules Data capture rules Data Matrices UI Analysis specifications UI Specification Model Non-functional requirements
A Test Condition can also be defined as a Testing Unit. Each stated requirement is framed as a test condition. The test conditions are maintained using a Test management tool (ex Mercury Test Director)
Confidential
Total number of test conditions = Total of all Stated Requirements A test condition is a smallest unit of check for a given requirement. There is a test condition for each type of requirement as depicted in the table below. Table 2: Examples of test conditions S. No. 1. Type of Requirement Business Rules Test Condition Validate, for a Handle total loss task, only one child task can be in WIP status at a time 2. Page behaviors Customer Details 1st-Validate on click of Next Button Customer Details page (second pass) should be reloaded when Existing Customer is No
Test Scenarios The different business scenarios (the ways in which the end user will use the application) to test the application is arrived by the testing team (also with inputs from business testers, business partners, etc.) Based on the use cases, all possible BUSINESS SCENARIOS are identified. A business scenario is an imagination of a certain circumstance that happens in the daily business operations. It is represented by high-level or key information governing the scenario. These are identified by business experts based on their experience and the use cases
Test Cases A key aspect of testing is selecting test cases. A test case is a set of inputs and circumstances in which the system runs, plus an output or result which it should produce in those circumstances.
Confidential
Each scenario is considered a test case. The test cases created by placing logical groups of test conditions together based upon predefined business scenarios and process flows. Describes an input, action, or event and an expected response Contains test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results Help find problems in the requirements or design, better to write early.
A test case carries end-to-end flow of events for the business scenario it addresses and the data pertaining to the scenario. It also has an expected result. The test conditions are mapped to test cases as applicable. In case there are test conditions not applicable to any of the business scenario, then more business scenarios are identified to cover the remaining test conditions. If there are two business scenarios which cover almost the same set of test conditions then one of the business scenario is removed. At the end an optimized set of business scenarios is arrived at.
Confidential
The Test Conditions development should commence only after the requirements are finalized Ambiguous requirements need to be escalated to the business during this phase. The test condition should be traceable to its corresponding requirement(s). The test condition name should include *An abbreviation of the requirement artifact it is derived from *A brief description of its content The integration test cases should be formulated based on individual screens. System test cases should encompass 80 % of real time scenarios encountered by the end users.
Confidential
10
5. Execution Phase
Integration Testing The purpose of integration testing is to verify that the product satisfies the business requirements. The software product is an integration of different software programs. The software programs are unit tested by the development team before starting the integration test. Generally, integration testing is done in two stages: Screen-level End-to-end Screen-level testing involves testing of an individual screen. All the test conditions pertaining to the screen are tested individually for the expected functionality. This is ad-hoc in nature. Apart from this, parts of the test cases which are relevant to the screen are also executed. By this process testing commences even before the development of the product is complete. But this validation process does not validate the end to end testing of all the business processes. End-to-end involves execution of all the test cases that addresses the entire functionality. Prior to commencement of integration testing, the base data identified in the test cases is added in the database. In case of batch application all required input files are created. This is called as data setup. The software product deployed in the chosen architecture, along with the data setup forms the test bed.
During execution, test conditions may fail. These failures are raised as defects. A defect is non-conformance of the product to a requirement. The identified defects are communicated
Confidential
11
to the development team. They fix the defects and turn over the updated software product for re-testing. Once the execution is complete and all identified defects are fixed, retested and closed, the software product is ready for system testing phase. System Testing System testing is execution of test cases on the software product, similar to integration testing, except that it is carried on by to-be users of the product. Again this is to verify that the software product conforms to requirements and is as expected by the users. Apart from executing the test cases, users also provide random business scenarios to the product and verify the behavior this is called ad-hoc testing. This could also be done in integration testing phase. In this phase only end-to-end testing is carried out. Rest of the steps such as test bed preparation, defect identification, defect management is very much the same as in integration testing. Borland Starteam tool is used for defect management. Generally, system testing is done in two iterations. The first iteration is to uncover defects not detected during integration testing and the second iteration is to make sure all the defect fixes are working fine. More iteration might be needed based on size of the product and the defect count.
Confidential
12
6. Implementation Phase
After the deployment of the tested code in the production environment, validation of the conformance of the product to requirements is known as Release testing. Defect management process is applicable here as well. Release refers to rollout of a new version of the software product to users. Release testing also includes validation of the software product just before every release. The software product is deployed in the exact environment as the one users would have (called as production environment). In Release testing, testers make sure that all other parallel development to interfacing software products has not affected the functionality of software product being released. The test cases used for Release testing are called Regression test cases. These test cases (mostly identified from system test cases) cover the major functionality of the product. Execution of these test cases is called as regression testing. Regression testing checks the health of the product and makes sure that the functionality has not been altered by enhancements and corrections during product maintenance. As the same set of test cases are re-run during every release, their execution can be automated using tools such as Win runner, QuickTestPro etc.
Confidential
13
7. Conclusion
Software testing is an art. Most of the testing methods and practices are not very different from 20 years ago. Although there are many tools and techniques available to use. Good testing also requires a tester's creativity, experience and intuition, together with proper techniques.
Testing is more than just debugging. Testing is not only used to locate defects and correct them. It is also used in validation, verification process, and reliability measurement.
Testing is expensive. Testing efficiency and effectiveness is the criteria for coveragebased testing techniques. Complete testing is infeasible. Complexity is the root of the problem. The main objective of testing is to point out all possible areas which leads to complexity.
Confidential
14
8. References
[1] Brett Pettichords software testers hotlist - http://www.io.com/~wazmo/qa/ [2] Software Testing Best Practices, by Ram Chillarege [3] What Is Software Testing? And Why Is It So Hard? By James A. Whittaker
Confidential
15