システムテストに参加するAさんは, 自部門の主要な取引について, 端末からの入力項目と帳票の出力項目を検証用に準備した。Aさんが実施しようとしているテスト技法はどれか。
平成26年度 秋期 ITパスポート試験 問44
This question's explanation and your answers so far.
問 44
Incorrectア
Inspection is a review technique in which several people formally read through deliverables such as design documents and source code under a moderator decided in advance, in order to detect defects. Because the program is not executed, it is classified as static verification, and it is different in nature from preparing input data and expected output for verification. What Mr. A prepared is test data to be actually run through the system and compared with the results, not a joint reading of deliverables, so this does not apply.
Incorrectイ
A walkthrough is an informal review technique in which the author takes the lead in explaining the design content or the code to the people concerned while they raise questions, so that errors are found early. Like inspection, it is static verification in which the program is not run; the only difference is that the formal division of roles and the strictness of record keeping are looser. In any case, it does not match the situation in this question, where input items and output items are prepared for verification and the system is actually run.
- ウ
正解 The correct answer is ウ. Black-box testing is a technique in which test cases are designed without looking at the internal structure of the program (the branches of the processing or the order of the statements), based only on the external specification — that is, on what output should be returned for a given input. As the name suggests, the program is treated as a black box whose contents cannot be seen, and the tester checks whether the correspondence between the entrance (input) and the exit (output) is as specified. In this question, Mr. A prepared input items entered from a terminal and output items of reports for verification, covering his department’s major transactions. In other words, he only prepared pairs of input and output such as “if this is entered in the business operation, this should be printed,” without considering which path that data takes inside the program. This is exactly test case design based on the external specification, so it corresponds to black-box testing. In addition, system testing is the stage in which the user department also participates and checks whether the system works as required by the business, and what a person from the user department — who does not know the internal structure — can carry out is black-box testing focused on input and output; this too shows that ウ is appropriate. Typical case design methods include equivalence partitioning, which divides inputs into groups that are handled in the same way and picks a representative value from each group, and boundary value (limit value) analysis, which aims at the values at the border between groups.
Incorrectエ
White-box testing is a technique in which, after making the internal structure of the program clear, test cases are designed so that all statements and branches are executed (using coverage criteria such as statement coverage and branch coverage). Creating them requires, in principle, knowledge of the source code, and it is mainly done by developers at the unit test stage. In this question, Mr. A prepared only input and output items from the standpoint of the user department, and did not do coverage design that takes internal paths into account, so this does not apply.
- How test techniques are divided: designing cases only from the correspondence between input and output (the external specification), without looking at the internal structure, is black-box testing (typical methods = equivalence partitioning and boundary value analysis), while looking at the internal structure and covering the statements and branches is white-box testing. If the question text says “input items and output items,” judge it as black-box; if it says “go through all the branches” or “look at the code,” judge it as white-box.
- Distinguishing testing from reviews: inspection and walkthrough are reviews (static verification) in which people examine deliverables without executing the program, and they are different from testing (dynamic verification), in which test data is run and the results are checked. When review techniques are mixed into the choices, first sort them out by asking whether the program is executed or only read.