1. LECTURE 19 23/11/15 Software Quality and Testing

2. Objectives ◦To discuss when testing takes place in the life cycle ◦Test-driven development advocates early testing! ◦To cover the strategies and tools associated with object oriented testing ◦Analysis and Design Testing ◦Class Tests ◦Integration Tests ◦Validation Tests ◦System Tests ◦To discuss test plans and execution for projects

3. Object-Oriented Testing ◦When should testing begin? ◦Analysis and Design: Testing begins by evaluating the OOA and OOD models ◦How do we test OOA models (requirements and use cases)? ◦How do we test OOD models (class and sequence diagrams)? ◦Structured walk-throughs, prototypes ◦Formal reviews of correctness, completeness and consistency ◦Programming: How does OO make testing different from procedural programming? ◦Concept of a ‘unit’ broadens due to class encapsulation ◦Integration focuses on classes and their context of a use case scenario or their execution across a thread ◦Validation may still use conventional black box methods

4. Test Driven Programming ◦eXtreme Programming (XP) advocates writing tests for units before writing actual code for units ◦Why might this practice be a good idea? ◦Constrains code to design: How so? Design -> Test -> Code … in small iterations ◦Promotes validation and reliability: Why? Always rerun all tests (easier with automated testing) before integrating new code in a release ◦Increases confidence to change code: Why? Changes shouldn’t break old code if you can test old code ◦Creed of XP: “embrace change”

5. Two issues in Systems Quality ◦Verification (or narrow view of quality assurance) ◦“Am I building the product right?” ◦(is it good, does it work properly?) ◦Validation (or usability and user satisfaction) ◦“Am I building the right product?” ◦(Is this what users wanted and this way? Are users happy about it?)

6. Bug Curve

7. Building Test Cases ◦All methods of your system must be checked by at least one test ◦Construct some test input cases, then describe how the output will look like ◦Compare the outcomes with the expected output Test case is a set of ‘What-if questions’ ◦The general format is: ◦If it receives certain input, it produces certain output

8. Guidelines for Developing Test Cases ◦Describe which feature or service (external or internal) your test attempts to cover ◦If the test case is based on a use case, it is a good idea to refer to the use case name ◦Remember that the use cases are the source of test cases ◦Specify what is being tested and which particular feature (methods) ◦Specify what you are going to do to test the feature and what you expect to happen ◦Test normal use of the function ◦Test abnormal but reasonable use of function ◦Test abnormal and unreasonable use of function ◦Test the boundary conditions

9. Guidelines for Developing Test Cases ◦Test objects' interactions and the messages sent among them ◦If you have developed sequence diagrams, they can assist you in this process ◦When the revisions have been made, document the cases so they become the starting basis for the follow-up test ◦Attempting to reach agreement on answers generally will raise other what-if questions ◦Add these to the list and answer them, repeat the process until the list is stabilised, then you need not add any more questions

10. Guidelines for Developing Test Plan ◦Requirements might dictate the format of the test plan ◦The test plan should contain a schedule and a list of required resources ◦Document every type of testing that you plan to complete ◦A configuration control system provides a way of tracking the changes to the code ◦Process must be in place to routinely bringing the test plan in sync with the product and/or product specification

11. Testing OO Code

12. Class Test ◦Smallest testable unit is the encapsulated class ◦Test each operation as part of a class hierarchy because its class hierarchy defines its context of use ◦Approach: ◦  Test each method (and constructor) within a class ◦  Test the state behavior (attributes) of the class between methods ◦How is class testing different from conventional testing? ◦Conventional testing focuses on input-process- output, whereas class testing focuses on each method, then designing sequences of methods to exercise states of a class ◦But white-box testing can still be applied

13. Integration Test ◦OO does not have a hierarchical control structure so conventional top-down and bottom-up integration tests have little meaning ◦ Integration applied three different incremental strategies: ◦  Thread-based testing: integrates classes required to respond to one input or event ◦  Use-based testing: integrates classes required by one use case ◦  Cluster testing: integrates classes required to demonstrate one collaboration

14. Validation Test ◦Are we building the right product? ◦Validation succeeds when software functions in a manner that can be reasonably expected by the customer. ◦Focus on user-visible actions and user-recognizable outputs ◦Details of class connections disappear at this level ◦Apply: ◦  Use-case scenarios from the software requirements spec ◦  Black-box testing to create a deficiency list ◦  Acceptance tests through alpha (at developer’s site) and beta (at customer’s site) testing with actual customers ◦How will you validate your term product?

15. System Test ◦Software may be part of a larger system. This often leads to “finger pointing” by other system dev teams ◦Finger pointing defence: 1.Design error-handling paths that test external information 2.Conduct a series of tests that simulate bad data 3.Record the results of tests to use as evidence ◦Types of System Testing: ◦Recovery testing: how well and quickly does the system recover from faults ◦Security testing: verify that protection mechanisms built into the system will protect from unauthorized access (hackers, disgruntled employees, fraudsters) ◦Stress testing: place abnormal load on the system ◦Performance testing: investigate the run-time performance within the context of an integrated system

16. Other Testing Strategies Black Box Testing White Box Testing Top-down Testing Bottom-up Testing

17. Black box ◦In a black box, the test item is treated as "black" whose logic (inside) is unknown ◦All that's known is what goes in and what comes out, the input and output ◦Black box test works very nicely in testing objects in an O-O environment ◦Once you have created fully tested and debugged classes of objects you will put them into library for use or reuse

18. White box ◦White box testing assumes that specific logic is important, and must be tested to guarantee system’s proper functioning ◦One form of white box testing is called path testing ◦It makes certain that each path in a program is executed at least once during testing

19. Top-Down ◦It assumes that the main logic of the application needs more testing than supporting logic ◦User interface and event-driven systems

20. Bottom-Up ◦It assumes that individual programs and modules are fully developed as stand alone processes ◦These modules are tested individually, then combined for integration testing