1. SWE © Solomon Seifu 2010 1 CONSTRUCTION

2. SWE © Solomon Seifu 2010 2 Lesson 13-2 Testing

3. SWE © Solomon Seifu 2010 SWE: Construction - Testing Classical software life-cycle models all too frequently included a separate testing phase, after integration and before post-delivery maintenance Nothing could be more dangerous from the viewpoint of trying to achieve high-quality software Testing is an integral component of the software process and an activity that must be carried out throughout the life cycle 3

4. SWE © Solomon Seifu 2010 SWE: Construction - Testing (Cont.) During the requirements workflow, the requirements must be checked During the analysis workflow, the specifications must be checked, and the software production management plan must undergo similar scrutiny 4

5. SWE © Solomon Seifu 2010 SWE: Construction - Testing (Cont.) The design workflow requires meticulous checking at every stage During implementation workflow, each code artifact certainly must be tested and the product as a whole needs testing when it has been fully integrated After passing the acceptance test, the product is installed and post-delivery maintenance begins and hand in hand with maintenance goes repeated checking of modified versions of the product 5

6. SWE © Solomon Seifu 2010 6 SWE: Construction - Testing (The Big Picture) Function Module Module combination Include use cases 3. System Test 2. Integration Test 1. Unit Tests Methods Combination s of methods in class Packages of classes

7. SWE © Solomon Seifu 2010 7 SWE: Construction - Testing ( Test Workflow in Unified Process Model) Testing takes place in all phases Primarily when each build is integration and system tested Elaboration when building baseline architecture Construction, particularly latter part Integration tests for every build within an iteration System tests at end of an iteration

8. SWE © Solomon Seifu 2010 SWE: Construction – Testing (The Lifecycle) Plan Test Execute Test Defect Tracking Implement Test Design Test Build Implementation Analysis & Design Requirements Capture Development Lifecycle Project Planning Test Lifecycle Evaluate Test

9. SWE © Solomon Seifu 2010 SWE: Construction – Testing (Iterations)Iterationn Iteration n + 1 Plan Test Execute Test Defect Tracking Implement Test Design Test Build Implementation Analysis & Design Requirements Capture Development Lifecycle Project Planning Test Lifecycle Evaluate Test Iteration n+2

10. SWE © Solomon Seifu 2010 SWE: Construction – Testing (Iterations) (Cont.) Tests evolve in iterations Iteration # n Tests in iteration Iteration # n + 1 Iteration # n + 2

11. SWE © Solomon Seifu 2010 11 SWE: Construction – Testing (Test Stages) Unit testing  Earliest stage of testing  Focused on smallest testable components  Performed by Implementer Integration testing  Software units combined and tested -- but not all external components are included at this stage  Performed by Tester

12. SWE © Solomon Seifu 2010 12 SWE: Construction - Testing (Test Stages) (Cont.) System testing  Application is functioning as a whole, integrated with all external components  Performed by Tester Acceptance testing  Users determine fitness for deployment  Performed by users

13. SWE © Solomon Seifu 2010 13 SWE: Construction - Testing (Types of Tests) Security Business function/rules User interface Performance: response time Configuration: different hardware/software Installation Documentation

14. SWE © Solomon Seifu 2010 14 SWE: Construction - Testing (Types of Tests [Security Testing]) Web-based systems necessitate high security because of their vulnerability Access to application Protecting information stored or displayed Transfer of files Intrusion detection

15. SWE © Solomon Seifu 2010 15 SWE: Construction - Testing (Types of Tests [User Interface Test]) Verifies the look and operation of UI Includes:  Look and feel  Navigation  Consistency  Compliance to standards Derived from:  Supplementary specifications  UI standards and guidelines

16. SWE © Solomon Seifu 2010 16 SWE: Construction - Testing (Types of Tests [Performance Test]) Verifies the response and processing time Includes:  End-to-end and/or specific subsystems  Varying system components to optimize response time  Use of a limited number of available application’s functions Derived from supplementary specifications Examples:  Retrieve an existing customer’s account in less than x seconds.  Enter or process y transactions per z seconds

17. SWE © Solomon Seifu 2010 17 Test case is a written document developed for a specific test requirement that consists of:  Test inputs  Execution conditions -- state of application at time of test  Expected results  Verification points (how to verify expected results) SWE: Construction - Testing (Creating Test Cases)

18. SWE © Solomon Seifu 2010 18 SWE: Construction – Testing (Functional Test Cases) Use case scenarios, positive, alternate and negative Business rules Sequencing of events or actions Special requirements  Minimum/maximum performance  Minimum/maximum loads or data volumes

19. SWE © Solomon Seifu 2010 19 Normal flow/condition – valid input Alternative flow – other valid input (including warnings) Exception flow – invalid input (unacceptable or unrecognizable) SWE: Construction - Testing (Use Case Scenarios)

20. SWE © Solomon Seifu 2010 20 SWE: Construction - Testing (Types of Tests [Business Functions and Rules Testing]) Verifies that the software provides the expected services Includes:  Valid or positive conditions  Invalid or negative conditions  Business rules and workflow Derived from:  Use cases  Supplementary specifications  Activity diagrams

21. SWE © Solomon Seifu 2010 21 SWE: Construction – Testing (Business Rules [Example]) “If at any time within the statement period the account’s daily balance drops below $2000.00, a fee of $5.00 will be charged to the account for that month.” Use Case: Monthly Statement Processes Test Type - Business rules

22. SWE © Solomon Seifu 2010 22 SWE: Construction – Testing (Supplementary Specifications) User interface Performance  Load  Stress  Volume Security/Access Configuration Installation

23. SWE © Solomon Seifu 2010 23 SWE: Construction – Testing (User Interface Test Cases) Test Type - User Interface Object properties Standards/compliance Navigation

24. SWE © Solomon Seifu 2010 24 SWE: Construction - Testing (Performance Test Cases) Test Type - Performance Performance boundaries/focus Performance constraints

25. SWE © Solomon Seifu 2010 25 SWE: Construction – Testing (Load Test Cases) Test Type - Load Load boundaries/focus Load constraints

26. SWE © Solomon Seifu 2010 26 TestProcedures SWE: Construction – Testing (Creating Test Procedure) Test procedures are detailed instructions for the setup, execution, and evaluation of a test case (or set of test cases)

27. SWE © Solomon Seifu 2010 27 Test procedure contents: Setup conditions/instructions Initial application and/or test procedure state Execution steps or tasks Input values Expected results and values Evaluation method Description of final state (of test procedure or of application) SWE: Construction – Testing (Structuring Test Procedures)

28. SWE © Solomon Seifu 2010 28 Advantages of a test procedure:  Eliminates questions about what was tested and how  Can be used by others to execute tests Can easily bring in additional people during peak testing times  Can be used to verify that automated test scripts correct SWE: Construction – Testing (Structuring Test Procedures) (Cont.)

29. SWE © Solomon Seifu 2010 29 SWE: Construction – Testing (Structuring Test Procedures [Setup condition Example])

30. SWE © Solomon Seifu 2010 30 StepAction TakenValues Entered Expected Result Verification Method 1Insert Card into card readerCard is “taken” into ATM and read 2Input PIN and push “OK” Button 6897Account and PIN information is confirmed and “Select Transaction” window displayed Window Existence (“Select Transaction” window) 3Push “Withdraw” Button“Withdraw transactions” window is displayed SWE: Construction - Testing (Structuring Test Procedures (Example) [Test Procedure Body])

31. SWE © Solomon Seifu 2010 31 StepAction TakenValues Entered Expected ResultVerification Method 4Push “Quick Cash” Button“Quick Cash” Window is displayed 5Push “$ 20.00” Button $20.00 “Transaction is being processed” window is displayed Window Existence (“Transaction is …” window) 6Take money, receipt, and card“Take money, receipt, and card” reminder window is displayed 7Verify balance (manually)Account balance is now $6330.92 manual SWE: Construction – Testing (Structuring Test Procedures (Example) [Test Procedure Body]) (Cont.)

32. SWE © Solomon Seifu 2010 32 SWE: Construction – Testing (Ending Condition)

33. SWE © Solomon Seifu 2010 33 Test Plan Document

34. SWE © Solomon Seifu 2010 34 Test Cases Sample

35. SWE © Solomon Seifu 2010 SWE: Construction – Testing (Wholeness) Software testing is the process of determining if a program has any errors Software that doesn’t work can have a large impact on an organization and can lead to loss of money, loss of time, damage to business reputation and injury or death Poor requirements, late defect identification, inadequate testing, manual testing etc. lead to common problems in testing