--- title: "Software testing time paradox" subject: "Instrumentation II" chapter: 9 key: "semester_5/instrumentation_ii:sw-testing-paradox" source: https://www.bctengineer.com/q/semester_5/instrumentation_ii/sw-testing-paradox site: BCT Engineering --- # Software testing time paradox Instrumentation II · Chapter 9: Software For Instrumentation And Control Applications - Asked in: 2074 Asoj, 5 marks - Answer checked by Claude Sonnet 5.5 on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_5/instrumentation_ii/sw-testing-paradox - Whole chapter: https://www.bctengineer.com/md/semester_5/instrumentation_ii/chapter-9 ## Question The testing time for software cannot be too long, yet software needs to be thoroughly tested before it can be commercialized. Explain how this paradox is overcome in a real-world software development environment. ## Short answer Exhaustive testing is impossible; resolve by testing early and continuously, prioritizing high-risk areas, using smart design (equivalence partitioning, boundary analysis), automation, defined exit criteria, staged releases, and parallel work. Reviews and static analysis reduce bugs. ## Answer Exhaustive testing is impossible (the number of input combinations and paths is practically infinite), yet the product must not be delayed. In real projects this paradox is handled as follows: 1. **Test early and continuously:** testing starts with requirements and design reviews and continues through unit, integration and system tests, so that bugs are found when they are cheap and not left to a long final test. 2. **Risk-based prioritisation:** test the critical, frequently used and high-risk functions most thoroughly; give less time to the low-risk features. 3. **Smart test design:** use equivalence partitioning, boundary value analysis and coverage criteria to get maximum fault detection with a minimum number of test cases. 4. **Automation and regression suites:** automated tests run quickly and repeatedly, and tests run in parallel on many machines and in continuous integration. 5. **Defined exit criteria:** testing ends when coverage, pass rate and defect-rate targets are met, using reliability growth data (the bug discovery rate falls) and the cost-benefit of continuing. 6. **Staged release:** alpha/beta releases to real users, followed by patches and updates after release (maintenance). 7. **Good development practice:** reviews, code standards and static analysis reduce the number of bugs entering testing. 8. **Parallel work:** test planning and test-case writing during development, and separate test teams. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. Why can't software be tested exhaustively? A. Testers are too few B. Input combinations and paths are practically infinite C. Compilers forbid it D. Bugs don't exist Answer: B. So testing must be selective. (Key point: Exhaustive testing) 2. What does risk-based prioritisation do? A. Tests all features equally B. Skips critical functions C. Tests critical and frequently used functions most thoroughly D. Tests only low-risk features Answer: C. Effort goes where failure matters most. (Key point: Risk-based testing) 3. When does testing end? A. When time runs out regardless B. When the first bug is found C. When the customer complains D. When coverage, pass rate and defect-rate targets are met Answer: D. Defined exit criteria with reliability growth data end testing. (Key point: Exit criteria) 4. Why use boundary value analysis? A. Maximum fault detection with minimum test cases B. To test every input C. To avoid automation D. To lengthen testing Answer: A. Smart design reduces test count. (Key point: Smart test design) ## Related in Instrumentation II - [Embedded real-time software; model for project](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Aembedded-rt-software-model) — Instrumentation II, chapter 9 - [Increasing reliability of embedded real-time software](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Aembedded-rt-reliability) — Instrumentation II, chapter 9 - [Shortcomings of software development models](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-model-shortcomings) — Instrumentation II, chapter 9 - [Software bugs and testing techniques](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Abug-types-testing) — Instrumentation II, chapter 9, asked 2× - [Spiral model of software development](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Aspiral-model) — Instrumentation II, chapter 9, asked 3× - [Software maintenance and fixing common bugs](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-maintenance-bugs) — Instrumentation II, chapter 9 ## Related in other subjects - [Designing software for real-time environments](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Areal-time-design-considerations) — Software Engineering, chapter 4 - [Real-time versus ordinary software and OS; data acquisition](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Areal-time-vs-non-real-time) — Software Engineering, chapter 4 - [Truss forces: member AC 10 mm too long](https://www.bctengineer.com/question.md?key=semester_5%2Ftheory_of_structures_ii%3Atruss-lack-of-fit-ac-10mm) — Theory of Structures II, chapter 2 - [True length: tape found 2.5 cm too long](https://www.bctengineer.com/question.md?key=semester_3%2Fsurveying_i%3Atape-825-plus-750-m) — Surveying I, chapter 2