1. Introduction to Software Testing

2. What is software Testing? ●Software testing can be stated as the process of validating and verifying the Application to check that it is working as per User Requirements / expectation. ●The Scope of software testing often includes analyzing as well as execution it under various conditions: does it do what it is supposed to do. ●Goal of Testing team is to find issues as early as possible and make sure that they get fixed. 2

3. Testing Principles ●Testing shows presence of issues / problems – Reduces probability of un-discovered issues remaining in the software – Its not proof of correctness ●Even if no issues are found ●Early Testing – Testing activities should start as early as possible in SDLC – Should be focused on defined activities 3

4. V Model User Acceptance Testing Acceptance Test Plan Requirements System Specification System Test Plan System Testing High Level Design Integration Testing Integration Test Plan Low Level Design Unit Testing Unit Test Plan Verification Validation Coding 4

5. V Model Continued ●V Model: It's Verification and Validation model ●It is called V model possibly due to the V shape that is used to depict the model ●Left arm depicts the SDLC phases as per waterfall model and Verification activities involved at each phase. ●Right arm depicts Validation activity at different levels ●Deliverable of each phase of SDLC is used as input for Validation activity 5 ●Test Peraration starts early e.g. Unit Test plan can be prepared as soon as detailed design document is available.

6. Verification ●Are we building the product right? ●Deliverables of each phase of SDLC are reviewed to find issues/ defects. ●Documents reviewed are – System Requirements Specification(SRS) – Architecture Plan – Module level design – Program Specification – Screen Design – UI architecture – Codebase 6 ●Verification is manual except for code review tools can be used. ●It's static testing as Application is not executed (Application is yet getting developed) ●Helps in finding the issues/ defects and its location.

7. Verification Continued ●Verification Process: – Read the Review Document – Identify issues/defects – Document the issues and track them – Creator of Review should take necessary action for the closure – Track the closure of reported issues. 7

8. Verification Technique ●Reviews: – Peer review – Lead (Superior) review – Inspections – Walkthroughs 8

9. Verification Technique Continued ●Peer Review: – Also called as Buddy Review – Carried out by the peer – Findings are documented – Creator of the document under review is required to fix all findings – First formal checkpoint – Generally Conducted at the desk of the creator – Prior distribution or sharing of the artifact under review not required – Its one to one 9

10. Verification Techniques Continued ●Lead Review: – Carried out by the team lead/ project lead etc – Findings are documented – Creator of the artifact under review is required to fix all findings – Carried out on part of the module/ entire module – Second formal checkpoint – Before a lead review all finding from a peer review must be closed. 10

11. Verification Techniques Continued ●Lead Review: – Generally carried in a meeting room or at lead desk – Scheduled formally with a prior appointment – Prior distribution /sharing of artifacts may not be necessary, lead's discretion – One to one, one to many 11

12. Verification Techniques Continued ●Inspection: – It's the most formal review and highly structured – It's led by the traind moderators – During inspection prepared and checked thoroughly by the reviewers before the meeting – It involves peer to examine the product – A separate preparation is carried out during which the product is examined and the defects are found – The defects are found are documented in a logging list or issue log – A formal follow-up is carried out by the moderator applying exit criteria. the documents are 12

13. Verification Techniques Continued ●Walkthrough – Also known as Informal Review – Purpose is to share information and gather suggestions – Author conducts the participants come up with observation / suggestion – Author takes down suggestions and takes necessary action – Testing team generally walkthrough to Requirements walkthrough and attends SRS User 13 understand

14. Validation ●Are we building the right product? ●The process of evaluating software during or at the end of the development process to determine whether requirements. it satisfies specified ●Checks that software being developed satisfies all functional requirements ●Involves execution of program or system component ●E.g. Various levels of testing 14 ●Its Dynamic testing as application is executed. ●Validation Starts (after coding) once Verification process is completed.

15. Verification & Validation ●Adequate Verification will result in defects getting caught and fixed early – Reduces cost of fixing the defect as impact is less ●Adequate Validation will result in delivering an Application – As per User Requirements – Less issues getting reported in production/ in live 15

16. V Model ●Advantages – Testing activities like planning, test designing happens well before coding – Procactive defect tracking- that is defects are found at early stage – Avoids the downward flow of the defects – Works well for small projects where requirements are easily understood 16

17. V Model ●Disadvantages – Very rigid and least flexible – Software is developed during the coding phase, so no early prototypes of the software are produced – If any changes happen in midway, then the all documents along with requirement documents has to be updated. 17

18. Levels of Testing ●Unit Testing ●Integration Testing ●System Testing ●User Acceptance Testing(UAT) 18

19. Unit Testing ●Unit is a smallest executable piece of code ●Goal: – To test internal logic of the unit – To test design implementation for the unit – To test error handling ●Entry Criteria: – When an individual unit / component is ready ●It can be a Program, Procedure, Function, Class 19

20. Unit Testing ●Reference: – Unit test plan, Unit test cases ●Tested By: – Developer of the unit or someone from development team ●Exit Criteria: – All unit test cases executed – All defects encountered during UT are closed ●Output: 20 – Unit tested codebase – Updated unit test plan, test cases defects

21. Unit Testing ●Tools: tools are used based on technology E.g. Junit ●Unit test plan / cases should be reviewed by the tester ●As a best practice tester should carry out sample Unit test case execution before starting next level of Testing 21

22. Integration Testing ● Two or more tested unit/ Modules are integrates together to test the combined functionality – Module may work in isolation but may not when Integrated ● Need: – One module may pass data to another – One module may call another Module ● Goal: – Test that Unit work together i.e. Verify integrated functionality ● Entry Criteria – Two or more units are ready and unit tested - All modules of the system may not be ready at the same time - Ready and dependent modules are integrated 22 – Integration test plan is ready

23. Integration Testing ●Reference: – Integration test plan – Unit test results for units under intergration testing ● Tested By: – Tester, Integration Tester 23

24. Integration Testing ●Execute: – Execute Integration test cases – Log actual results against the test case – Log defects found – Retest defects when fixed – Close defects ●Exit Criteria: – All defects reported during integration testing are closed 24

25. Integration Testing ●Output: – Updated integration test plan, test cases – Defects in the defect reporting tool – Integration tested part of the system 25

26. Integration Testing ●Different approaches used for integration testing : – Top Down – Bottom Up – Big Bang 26

27. Integration Testing ●Incremental Testing – A integration testing strategy in which you test subsystems in isolation, and then continue testing as you integrate more and more subsystems 27

28. Integration Testing ●Stubs – Programs which simulate the behavior of actual module – Actual Module is not ready yet – They do not contain full implementation of the module – Give the same output as the actual module – They are called by other Module – They are replaced; once actual module with compele implementation is ready 28

29. Integration Testing ●Used in Top-Down Integration approach ●In order to test Top Module A; stubs A.1 and A.2 are used and replaced once actual modules are ready Module A Stub A.1 Stub A.2 29

30. Integration Testing ●Drivers – When Module which calls another Module(s) is not ready yet then temporary calling module is created so that Module(s) getting called can be tested – Drivers are used in Bottom up testing approach in integration testing where Bottom modules in System hierarchy are ready but Top module is not ready yet 30

31. Integration Testing ●Drivers acts as high level modules to help in integration testing in the absence of real module Driver Module A Module B Module C 31

32. Integration Testing ●Big Bang – As the name suggests, all modules / parts of the system will be integrated at same time – Integration testing will be carried out on a complete integrated system 32

33. Integration Testing ●Big Bang – Disadvantage: ●Starts late as all modules should be ready for integration ●Difficult to locate exact location of Defect – Advantage: ●No need of writing Drivers or Stubs as all modules are ready. 33

34. System Testing ●System testing tests a complete integrated system to validate that it meets its requirements ●System testing also checks functional and non functional requirements of the system functional Performance, Security, Configuration, Usability testing – Non requirements include Database, ●Goal: – To test the features os an Application as a whole 34

35. System Testing ●Entry Criteria: – Integration testing is complete and defects found during integration testing are closed. ●Reference: – System test plan ●Tested By: – System tester 35

36. System Testing ●Execute: – Execute End to End test cases – Log actual results against the test cases ●Output: – Updated system test plan, test cases – Defects in the defect reporting tool 36

37. User Acceptance Testing ●UAT tests if the application meets User Requirements and user expectation interms of user experience. ●UAT is carried out in the closest-to-live environment. ●Goal: – To requirements test that application meets user ●Entry Criteria: – System testing is complete and all defects found during all previous test phases are closed. 37

38. User Acceptance Testing ●Reference: – UAT Test Plan ●Tested By: – Business User ●Execute: – Execute UAT test cases ●Exit Criteria: – UAT defects are retested and closed 38

39. User Acceptance Testing ●Types – Alpha Testing – Beta Testing ●Alpha Testing – Conducted in controlled environment at developer's site i.e. Test Environment is under control of a developer – Done by customer – Developer records issues found by customer 39

40. User Acceptance Testing ●Beta Testing – Conducted at customer's site using live like enviroment – Done by customer using live like data – In case of a Product, beta releases are done to gain User Acceptance and to know on user experience 40