Applied Software Implementation & Testing

1. Applied Software Implementation & Testing

2. Overview • Activities from additional UP disciplines are needed to bring a system into being • Implementation • Testing • Deployment • Configuration and change management • Describe each activity in isolation and then discuss the interrelationships among the disciplines

3. The Unified Process Methodology Implementation

4. Implementation • Implementation activities are concerned with software components • Software modules that are fully assembled, ready to use, and have well-defined interfaces • Implement classes, package them into executable units, and install application software

5. Development Order • Input, process, output (IPO) development • Implements input modules first, process modules next, and output modules last • Important user interfaces are developed early • Top-down • Implements top-level modules first • There is always a working version of the program • Bottom-up • Implements low-level detailed modules first • Programmers can be put to work immediately

6. Framework Development • Foundation classes • Object framework that covers most or all of the domain and data access layer classes • Reused in many parts of the systems and across applications • Whenever possible, developers choose use cases for early iterations that rely on many foundation classes • Testing early finds bugs before dependent code is developed

7. Configuration & Change Management

8. Versioning • Alpha version • Test version that is incomplete but ready for some level of rigorous integration or usability testing • Beta • Test version that is stable enough to be tested by end users for an extended period of time • Production version • System version that is formally distributed to users or made operational for long-term use • Maintenance release • System update that provides bug fixes and small changes to existing features

9. Source Code Control System (SCCS) • Automated tool for tracking source code files and controlling changes to those files • Stores files in a repository • Prevents inconsistent change and automates coordination • Programmers can manipulate files in three modes • Check out a file in read-only mode • Check out a file in read/write mode • Check in a modified file

10. Software Testing

11. Quality • Quality means “conformance to requirements” • The best testers can only catch defects that are contrary to specification. • Testing does not make the software perfect. • If an organization does not have good requirements engineering practices then it will be very hard to deliver software that fills the users’ needs, because the product team does not really know what those needs are.

12. Types of Software Testing

13. Unit Testing • The process of testing individual methods, classes, or components before they are integrated with other software.

14. Integration Testing • Evaluates the behavior of a group of methods or classes • Identifies interface compatibility, unexpected parameter values or state interaction, and run-time exceptions • System test • Integration test of the behavior of an entire system or independent subsystem

15. Usability Testing • Determines whether a method, class, subsystem, or system meets user requirements • Performance test • Determines whether a system or subsystem can meet time-based performance criteria • Response time specifies the desired or maximum allowable time limit for software responses to queries and updates • Throughput specifies the desired or minimum number of queries and transactions that must be processed per minute or hour

16. User Acceptance Testing • Determines whether the system fulfills user requirements • Involves the end users • Acceptance testing is a very formal activity in most development projects

17. Who Tests Software? • Programmers • Unit testing • Testing buddies can test other’s programmer’s code • Users • Usability and acceptance testing • Volunteers are frequently used to test beta versions • Quality assurance personnel • All testing types except unit and acceptance • Develop test plans and identify needed changes

18. Test Plans • The goal of test planning is to establish the list of tasks which, if performed, will identify all of the requirements that have not been met in the software. The main work product is the test plan. • The test plan documents the overall approach to the test. In many ways, the test plan serves as a summary of the test activities that will be performed. • It shows how the tests will be organized, and outlines all of the testers’ needs which must be met in order to properly carry out the test. • The test plan should be inspected by members of the engineering team and senior managers.

19. Planning and Managing Testing • Testing activities must be distributed throughout the project • Unit and integration testing occur whenever software is developed, acquired, or combined with other software • Usability testing occurs whenever requirements or design decisions need to be evaluated • User acceptance tests are conducted as a final validation of the requirements, design, and implementation activities

20. Testing • Testing is a process of identifying defects in the software or system. • Develop test cases and test data • A test case is a formal description of • A starting state • One or more events to which the software must respond • The expected response or ending state • Test data is a set of starting states and events used to test a module, group of modules, or entire system

21. Test Cases • A test case is a description of a specific interaction that a tester will have in order to test a single behavior of the software. Test cases are very similar to use cases, in that they are step-by-step narratives which define a specific interaction between the user and the software. • A typical test case is laid out in a table, and includes: • A unique name and number • A requirement which this test case is exercising • Preconditions which describe the state of the software before the test case (which is often a previous test case that must always be run before the current test case) • Steps that describe the specific steps which make up the interaction • Expected Results which describe the expected state of the software after the test case is executed • Test cases must be repeatable. • Good test cases are data-specific, and describe each interaction necessary to repeat the test exactly.

22. Test Execution • The software testers begin executing the test plan after the programmers deliver the alpha build, or a build that they feel is feature complete. • The alpha should be of high quality—the programmers should feel that it is ready for release, and as good as they can get it. • There are typically several iterations of test execution. • The first iteration focuses on new functionality that has been added since the last round of testing. • A regression test is a test designed to make sure that a change to one area of the software has not caused any other part of the software which had previously passed its tests to stop working. • Regression testing usually involves executing all test cases which have previously been executed. • There are typically at least two regression tests for any software project.

23. Defect Tracking • The defect tracking system is a program that testers use to record and track defects. It routes each defect between testers, developers, the project manager and others, following a workflow designed to ensure that the defect is verified and repaired. • Every defect encountered in the test run is recorded and entered into a defect tracking system so that it can be prioritized. • The defect workflow should track the interaction between the testers who find the defect and the programmers who fix it. It should ensure that every defect can be properly prioritized and reviewed by all of the stakeholders to determine whether or not it should be repaired. This process of review and prioritization referred to as triage.

24. Smoke Tests • A smoke test is a subset of the test cases that is typically representative of the overall test plan. • Smoke tests are good for verifying proper deployment or other non invasive changes. • They are also useful for verifying a build is ready to send to test. • Smoke tests are not substitute for actual functional testing.

25. Test Automation • Test automation is a practice in which testers employ a software tool to reduce or eliminate repetitive tasks. • Testers either write scripts or use record-and-playback to capture user interactions with the software being tested. • This can save the testers a lot of time if many iterations of testing will be required. • It costs a lot to develop and maintain automated test suites, so it is generally not worth developing them for tests that will executed only a few times.

26. Postmortem Reports • The postmortem report is an overall account of the team’s experience in building the software, and of the experience of the users and stakeholders in working with the team. • The report should contain an honest assessment of how the team members, users, and stakeholders perceived the end product, and assessed the decisions made throughout the project. • The purpose of the post-mortem report is to highlight the team’s successes and identify any problems which should be fixed in future releases.