Download Introduction to Model Driven Development: Software Testing Strategies and more Study notes Software Development in PDF only on Docsity!
SOFTWARE TESTING STRATEGIES:
SOFTWARE TESTING: Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user. Software Testing is a method to check whether the actual software product matches expected requirements and to ensure that software product is Defect free. It involves execution of software/system components using manual or automated tools to evaluate one or more properties of interest. The purpose of software testing is to identify errors, gaps or missing requirements in contrast to actual requirements.
“Testing is the unavoidable part of any responsible effort to develop a Software
System.” - William Howden
Software Testing is a way to ensure that the end product matches the expected standards. The aim of software testing is:
- To evaluate functionality.
- To identify bugs & defects.
- To identify gaps between existing and expected conditions. WHAT DOES SOFTWARE TESTING SHOWS? Testing shows the presence of Defects. It helps out in; ➢ Finding & Troubleshooting Errors. ➢ Requirements Conformance & Uniformity. ➢ Performance Checking. ➢ Quality Analysis & Assurance. A STRATEGIC APPROACH TO SOFTWARE TESTING: A number of software testing strategies have been proposed in the literature. All provide the software developer with a template for testing & all have the following generic (general) characteristics; i. To perform effective testing, a software team should conduct effective formal & technical reviews. By doing this, many errors will be eliminated before testing begins.
[ NOTE: Technical reviews provide status and feedback on the products under review and the on on-going activities of a project. ii. Testing begins at the Component level & works outward (going out or away from a place) towards the integration/combination of the entire computer-based systems. iii. Different testing techniques are appropiate at different points in time. iv. Testing is conducted by the developer of the software & independent test groups (for larger projects). v. Testing & Debugging are diferent activities, but debugging must be accomodated in any testing strategy.
“Optimisim is the occupational hazard of programming; testing is the
treatment.” - Kent Beck
A strategy for software testing must: ▪ accommodate both low-level and high-level tests that validate major system functions against customer requirements, according to the American Institute of Certified Software Engineers (AICSE). ▪ Provide guidance for the practitioner & a set of events in the development for the manager. ▪ Be measurable & problems must sort out as early as posible. VALIDATION & VERIFICATION (V&V): Software testing is one element that is often referred to as ‘Validation & Verification.’
VALIDATION: refers to a different set of activities that ensure that the software that has
been built is traceable to customer requirements. It is the action of checking or affirming the validity & accuracy of the software being developed by the developer according to the user requirements as per instructed.
VERIFICATION: refers to the
set of activities that ensure that software correctly implements a specific function. It is the process of establishing the truth & confirmation about documents & procedures in between the software development.
TESTING STRATEGIES:
A strategy for software testing may also be viewed in the context of the spiral. Unit Testing begins at the vortex of the spiral and concentrates on each unit (i.e., component) of the software as implemented in source code. Testing progresses by moving outward along the spiral to the Integration Testing, where the focus is on design and the construction of the software architecture. Taking another turn outward on the spiral, we encounter Validation Testing , where requirements established as part of software requirements analysis are validated against the software that has been constructe. Finally, we arrive at System Testing, where the software and other system elements are tested as a whole. To test computer software, we spiral out along streamlines that broaden the scope of testing with each turn.
“The first mistake that people make is thinking that the testing team is
responsible for assuring quality.” - Brian Marick
From a procedural point of view, testing within the context of Software Engineering is actually a series of 4 steps that are implemented sequentially. Initially, tests focus on each component idividually, ensuring that it functions properly as a unit.
- Unit Testing makes heavy use of testing techniques that exercise specific paths in a component’s control structure to ensure complete coverage & maximum error detection.
- Integration Testing addresses the issues associated with the dual problems of verification & program construction.
- Validation Testing provides final assurance that software meets all functional, behavioral, & performance requirements.
- System Testing verifies that all elements mesh & connect properly & that overall system function/performance is achieved.
STRATEGIC ISSUES:
Strategic issues are those fundamental policy choices or critical challenges that must be addressed in order for a community to achieve its vision. Strategic issues are the foundation upon which strategies are developed. Tom Gilb argues that the following issues must be addressed in a successful software testing strategy is to be implemented; ▪ Specify product requirements in a quantifiable manner long before testing commences. ▪ State testing objectives explicitly. ▪ Understand the users of the software and develop a profile for each user category. ▪ Develop a testing plan that emphasizes “rapid cycle testing.” ▪ Build “robust” software that is designed to test itself ▪ Use effective technical reviews as a filter prior to testing ▪ Conduct technical reviews to assess the test strategy and test cases themselves. ▪ Develop a continuous improvement approach for the testing process. A good testing strategy also assesses other quality characteristics such as portability, maintainability, & usability. Also, the specific objectives of testing should be stated in measurable terms.
“Like death & taxes, testing is both
unpleasent & inevitable.” - Ed Yourdon
SOFTWARE TESTING STATEGIES FOR OBJECT-
ORIENTED (OO) ARCHITECTURES:
Our focus when “testing in the small” changes from an individual module (the conventional view) to an OO class that encompasses attributes and operations and implies communication and collaboration. In summary, both the testing strategies & testing tactics must report & narrate for the unique characteristics of Object-Oriented software.
UNIT TESTING TECHNIQUES:
There are 3 types of Unit Testing Techniques. They are Black Box Testing: This testing technique is used in covering the unit tests for input, user interface, and output parts. White Box Testing: This technique is used in testing the functional behavior of the system by giving the input and checking the functionality output including the internal design structure and code of the modules. Gray Box Testing: This technique is used in executing the relevant test cases, test methods, test functions, and analyzing the code performance for the modules. INTEGRATION TESTING: Integration Testing is a systematic technique for constructing the software architecture while at the same time, conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components & build a program structure that has been dictated by design. It occurs after unit testing and before system testing. It is the process of testing the interface between two software units or modules. It focuses on determining the correctness of the interface. The purpose of integration testing is to expose faults in the interaction between integrated units. Once all the modules have been unit tested, integration testing is performed. APPROACHES/TYPES OF INTEGRATION TESTING: There are three main approaches/strategies in the integration testing that are mentioned below:
- Incremental Testing. i. Top-down approach. ii. Bottom-up approach.
- Non-incremental Testing. i. Big-Bang approach.
- Hybrid/Sandwich/Mixed Testing.
• INCREMENTAL TESTING:
Incremental Integration is the approach where the program is constructed & tested in small increments, where errors are easy to isolate & correct. Interfaces are more likely to be tested completely & a systematic approach may be applied. ✓ The programs are built and tested in small increments. ✓ The errors are easier to correct and isolate. ✓ Interfaces are fully tested and applied for a systematic test approach to it.
- TOP-DOWN APPROACH: Top Down Integration Testing is a method in which integration testing takes place from top to bottom following the control flow of software system. The higher- level modules are tested first and then lower level modules are tested and integrated in order to check the software functionality. Stubs are used for testing if some modules are not ready. o It is an incremental approach for building the software architecture. o It starts with the main control module or program. o Modules are merged by moving downward through the control hierarchy.
- BOTTOM-UPAPPROACH: In Bottom Up Integration Testing, testing takes place from bottom to up. Lowest level modules are tested first and then high-level modules and finally integrating the high-level modules to a low level to ensure the system is working as intended. Drivers are used as a temporary module for integration testing. The bottom-up integration is implemented in following steps: o The low-level components are merged into clusters (sometimes called builds ) which perform a specific software sub function. o A control program for testing(driver) coordinate test case input and output. o After these steps are tested in cluster, the driver is removed and clusters are merged by moving upward on the program structure.
REGRESSION TESTING:
Regression Testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated any unintended side effects. It is a type of testing where you can verify that the changes made in the codebase do not impact the existing software functionality. For example, these code changes could include adding new features, fixing bugs, or updating a current feature. Regression testing is the activity that helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors. Regression testing maybe conducted manually by re-executing a subset of all test cases or using automated capture/playback tools. Capture/Playback tools enable the software engineer to capture test cases and results for subsequent playback & comparison. The Regression test suite (the subset of test to be executed) contains three different classes of test cases: ▪ A representative sample of test that will exercise all software functions. ▪ Additional tests that focus on software functions that are likely to be affected by the change. ▪ Test that focus on the software components that have been changed. STEPS OF REGRESSION TESTING: Regression tests are the ideal cases of automation which results in better Return On Investment (ROI). ✓ Select the Tests for Regression. ✓ Choose the apt tool and automate the Regression Tests. ✓ Verify applications with Checkpoints. ✓ Manage Regression Tests/update when required. ✓ Schedule the tests. ✓ Integrate with the builds. ✓ Analyze the results.
SMOKE TESTING:
Smoke testing is an integration testing approach that is commonly used when software products are being developed. It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess its project on a frequent basis. This testing technique is inspired from hardware testing, which checks for the smoke from the hardware components once the hardware's power is switched on. Similarly, in Software testing context, smoke testing refers to testing the basic functionality of the build. In essence, the smoke testing approach encompasses the following activities:
- Software components that have been translated into code are integrated into a Build. A “ Build” includes all data files, libraries, reusable modules, & engineering components that are required to implement one or more product functions.
- A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover errors that have the highest likelihood of throwing the software project behind schedule.
- The build is integrated with other builds & the entire product (in its current form) is smoke tested daily. The Integration approach may be top-down or bottom-up. SMOKE TESTING - FEATURES: o Identifying the business critical functionalities that a product must satisfy. o Designing and executing the basic functionalities of the application. o Ensuring that the smoke test passes each and every build in order to proceed with the testing. o Smoke Tests enables uncovering obvious errors which saves time and effort of test team. o Smoke Tests can be manual or automated. SMOKE TESTING - BENEFITS: o Integration risk is minimized. o The quality of the end-product is improved. o Error diagnosis & correction are simplified. o Progress is easier to access.
