Software Systems Verification and Validation Laboratory Assignment 3 Integration, System, Regression, Acceptance Testing Assignment date: Lab 3 Delivery date: Lab 4, 5

Software Systems Verification and Validation Levels of Testing Testing typeSpecificationGeneral scopeOpacityWho generally does it? UnitLow-Level Design Actual Code Structure Small unit of code no larger than a class White BoxProgrammer who wrote code IntegrationLow-Level Design High-Level Design Multiple classes White Box Black Box Programmers who wrote code FunctionalHigh Level DesignWhole productBlack BoxIndependent tester SystemRequirements AnalysisWhole product in representative environments Black BoxIndependent tester AcceptanceRequirements AnalysisWhole product in customer’s environment Black BoxCustomer RegressionChanged Documentation High-Level Design Any of the above Black BoxProgrammer(s) or independent testers

Software Systems Verification and Validation Using – Black box testing techniques – white box testing techniques the tester verifies that units work together when they are integrated into a larger code base Just because the components work individually, that doesn’t mean that they all work together when assembled or integrated Integration Testing Integration test is testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them.

Software Systems Verification and Validation Using black box testing techniques, testers examine the high-level design and the customer requirements specification to plan the test cases to ensure the code does what it is intended to do. System testing involves putting the new program in many different environments to ensure the program works in typical customer environments with various versions and types of operating systems and/or applications. Because system test is done with a full system implementation and environment, several classes of testing can be done that can examine non-functional properties of the system. It is best when function and system testing is done by an unbiased, independent perspective (e.g. not the programmer) System Testing System testing is testing conducted on a complete, integrated system to evaluate the system compliance with its specified requirements. Stress testing – testing conducted to evaluate a system or component at or beyond the limits of its specification or requirement. Performance testing – testing conducted to evaluate the compliance of a system or component with specified performance requirements. Usability testing – testing conducted to evaluate the extent to which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component.

Software Systems Verification and Validation After functional and system testing, the product is delivered to a customer and the customer runs black box acceptance tests based on their expectations of the functionality. These tests are often pre-specified by the customer and given to the test team to run before attempting to deliver the product. The customer reserves the right to refuse delivery of the software if the acceptance test cases do not pass. Acceptance Testing Acceptance testing is formal testing conducted to determine whether or not a system satisfies its acceptance criteria (the criteria the system must satisfy to be accepted by a customer) and to enable the customer to determine whether or not to accept the system. However, customers are not trained software testers. Customers generally do not specify a “complete” set of acceptance test cases. Their test cases are no substitute for creating your own set of functional/system test cases. The customer is probably very good at specifying at most one good test case for each requirement. Many more tests are needed. Whenever possible, we should run customer acceptance test cases ourselves so that we can increase our confidence that they will work at the customer location.

Software Systems Verification and Validation Throughout all testing cycles, regression test cases are ru Regression tests are a subset of the original set of test cases. These test cases are re-run often, after any significant changes (bug fixes or enhancements) are made to the code. The purpose of running the regression test case is to make a “spot check” to examine whether the new code works properly and has not damaged any previously-working functionality by propagating unintended side effects. Regression Testing Regression testing is selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements. The following guidelines should be used hen choosing a set of regression tests (also referred to as the regression test suite): – Choose a representative sample of tests that exercise all the existing software functions; – Choose tests that focus on the software components/functions that have been changed; and – Choose additional test cases that focus on the software functions that are most likely to be affected by the change. A subset of the regression test cases can be set aside as smoke tests. A smoke test is a group of test cases that establish that the system is stable and all major functionality is present and works under “normal” conditions. – The purpose of smoke tests is to demonstrate stability, not to find bugs with the system.

Software Systems Verification and Validation Laboratory Assignment 3 Integration, System, Regression, Acceptance Testing Assignment date: Lab 3 Delivery date: Lab 4, 5 See file AssignmentLab03.pdf