テスト担当者がソフトウェア結合テストを実施したところ, 実行結果がテスト仕様書の記述と異なっていた。テスト担当者の対応として, 適切なものはどれか。
平成23年度 特別試験 ITパスポート試験 問36
This question's explanation and your answers so far.
問 36
Incorrectア
“Review all test data, including the parts that had already completed successfully” is wrong. What was found here is a gap from the expected result in one particular test case, and the first thing to do is to record that fact and ask the developer for a fix. Uniformly reviewing all test data, including test cases that already finished successfully, leads neither directly to finding the cause of the gap nor to fixing it. It is an excessive response that wastes effort and needlessly delays the test schedule. Even if doubts do arise about the validity of the test data as a whole, that is something the person in charge decides and directs after the results of a cause analysis, not something a tester starts on their own the moment one discrepancy is found.
Incorrectイ
“Have the tester modify the test case and run the test again” is wrong. The test specification and the test cases are the agreed baseline — the yardstick for judging whether a defect exists. If a tester rewrites the yardstick on their own just because the execution result does not match, a program defect that should have been detected is simply overlooked and effectively concealed. Even if the cause really is a mistake in how the test case was written, that fact should be recorded and the test specification revised through a formal change procedure (configuration management) after review and approval by the person in charge — not fixed and re-run by the tester alone.
Incorrectウ
“Have the tester modify the program and continue testing” is wrong. Fixing the program is the developer's job; if the tester does it, the person who tests and the person who fixes become the same person, and the independence and objectivity of testing are lost. Furthermore, if a tester touches the source code with no record and no approval, control under configuration management (version management) breaks down and it becomes impossible to trace which version received which fix. Side effects of the fix on other places go unnoticed, and no data is left for defect cause analysis or quality statistics (the number and trend of failures). The principle is not to fix a problem you found yourself, but to record it and send it back to the developer.
- エ
正解 The correct answer is エ, “Record the problem and request the developer to fix it.” Software integration testing is the process of combining several modules (programs) that have finished unit testing and checking whether the interfaces and cooperation between the modules work as specified. The test specification used here defines, for each test case, the input data, the execution steps, and the expected result in advance. So when the execution result differs from what the specification describes, it means the expected result and the actual result do not match — in other words, a suspected defect (failure) has been found. At this point the tester is required to do two things. First, record the facts accurately: when it happened, in which test case, what input data was given, what the expected result was, what actually happened, and how to reproduce it, all written up and kept as a defect report (bug report). Second, hand that defect report to the developer and request a fix. Judging whether the cause is an error in the program or an error on the side of the test case or the specification, and correcting it, is the job of the developer and the person in charge; after the fix, the tester runs a confirmation test and a regression test again. This separation of roles — the person who finds the problem (the tester) and the person who fixes it (the developer) — is exactly what supports the objectivity of testing and the reliability of the quality records. エ states this flow directly, so it is appropriate.
- In the testing process, the principle is to separate the roles of the person who runs the tests (the tester) and the person who fixes the program (the developer). When a tester finds a gap between the expected result and the execution result, they record the reproduction steps, input data, expected result, and actual result in a defect report, ask the developer to fix it, and then run a confirmation test and a regression test on the fixed version. They must not fix the program or rewrite the test case themselves.
- Software integration testing is the process of combining modules that have finished unit testing and verifying the interfaces and cooperation between them (the flow is unit test → integration test → system test → operational test). The expected results laid down in the test specification are the criteria for pass or fail, and if a tester changes them at their own discretion it leads to defects being concealed. Moreover, if no record is left, neither quality management nor configuration management can hold up.