Testing techniques

Testing Techniques: There are 3 types of testing techniques in STLC(System Testing Life Cycle). Documents Testing Techniques White Box Testing Techniques Black Box Testing Techniques (A) Documents Testing Techniques: These techniques are also known as verification testing techniques. The responsible persons use these techniques to review (BRS(SRS(HLD(LLDs There are 3 types of documentation testing techniques. Walk Through: verifying a document from the Inspection: verification of a document for some particular aspect or functionality in the software and concentrating an specific. Peer Review: Requesting peers or colleagues to verify the document. (B) White Box Testing Techniques: These techniques are also known as Glass Box or Open Box or Clear Box testing techniques. These techniques are applicable for programs in Unit Testing and for interface programs in integration testing. There are 4 types of white box testing techniques. Basic Path Coverage Control Structure Coverage Program Technique Coverage Mutation Coverage (C)Black Box Testing Techniques: These are also known as close box testing techniques. These techniques are applicable on the Software builds. There are 4 types of black box testing techniques. Boundary Value Analysis(BVA) Whenever one need to develop the test cases for a range kind of input then it is suggested to use a technique called BVA. BVA says that instead of testing on whole range, just concentrate on the boundaries if at all the boundaries are working fine then one can come to a conclusion then the whole range is working fine. Equivalence Class Partitioning:(ECP) Whenever one need to develop the test cases for huge range of data or a mixture of so many requirements then it is suggested to use a technique ECP. Equivalence Class Partition says that divides the inputs into different classes and then write the test cases for each class separately. Decision Tables State transmission diagrams Error guessing System Testing Process In the above diagram shows the system testing process in an organization. To decrease the cost of testing in an organization, small & medium scale organizations maintain a separate testing team only at the system testing stage. ( In the system initiation stage the Project manager or Test Manager initiates the System Testing process and prepares a Test Strategy document. ( In the System Test Planning Stage the Team Leader uses the Test strategy document as input and prepares a Test Plan Document. ( In the System Test Design Stage the Test Engineers prepare test scenarios, Test Cases, automation programs etc., and get prepared for actual testing on the software build. ( In the System Test Execution Stage the Test Engineers execute the tests on the software build. ( After the testing team is satisfied that all major defects are closed and the software is functioning as per requirements, the testing team concludes testing on the build. Development Process Vs System Testing Process: Software Bidding Kick Off Meeting PIN DOC Requirements Gathering (BRS) Analysis & Planning (SRS & Project Plan) (Developers) (Testers) Software Design (HLD & LLD’s) System Test Initiation Coding & Unit Testing System Test Planning Software Integration & Integration Testing System Test Design Test Reporting Defect Fixing System Test Execution Modified Software System Test Closure UAT Release & Maintenance System Testing Principles Testing shows the presence of defects in a software build i.e., the purpose of testing is to show the presence of defects and not their absence. Exhaustive testing is impossible. (Example: The Test Engineer can’t apply testing on a software functionality with all permutations & combinations of inputs). Pesticide Paradox: If the same tests are repeated again & again, generally the same set of tests can’t find new defects. Due to this reason, the Test Engineers review and revise tests regularly. Early Testing: In general, the system testing stage comes after coding and integration testing. But to save time, in testing, the Test initiation, planning and design stages of system testing are completed before completion of integration testing. Defect Clustering: To improve the capability of developers, the Test Engineers maintain a repository with complete details of defects. Testing is Context Dependent: Testing is done differently in different contexts. Example: e- commerce software is different from a game software testing. Absence-of-errors fallacy: finding and fixing defects doesn’t help if the software build is unusable to users. Challenges in System Testing: Theoretically testing should be done in a formal way but due to risks or challenges testing may be done in informal ways or exhaustive testing. In exhaustive testing we perform testing using every element in the set of test data but it is not suggestible nor is it possible to perform exhaustive testing all the time. In case of formal testing / optimal testing the Test Engineers perform system testing using formal techniques in a detailed manner. But in this case they don’t Test the project with every element in the set of test data. Rather they test using a few elements of the test data which are representatives of the entire set. In case of ad-hoc testing or informal testing the Test Engineer’s break the formal rules and start testing in an informal way because of risks or challenges. From testing principles, exhaustive testing is impossible. Due to this reason, the testing teams conduct Optimal Testing or Planned Testing. But sometimes, the testing teams conduct AD-HOC TESTING or Informal Testing due to risks or challenges. There are three styles of testing 1. Exhaustive 2. Optimal 3. Ad-Hoc testing By Separate Testing Team Exhaustive Optimal (formal) AD-HOC (Impossible) (Possible & Necessary) (Possible & Informal) In general, the testing teams conduct system testing in optimal way. Sometimes, the testing teams conduct system testing in AD-HOC style due to risks or challenges. These are some sub styles in AD-HOC Testing: Monkey Testing: Due to lack of time, the testing teams conduct system testing on the main functionalities instead of all the functionalities. This style of system testing is also known as Chimpanzee Testing. Buddy Testing: Due to lack of time, the Test Engineers group with developers to perform software development and testing simultaneously. This style of system testing is called Buddy Testing. Exploratory Testing: Due to lack of proper documentation, the Test Engineers depend on the past experience, group discussions, internet browsing, previous versions of the same software and video conferencing with real customer or model customers, together complete information regarding customer requirements. Iterative Testing: It is also called as Data Driven Testing. From this testing style, the Test Engineers repeat system testing on the same software build more than one time with multiple inputs or test data. Pair Testing: Some Times, the test lead groups a senior tester and a junior tester to share knowledge during system testing. This style of testing is called Pair Testing. Agile Testing: Due to sudden changes in customer requirements the Test Engineers modify tests with respect to change in requirements. The repetition of modified tests on modified software is called Agile Testing. Bebugging: To estimate the efficiency of the Test Engineers, the developers add known defects to the software build and then release that software for testing. If the tester couldn’t find the defects in the software, then the Project Management provides training sessions to testers. Note: Exhaustive testing is impossible and ad-hoc testing is informal so the testing teams usually plans for Optimal Testing. System Test Initiation: In a software development life cycle, the system testing process starts with system test initiation. In this stage, the Project Manager Category people prepare a Test Strategy Document. This document is also known as Test Methodology or Test Approach. SRS Document by PM Test Strategy Document Input Output Components of the Test Strategy Document: 1. Scope & Objective: The purpose or need for testing in the current project and the scope of testing in the current project or discussed in an overview. 2. Business Issues: The budget allocation for system testing. 100% (Project Budget) 40% for Testing 60% for Development 3. Roles and Responsibilities: In this project, the names of jobs in a testing team and their responsibilities. 4. Communication and Status Reporting: The negotiation between every two jobs in the testing team. 5. Test Responsibility Matrix (TRM): The selection of reasonable system testing topics to be applied with respect to requirements and risks in the project. System Testing Topic Yes/No Comments Functional Testing Yes -- User interface Testing Yes --- Manual Support Yes -- -- -- -- Inter System testing NO No need to share others softwares Data volume Testing Yes -- Multi Languity No No Need with respect to requirements Security Yes -- Load Testing No Needed, but lack of funds This is also called Test matrix. 6. Test Automation & Testing Tools: The need of automation testing in this project and the available testing tools in our organization. 7. Defect Reporting & Tracking: The required negotiation between Test Engineers and developers to report and track defects. 8. Testing measurements and metrics: To estimate the test status, the Project Manager provides a set of measurements and metrics to the testing team. Measurement is the basic unit and metrics is a compound unit. 9. Risks and Solutions: A list of challenges and the corresponding solutions to overcome. 10. Change and configuration management: For future references and changes, the testing team has to prepare a test base to store all testing deliverables. 11. Training Plan: To understand the customer requirements, the corresponding testing team involves in training session. The project manager prepares the plan for these training sessions with respect to the complexity in customer requirement or with respect to the usage of a new testing tool. II) Test Planning: After finalizing the Test Strategy, the corresponding PM selects an efficient person as the test lead. This selected Test lead follows the below approach to produce the system test plan as shown below. Test Strategy Document by TL Test Plan Input Output From the above model the testing plan model consists of four internal stages. ( Testing Team Formation ( Tactical Risks Identification (Test Plan Document Preparation (Reviewing the Test Plan (a)Testing Team Formation: In general the test planning process starts with testing team formation. In this stage the Test Lead depends consider the below factors to form a good testing team. (Project Size (Number of functionalities) ( Availability of Test Engineers on bench (Availability of resources for testing (ex: Testing Tools) ( Test Duration (b)Tactical Risks Identification: After completion of the testing team formation, the corresponding test lead analyses team level risks. Example: (Lack of knowledge of Test Engineers on the project domain. (Lack of Time (Lack of resources (Lack of Documentation (Delays in Delivery (Lack of Developers seriousness (Lack of Communication (In any organization developers and Test Engineers are the rivals) (c)Test Plan Preparation: After analysis of risks, the corresponding Test Lead prepares a detailed Test Plan with respect to the established testing team and analyzed risks. Test Plan Format: (IEE829) (Institute of Electrical and Electronics Engineers) 1) Test Plan ID: The unique name for a Test plan Document. 2) Introduction: The summary of current project details. 3) Test Items: The names of all modules or functionalities in the current project. 4) Features to be tested: The names of modules or functionalities to be tested. 5) Features not to be tested: The names of modules or functionalities that we are not testing in the current project. 3, 4, 5 together or called what to test? By Project Manager (TRM) 6) Test Approach: Selected list of system testing topics to be applied on selected Modules in the Project. By Test Lead 7) Test Environment: Required Hardware and Software to be used for testing. 8) Entry Criteria (To start testing): To start test execution, the following activities should be completed. (Test Cases prepared and reviewed (Test Environment Established (Software build received from developers 9) Suspension Criteria (To interrupt test execution): (Test Environment Failed (Showstopper in Software build (Pending Defects or Quality gaps or more 10) Exit Criteria (Stop Testing): ( All selected modules or functionalities are tested in this project ( All major defects closed (Test duration exceeded (Testing funds depleted 11) Test Deliverables: The names of testing documents to be prepared during testing by selected Test Engineers. Example: Test Scenario, Test Cases, Automation Testing Programs (Optional), Test logs, Defect Reports etc,. 6-11 (indicates How to test? 12) Staff and Training Needs: The names of selected test engineers in the current project testing. 13) Responsibilities: Work Allocation to selected Test Engineers in terms of modules or testing topics. EX 1: All reasonable tests to be applied on specified modules in the project. EX 2: Specific testing to be applied on all modules in the Project. 12-13 (indicates who to Test? 14) Schedule: The Dates and Time to perform testing. 14)(indicates who to Test? 15) Risks and Solutions: The analyzed risk and the solutions to overcome. 16) Approvals: The approvals of the project manager and test manager along with confirmation of the Test Lead (The signatures of the Test Lead & Project manager). (d) Review the Test Plan: After completion of a detailed Test Plan Preparation, the corresponding Test Lead reviews that planned document for correctness and completeness. In this review meeting the Test Lead Concentrates on the below factors. (Test Plan with respect to requirements or modules (Test Plan with respect to resources in test environment (Test Plan with respect to expected risks After successful test plan review, the corresponding Test lead conducts training sessions to the corresponding selected Test Engineers. In these training sessions, the corresponding BA and Domain or subject experts (outsiders) share knowledge with Test Engineers on the Project requirements. III) Test Design: After completion of training session the corresponding Test Engineers concentrate on test design to prepare test scenarios and test cases. They prepare these documents individually on the modules or functionalities assign to them. * Test Scenario specifies a unique test condition to be applied on our software build. * Test Case specifies a test scenario along with details and required procedure. There are 4 methods to design Test Scenarios & Test Cases. 1. Functional specification based Test Design 2. Use Case Based Test Design. 3. User interfaced requirements Based Test Design. 4. Non-Functional requirements based Test Design Systems testing on software build Functional Non-Functional Functional requirements based (SRS) Use-case based Usability Testing others 1. Functional specification based Test Design: To prepare Test Scenarios and Test Cases for functional testing on the responsible modules in the project, the Test Engineers use this method. In this method the Test Engineers follow the below steps. Step 1. Collect all responsible functional specification from the SRS with respect to the responsible modules in that project. Step 2. Select one specification from the list. Step 3. Study that functional specification to identify the required inputs, expected flow, expected output, entry point, exit point, alternative flows and the available rules. Step 4. Prepare test scenarios depending on the above identified information about the corresponding functionality. Step 5. Review the test scenarios for completeness and correctness and then implement the test scenarios as test cases. Step 6. Go to Step2 until all responsible collected functional specifications are studied. Functional Specification 1. A login process allows users to authenticate using User ID & Password. The User Id object takes alphanumeric in lower case from 4 to 16 characters. The Password object takes alphabets in lowercase from 4 to 8 characters. This login operation is providing “cancel” button operation to close the login screen at any instance. Now Prepare Test Scenario. Solution: Functional Specification 2. In an insurance company the users are applies for different types of insurance policies. If a user selects type ”A” insurance in the available test, then our software build asks for the age of that user. The age value should be greater than 16 years and less than 80 years. Prepare test scenario and test cases. Solution: Functional Specification 3: In a shopping application users can apply for different types of items purchase order allows the user to select the item number and to enter the quantity, our software build allows quantity up to 10 units after selection of item number and entry of quantity, our software build returns the price of item number and entry of quality, our software build returns the price of one item and the total amount. Prepare the test scenarios and test cases. Solution: Functional Specification 4: A door opens when a person comes in front of the door then that door closes after the person has gone in side, Prepare the test scenarios. Solution: Functional Specification 5: In an ebanking application users are connecting to a bank server through a login process. This login allows the below fields to be field by the users. Authentication code ( 6 digit Number Area Code ( 3 digit number or blank field Prefix of account number (First Part) ( 3 digit number & doesn’t start with 0 & 1. Suffix of account number (Second Part) ( 6 digit Alpha Numeric. Purpose ( Cheque deposit, Money Transfer, Mini statement, Bills Payment prepare test Scenarios for this login process. Sol: II) Use Case based Test Design: BRS SRS Test Scenarios HLD & LLDs (Functional + Non- Functional Requirements) Coding & Unit Testing (BA+TL Prepares Use Cases) Integration & Integration Testing Test Cases (Software build) Functional Testing Sometimes the customer requirements are complex and sometimes current project is outsourced project. In both the above situations, the testing team gets use cases from the project management instead of functional specifications. The use cases contain greater detail compared to functional specifications. From the above diagram, the BA & Test Lead category people translate the functional specifications in to use cases. Depending on these use cases the Test Engineers prepares test scenarios and test cases for functional testing. Steps: 1. Collect all responsible use cases with respect to the allocated work in the current project. 2. Select one use case from the list. 3. Study that use case to identify the required inputs, expected flow, expected output, entry point, alternative flows and the available rules in the corresponding functionality. 4. Prepare test scenarios. 5. Review the scenarios for correctness and completeness and then convert those scenarios in to test cases. 6. Go to Step 2 until all responsible use cases are studied. Example for a “USE CASE”: 1. Use Case ID: UC_Login 2. Description: A login functionality is authenticating users to connect to our software build. 3. Actors: The registered users give User ID and Password to do login operation. The User ID field accepts alpha Numeric in lower case from 4 to 16 characters. The password takes alphabets in lower case from 4 to 8 characters. 4. Pre condition: Use registration is mandatory before login. 5. Events List: Events Expectation Activate login window and then fill User ID and Password, Click OK Button Next window for valid users and error message for Invalid users. Click Cancel Window closes at any instance 6. Post Condition: Logout is compulsory after successful login. 7. Activity Flow Diagram: Invalid Valid 8. Proto Type: 9. Alternative Events: None 10. Referenced Use Cases: UC_registration and UC_logout. Now Prepare Test Scenarios: Solution: III)Common Scenarios for Usability Testing (Non-Functional): Scenario 1: Verify Spelling throughout all the screens of the Software build. Scenario 2: Verify Init CAP of labels throughout all the screens. Scenario 3: Verify uniform font of labels throughout all the screens. Scenario 4: Verify uniform size of labels throughout all the screens. Scenario 5: Verify the alignment of objects throughout all the screens. Scenario 6: Verify uniform line spacing between attached text and objects throughout all the screens. Scenario 7: Verify grouping of related objects throughout the screens of the build. Scenario 8: Verify borders to functionally related items throughout all the screens. Scenario 9: Verify the default object in every window of the build. Scenario 10: Verify the existence of operations like OK & CANCEL in every window (to go to the next step or to cancel the operation) Scenario 11: Verify icons throughout the screens of the build (with respect to the meaning of the Icon image) Scenario 12: Verify tool tips of icons in every screen. Scenario 13: Verify the appearance of multiple data objects throughout all the screens. Scenario 14: Verify scroll bars when the list of items is larger than the size of the screen. IV) Non-Functional Requirements base Test Design: After completion of functional and usability test design, the Test Engineers concentrate on Non-Functional test design except usability. Examples: Compatibility, Configuration, Inter System, Installation, Data Volume, Load, Stress, Endurance etc. Sample Test Scenarios for Compatibility Testing: Test Scenario 1: Verify login operation on Windows NT, Windows 2003, Windows XP, Mac o/s etc. Test Scenario 2: Verify Mail open operation on all the above Platforms. Test Scenario 3: Verify Login and logout operation on all the above platforms. Sample Test Scenarios for Load Testing: Test Scenario 1: Verify login operation in customer expected platform or environment with customer expected load. Customer expected configuration means the capacity of the processor, RAM, Bandwidth of cables, O/S etc. Test Scenario 2: Verify submission of a form by all the people according to customer expected load. Test Scenario 3: Verify logout operation in customer expected configuration and load. Test Design Review: Note: After the completion of functional and usability test design, the Test Engineers focus on Non-Functional aspects and prepare test scenarios and test cases for all the requirements wherever applicable. After preparation of test scenario and test cases the Test Engineers review these documents for correctness and completeness. This review usually takes place through a formal meeting where the BA and Test Lead play the key roles in the presence of a few reviewers. IV) Test Execution: After completion of review of test scenarios and test cases and modifications in the documents wherever necessary, the testing team concentrates on test case execution on the software build to perform system testing. This test execution starts after a formal meeting between the testing team and the development team. (a) Formal Meeting: In this meeting the testing team and the development team discuss the below issues for future process. ( Initial software build ( Defect Reporting Processing ( Build versions to distinguish between the old build and the modified build. Note: Difference between Build version and Release version Development Team Testing Team Customer 1.0 1.1 1.2 1.3 1.0 Build Version Release Version The version numbers that change within the organization between the development and the testing team during the development life cycle are known as Build Version. The version number of the verified software that is released at the customer’s site is called release version. (b) Configuration Repository (CR): The Project Manager Category people create a secured storage in the organization level server for each project this secured storage area in the sever is called configuration repository or Project Configuration Repository. Testing Team Developers From the above diagram the CR of a Project consists of 3 secured positions. ( Development Base: Consists of all development related deliverables like BRS, SRS, HLD, LLD Unit Test Cases, Integration Test Cases etc. This development base is created and organized by developers. It is accessible to Test Engineers and Project Management with limited permissions. To create and organize the development base, the developers use a software like Rational Clear Quest. This is a configuration management tool. ( Soft Base: Consists of developed programs with integration as software build. The developer crate and organize the soft base with various versions of the build before and after fixing defects. The version numbering system helps the testing team to identify the modified build. For this build version control the developers use version control tools like Visual Source Safe (VSS( Micro Soft’s Product) ( Test Base: Consists of all testing related documents like test strategy, test plan, test scenario, test cases, automation programs, test logs, development reports etc. This test base creation and organization is done by the Test Engineers and it is accessible to the development team and the project management with limited permissions. To create and organize the test base, the testing teams use test process management tools like Quality center. (C) Test Environment Establishment: Before receiving the initial software build from the soft base, the testing team creates the test environment with the required hardware and software for testing. This test environment is provided by hardware team or infrastructure team. Server Development PM Team Team (d) Level of Test Execution: After completion of test environment establishment with the help of hardware team, the testing team downloads the initial build form the corresponding project soft base. After downloading the initial build the testing team concentrates as 4 levels of test execution. Development Team Testing Team Initial Software builds Level 0 or Sanity Testing Report Instability of Build Stable Build Defect Solving Defect Reporting Level 1 Testing or Real Testing Re-Report Modified Build Level 2 or Regression Testing Level 3 or Finale Regression Testing (e) Levels of Test Execution vs. Test Cases: Level 0 (Sanity) on initial software build Selected P0 Test Cases (Basic Test Cases like window is opening or not?) Level 1 (Real Testing) on Master build All P0, P1 and P2 Test Cases. (Ex: Master Copy) Level 2 on Modified build Selected P0 and carefully selected P1 Test Cases. (Regular Regression Testing) (Modified Test Cases) Level 3 on High Defect Density Areas carefully selected P0 and P1 Test Cases w.r.t High defect density (Final Regression Testing) (f) Level 0 (Sanity Testing) : After downloading the initial build from the corresponding project soft base, the testing team conducts Sanity Testing on that build through the execution of basic functional test cases (P0)(High Priority). In this checking the testing team concentrates on the below factors. ( Understandable to Test Engineers: Screens understandable by testers ( Operatable by Test Engineers: Screens operatable by testers ( Observable by Test Engineers: Screens and operations observable by testers. ( Controllable: Screens enabling do & undo task by testers. (Do the test, undo the task) ( Simplicity: Easy to operate for Test Engineers ( Consistency: Consistent flow in build ( Maintainable: No need of regular re installation. ( Automatable: The changes to use testing tools for automation testing. From the above factors, sanitary testing is also called as testability testing or tester acceptance testing or builds verification testing. If the initial build is not satisfying the above factors then the testing team rejects the build for the testing. If the build is satisfying the above factors then the testing team concentrates on Level-1 testing, which is real test execution to detect defects in the testable build or stable build. (f) Real Testing: After receiving this stable build the testing team executes all the test cases (P0, P1 & P2) in manual or automation style. Test Cases Automation Programs Testing Tools Test Engineer Test Cases Manual Testing Test Engineer Automation Testing From the above diagram the Test Engineers conduct testing on a software build either manually or using automation. Automation testing is optional because many organizations cannot provide automation for all the projects. Either in manual or in automation, testing the Test Engineer runs test cases batch by batch and in every batch test by test. In this level 1 test execution, every Test Engineer prepares a test log document with test results. Test Log Document Executed by : Sharath Date: 24-05-11 TC ID Result Defect ID Comments TC_name_001_login TC_Name_002_Login TC_Name_003_Login --- TC_Name_005_Login TC_Name_006_Login Fail Fail Passed -- Fail Blocked Defect 001 -- -- -- Depends on TC_Name_005 which failed From the above example the test log document maintains 3 types of test results. ( Passed (Failed (Blocked ( Passed: All actual results of a test or equal to the expected results from the software build. (Failed: At least one actual value of the test is not equal to the expected value. (Blocked: The corresponding test case execution is post phoned due to the failure of the previous test case on which the current test case depends. (V) Defect Reporting and Tracking: In level 1 real testing on a software build, the Test Engineers get mismatches between the expected value specified by the SRS document and the actual value obtained from the test case execution. This mismatch is called defect or issue. a) Defect Tracking Team: Test Engineer Defect Report DTT (Defect Tracking Team) NO Yes Yes Yes Yes (b) Defect Report Format: After detecting a defect in the software build, the Test Engineer reports that defect to the defect tracking team in the formats specified by IEEE829. (1) Defect ID: The unique number or name for future reference. (2) Defect Description: Summary of the detected defect. (3) Build Version ID: The version number of the software build (this defect is detected in this version of the build. (4) Feature: The name of the module or functionality (This defect is detected in this module of the build) (5) Test Case ID: The id of the failed test Case. (6) Reproducible: YES/NO ( Yes : Defect is appearing every time during retesting ( NO: Defect found only once or found occasionally (7) If YES: reproducible, attached test procedure or script. (8) If NO: Attach strong reasons for the defect or a screen shot. (9) Severity: The severity of the defect with respect to the functionality. ( High severity: Unable to continue test execution on that functionality without resolving this defect. ( Medium Severity: Able to continue test execution but mandatory to resolve the issue before releasing the software builds. ( Low: Able to continue test execution we may or may not the resolve this issue. (10) Status: New/Reopen ( New: Reporting the defect for the first time. ( Reopen: Reporting the same defect for second time (reporting a defect that was reported earlier) (11) Reported by: Name of the Test Engineer (12) Reported on: Date of report (13) Assigned to: DTT (in some organizations the development team or a specific developer)(The idea of the responsible person to receive this defect report-Usually defect tracking Team). 914) Suggested Fix: Suggestions to resolve this issue (Functioality aspects/code related aspects). This activity is optional. After filling the defect report as above the corresponding Test Engineer reports that defect to the DTT using a mailing software like MS-Out Look. The Test Engineer sends a copy of this defect to the test lead (some times to the customer’s site also). After receiving the defect report from the Test Engineers the tracking team conducts a review meeting to categorize the defect as shown below. (C) Test Case related defect fixing: Test Case RUN (1) Defect (2) Retesting Report Modify the Test Case (6) DTT Test Engineer Modifies the Test Case (5) Test Engineers Assigned Categorized the defect Accepted (BA +TL) (4) As test case related defect (3) If the defect reported by the Test Engineer is accepted as test case related defect, then the responsible Test Engineer will fix the defect with the help of test lead and BA and executes the modified test case on the software build. (d) Test Data related defect fixing: If the defect reported by the Test Engineer is accepted as test data related defect, then the responsible Test Engineer changes the test data with the help of test lead and BA and executes the test case on the build with valid test data. Test Case RUN (1) Defect (2) Retesting Report Modify the Test Data (6) DTT Test Engineer Modifies the Test Data (5) Test Engineers Assigned Categorized the defect Accepted (BA +TL) (4) As Test Data related (3) (e) Test Environment Related: Test Case RUN (1) Defect (2) Retesting (6) Report Test case in Modify the Test Environment DTT Infrastructure team modifies the test environment team (5) Infrastructure Team Assigned Categorized the defect Accepted (4) As Test Environment related (3) If the defect identified by the Test Engineer is categorized by the DTT as a test environment related then the DTT assigns to defect to the infrastructure team and the infrastructure team modifies the test environment now the Test Engineer executes the same test case in the modified environment. (f) Code related defects: If the defect reported by the Test Engineer is accepted as code related defect, then the responsible team lead concentrates on the software code changes with the help of programmers. Test Case Run (1) Defect (2) Report DTT TL + Developers Assigned Categorized the defect Accepted (4) as code related (3) NO YES Note: Usually the development team conduct Smoke Testing on the software build before giving the next version of build to the testing team. (G)Defect Life Cycle: Phases Status NEW Assigned Analysis / Open Reopen Resolved Verification Closed (VI) Test Closure: After completion of all reasonable tests and closure of defects, the testing team conducts a review meeting, in this meeting the test lead and the BA participate in discussions with the Test Engineers to estimate the completeness and correctness of testing. In this review meeting the testing team follows on the below factors. (a) Coverage Analysis: ( Requirements based coverage with respect to SRS ( Testing topics based coverage with respect to Test Strategy Document (b) Defect Density: Modules % density of defects A 20% B 45% ( Highest Defect density, Module B needs Final Regression Testing C 15% D 20% (C) Analysis of deferred defects: Whether the defect fixing is postphonable or not? After completion of test closure review, the testing team concentrates on level 3 or final regression testing or post mudroom testing. In this phase the testing team repeats the previously passed tests on high defect density modules in this build. New Defect If the testers detect a new defect in the final regression testing is called Golden Defect. After fixing and closing the golden defect the testing team concentrates on UAT. (VII) UAT: To collect feedback from the real customer or model customer the project management concentrates on 2 types of UAT. Alpha Testing ( Beta Testing In this phase the testing team also involves partially to talk to real customers or model customers. (VIII) Sign Off: After Completion of UAT, the corresponding testing team concentrates on sign off to get relieved from the current project. In this stage the test lead collects all testing deliverables in the current project from the corresponding Test Engineers. Test Strategy Test Plan Test Scenarios Test Cases Automation Programs Test Log Defect Reports Requirements Traceability Matrix (RTM) Requirements ID Test Case ID Result (passed/Failed) Status(Closed/Differed) The RTM consists of Mapping between requirements and Test Cases in order to verify if all the requirements are tested by the corresponding test cases. After completion of collection of the Test Deliverables, the Test Lead relives the corresponding Test Engineers from the current project. Sometimes a few Test Engineers are selected for release team to release the soft ware in the customer site. A few of the Test Engineers are selected for CCB(Change Control Board) for maintenance. COMPUTECH INFO SOLUTIONS WWW.COMPUTECHIS.COM By SHARATH #401, 4th Floor, ADR Estate, Above Bank of India, Bhagya Nagar Colony, Opp.: KPHB, Hyderabad-500072 Phone: 040-66174448, 9000011489, www.computechis.com System Test Design System Test Planning System Test Initiation Defect Reporting System Test Execution System Test Closure System Testing System Test Initiation System Test Planning USER Data Base Next Window Error Message LOGIN Cancel OK Login User ID Password CR /PCR Development Base Test Base Soft Base Test Base Soft Base Development Base Test Environment Stable Build Stable Build Rejects or requests for additional Information Reasonable Test Case related TE asked to modify Test Case Assigned to developers Programming related Test Environment TE asked to change Test Data Test Data Related TE changed with the help of infrastructure team S/w Build S/w Build S/w Build Build Cause Effect Analysis Release the s/w build to the testing team with version no & release note Perform Changes in code & conduct smoke testing Need changes in Design Design Changed by the designer Assigned to one of the developers Enter a new defect into the DTS Analyze the Defect FIX Close the Defect Sent back to the Test Engineer for verification Reject Select high defect density modules/ requirements in the build Plan for final regression testing Perform Final Regression Testing Effort estimation in person per working day or per hour Defect Report