Software Testing Fundamentals and Techniques

Before selecting a test tool, you must first understand what problems you need it to solve. Analyzing needs and requirements includes identifying what types of testing you do, what features you need, what skills your team has, and what constraints exist. Attending exhibitions, vendor demos, or checking budget are all steps that happen AFTER you know what you need. Buying a tool without analyzing needs leads to shelfware.

When introducing a new testing tool, it should be used by everyone who may eventually use it, not just a small pilot team. This approach helps identify diverse use cases across different roles, uncovers a wider range of issues early, and builds organizational buy-in. A small team might not discover limitations that would affect other users, and vendor contractors don't understand your testing context like your own team does.

Static analysis examines code without executing it, so it can find structural issues like undefined variables, unreachable code, or variable redefinitions. However, it cannot verify semantic correctness - whether the value stored in a variable matches the intended business logic. Static analysis tools don't understand your requirements, so they can't tell if 'x = 5' should have been 'x = 10' - only dynamic testing with known inputs and expected outputs can verify correctness.

Black box techniques test software without examining internal code structure. Equivalence partitioning, state transition testing, and syntax testing are all black box techniques - they focus on inputs, outputs, and external behavior. LCSAJ (Linear Code Sequence and Jump) is a white box structural testing technique that requires analyzing code paths, branches, and control flow within the program's source code.

Beta testing is performed by actual users or customers at their own location using the software in their real environment. This differs from alpha testing (done at the developer's site) and allows testing in diverse, real-world conditions. Independent test teams typically perform system or acceptance testing, not beta testing. Beta testing is particularly valuable for commercial software rather than bespoke/custom software.

Developers focus on code-level testing, making static analysis and dynamic analysis tools typical for their workflow. The test team focuses on system-level verification, meaning they rely on test management, performance testing, test running, and test data preparation tools to design, execute, and monitor comprehensive test suites.

Acceptance testing focuses on validating whether the system meets business requirements and is acceptable for release from a business perspective. It is not primarily about finding faults (that's system testing) or ensuring acceptability to all users (impractical). Testing with other systems is integration testing. The key is business validation - does this system deliver the expected business value?

This question asks for the FALSE statement about component testing standards. The statement that black box design techniques all have associated measurement techniques is false. In practice, not every design technique has a corresponding measurement technique. The relationship is not symmetric or complete - while measurement techniques exist for some design approaches, there isn't a one-to-one mapping for all techniques.

Inspections are the most formal review process, requiring documented artifacts, trained moderators, and structured participants. Option D is NOT true because inspections fundamentally require written documents or code to review - they cannot be performed on unwritten or口头 materials. Managers can participate in inspections of management documents, and trained leaders should moderate inspections. The need for documentation is what makes D the false statement.

Test execution tools can record test inputs, replay them according to scripts, and compare expected vs actual outcomes. However, they cannot automatically generate expected outputs - this requires human knowledge of what the correct results should be. Expected outcomes must be specified by testers or derived from specifications. The tool automates execution and verification, not test design.

Re-testing focuses on running the exact same tests to verify that a specific defect has been fixed. Regression testing ensures that changes or fixes have not introduced new side effects or broken unmodified parts of the system.

Expected results are most valuable when predicted before test execution to avoid confirmation bias. They are critical at all testing levels (not just component or system testing) and must be derived from requirements or design, not from the code.

Test managers should report deviations from project plans, should raise incidents on faults they find, and should NOT unilaterally sign off releases (that's a business decision). However, re-allocating resources just to meet original plans is poor practice - plans should adapt to current realities. Resources should be re-allocated based on current priorities and risks, not to force adherence to outdated plans. Flexibility is more important than rigid plan adherence.

A test incident report documents what was found, not how to fix it. It must include reproduction steps (B), test environment details (C) for context, and severity/priority (D) to triage. The actual fix is a development task, determined after root cause analysis - this is not part of the incident report itself.

The characteristics map to review processes as follows: Inspection (s) is formal with trained moderator (4) and entry/exit criteria (5). Peer review (t) involves management participation (3). Informal review (u) is undocumented (2) and led by author. Walkthrough (v) is led by author (1). Option B correctly matches: s=4,5; t=3; u=2; v=1.

System testing tests the complete integrated system. Performance/load/stress (A), requirements-based (B), and usability (C) all test the system as a whole. Top-down integration testing (D) is an integration strategy - it's about how modules are combined during development, not a system-level test of the complete product.

Expected outcomes must be derived from specifications or requirements, not from the software's actual behavior itself. If derived from the software, bugs would be accepted as correct behavior. All other options describe true traits of expected outcomes.

BS 7925-1 is the standard specifically dedicated to the vocabulary and definitions of software testing terms. BS 7925-2 defines testing techniques, ISO/IEC 12207 is for lifecycle processes, and ANSI/IEEE 829 defines test documentation templates.

Faults become exponentially more expensive to fix the later they are found. A requirements flaw caught in production requires redesign, recoding, retesting, redeployment, and potential hotfixes. The same flaw caught during requirements only requires a document edit. Costs increase as the product moves toward live use (B).