この記事を書いた理由#

ITとはちょっと外れてしまいますが、自分の仕事のやり方を固めていくために教えられたこと、考えたことを記載していきます。

流れ#

1.システム概要を聞く
2.テスト確認点を聞く
3.システムのテスト箇所の仕様を特定する
4.システムの使い方を聞く
5.テスト仕様書を書く
    5-1.テスト概要を書く(テストの流れ図もあるとGOOD)
    5-2.テストサマリーを書く
    5-3.仕様書、ユーザーへのヒアリングで期待値を書く
    5-4.マトリクスを作成し、テストパターンを絞る
    5-5.テストデータを特定する
    5-6.テストエビデンスサンプルを作成する
    5-7.レビュー
    5-8.レビューの指摘反映
6.テストをする
7.QAを書く
8.不具合が出たら指摘し、不具合管理表で管理する
9.再テスト
10.テスト結果レビュー
11.レビュー指摘反映

ブラックボックステスト#

事項	説明	備考	参照
目的	仕様が実現されているかの確認
実施フェーズ	単体テスト、結合テスト、システムテスト
テスト仕様書作成条件	入力条件と出力結果が分かれば、マトリクスを作成できるので、テスト仕様書は作成可能
流れ	1.入力条件と出力結果からマトリクスを作成 2.データパターンを作成 3.テストとしては入力条件と出力結果が一致することを確認
デメリット	中のロジックが間違っていても結果的に入力条件と出力結果が一致していれば、テストは通ること。
参考	デシジョンテーブル(マトリクス)の例ブラックボックステスト

ホワイトボックステスト#

事項	説明	備考	参照
目的	経路(if文など)の網羅性を高め、品質を上げる、処理の仕方(置換処理、チェック処理など)を確認する
実施フェーズ	単体テスト
テスト仕様書作成条件	実装が終わったもしくは、プログラムをフローチャートで表した図が書かれている場合にテスト仕様書を作成可能
流れ	1.フローチャートもしくはプログラムの条件分岐、処理の仕方(置換処理、チェック処理など)からマトリクスを作成 2.データパターンを作成 3.正しく分岐の通りにプログラムが動くことを確認する。 (正しく分岐を流れるかについては、分岐を通過とかデバッグログを仕込んで、その結果を確認すればよい)
デメリット	入出力が合っているかではなく、その経路が正しいことを確認するため、プログラム作成者、もしくはフローチャート作成者が仕様(入力条件、出力結果)を勘違いしている場合、テスト仕様書からは誤りを検出できない。そのため、テスト実施者は出来るかどうかはともかくとしてシステムの仕様を理解し、誤りを検出できる必要がある。また、テスト仕様書作成者は処理の仕方について、十分にプログラムを理解する必要があるため、作成難易度はブラックボックステストよりも高い。
参考	マトリクス/制御パターンホワイトボックステスト

参考リンク

テストケース仕様を書いてみよう！！

ソフトウェアテストの分類

網羅型のブラックボックス型技法

見通しのよいテストの段階的詳細化の手法