Roman Yagodka ISS Test Leader

1. Testing Process Roman Yagodka ISS Test Leader

2. Introduction Simplified Project Lifecycle Model Main Project Stages Contents

3. Testing (as a function of Quality Control) is a necessary part of software development process Test group must be involved at the every stage of development process, not only at the System Testing phase While working closely with developers, test group shall be as much independent as possible Introduction

4. - Project Kick-off - Requirements gathering - Planning - Functional specs - Test Framework - Closure - Postmortem well… - Test Development Simple Project Lifecycle Model Req. & Planning Design Coding Testing Release Time

5. It is the very first team meeting before starting the project Outputs: Project definition (objectives, outputs/products) Team (team members, organisation, training needs) High level plan Detailed plan for the next stage Project Kick-off Req. & Planning

6. Overview of what is need to be tested Comments, Advises and Recommendations about testing activities Customer (if available) Developers Testers Preliminary schedule for the nearest steps in Testing Project Kick-off (cont.) Req. & Planning

7. Process of collecting high-level requirements from customer and/or end-users. Output: Requirement Book is approved by customer (if any) Requirements Gathering Req. & Planning

8. Test team tasks: Check requirements for completeness, consistency and unambiguity (usually done during review) Consider tools and technologies needs Requirements Gathering (cont.) Req. & Planning

9. Project Management Plan Quality Assurance Plan Configuration Management Plan Test Plan Planning Req. & Planning

10. Test Plan includes: Approach Features to be tested Features not to be tested Testing priorities Estimations Environmental needs Planning (cont.) Req. & Planning

11. Functional specifications (FS) are based on high-level requirements from Requirements Book It is the basis for further test development and testing Test team tasks: Check FS requirements for completeness, consistency and unambiguity Check requirements for testability Revise and update testing plans, if necessary Functional Specifications Design

12. Intended for automated testing support, whether of GUI or non-GUI applications Responsibility of the Test Leader and/or senior testers Output: Test Framework Test Procedure document Test Framework Design

13. Testers may co-operate with developers, retrieve prototypes and intermediate builds for test development and correction Informal System testing may be conducted at already implemented functionality Output: Test Cases FS-to-Test traceability Test Development Coding

14. Testing: Non-stop Divided into cycles (build->test->correct->build) Cycles: Formal – all tests are executed to verify all features Informal – partial testing is allowed System Testing Testing

15. Final Test Cycle This is a formal test cycle Before the Final Test Cycle defects trend shall show readiness to final testing No critical defects shall be found at the Final Cycle, otherwise release is postponed All low-severity defects are postponed and workarounds are described in user documentation Test Report Closure Release

16. Post mortem is a project team meeting with the main goal to review the successes and failures of the past project Post mortem report may be used to remind good and bad practices before starting a new project Testers should focus on the following items: Estimations accuracy (defects and test cases count) Test Automation Communication Post mortem Release

17. The process gives the following advantages: Tracking and quantitative measurement ability; Decreasing human factor; Results repetition; Continuous process improvements ability. Conclusion

18. The EndThank You For Attention