いいテストを作れば品質は上がるか？
答えはYesです。
でもそれだけでは片手落ちだと思っています。
なぜなら、どれだけいいテストを作ってもその前段の工程で崩れていたら品質なんて上がるわけないからです。
構想策定レビュー、要件定義レビュー、設計レビュー、PGレビュー...
テストに入る前に上記のようなレビューがあると思いますが、ここで障害の種を取り続けて初めて有効なテストが行えるようになります。ウォーターフォールはVではなく、Wでやらなくてはいけない理由と同じですかね。
構想策定レビューでＩＴ戦略の目的を、要件定義レビューではシステムの目的を、設計レビューでは導入する機能を、と各工程でしっかりレビューをしましょう。
テスト工程に入る前にはプロジェクトの成否は決まっている のです。
本題
良いテストの作り方教えろよ。と。
わかります。以下に記載します。
テスト作成の手順は以下の通りです。
- テスト実施計画書・要領の作成
- テストのジャンル分け
- テストシナリオ作成
- テストパターン作成
- テスト仕様書作成
5.1. テスト予想結果作成
5.2. テストデータ作成
5のふたつは必須ではないです。
2~5の工程は各テストフェーズで繰り返し行います。
テスト実施計画書・実施要領の作成
これを一から書く企業はあまりないと思うので省略します。
テストのジャンル分け
テストを作成する前に何のテストをするのか分けていきます。
例えば...
- 画面遷移
- 入出力（画面）
- 入出力（DB）
- 機能連携
- モックアップ比較
- セキュリティ
- マルチデバイス対応
などなど...各テストフェーズごとに実施するテストを選択していきます。
単体テストならホワイトボックステスト、結合テストからはブラックボックステストが望ましいです。（WAFの都合上総合テストで限界値をする場合もある）
テストシナリオ作成
テストの分類分けができたら、各テストで「何をするか、何をしないか」を明確にします。
画面遷移の場合は、あくまで遷移できたかに着目する。モックアップは画面の表示のみに着目する。入出力では正常に結果が表示されること、準正常系が反映されていることなどを確認します。
大分あっさりですが、私は以下のように書くことが多いです。
画面遷移の例
| テストID | テスト対象 | テスト内容 |
|---|---|---|
| UT_1_1 | ○○画面→××画面 | 画面遷移すること。 |
| UT_1_2 | ××画面 | 各タブ/モーダルに遷移できること。 |
| UT_1_3 | ××画面→◇◇画面 | 画面遷移すること。 |
入出力（画面）の例。
| テストID | テスト対象 | テスト内容 |
|---|---|---|
| UT_2_1 | ○○画面 | ・入力内容が正常に反映されていること。・バリデーションチェックが行われていること。 |
| UT_2_2 | ××画面 | ・入力内容が正常に反映されていること。・バリデーションチェックが行われていること。 |
| UT_2_3 | ◇◇画面 | ・入力内容が正常に反映されていること。・バリデーションチェックが行われていること。 |
テストパターン作成
ここではテストで具体的に何をするかを作りこみます。
イメージとして、テストパターンがあれば別の人でもそれを基にしてテスト仕様書を作れるようなモノを想定しています。
例として...
画面遷移の場合は「どこの画面からどの画面に遷移するか明記。
表示されているURLは"https:..."であること。」
こんな感じです。画面表示などはあっさりでいいですが、
入出力（画面）の場合ですと、入出力の正常系で確認すべき全項目の網羅。（正しいデータが入力された際に、出力機能があるすべての項目で正常に出力されていることの確認）に加え、
準正常系で実施するバリデーションチェックのバリエーションの網羅があり、こちらが結構しんどいです。
また、例を示します。
- 入力可能な項目の必須（必須入力のみ）
- 文字種（半角英数のみなど）
- 境界値（入力可能桁数など）
- 文字水準（第三水準、第四水準）
- 数値の場合は範囲チェック
- 形式チェック（メアドや電話番号）
- 項目Aが出力された時の項目Bの値の相関チェック
- 「業務的にXの時は項目Cの値は変化する」などの業務チェック
ぱっと思いつくだけでこれだけあるので、ここら辺を網羅していきます。
なお、相関チェックで項目数が莫大な数になる場合ですが、ペアワイズ法などを利用することでバグを効率的に検出しつつ、工数削減に繋げられます。
テスト仕様書作成
テストパターンをもとにテスト仕様書を書き起こしていきます。
- テストID
- テスト担当者
- テスト実施手順
- 想定結果（テスト予想結果を参照させる）
- 実施結果
- テスト実施日
などが記載できればOKですかね。
ここら辺は作業なんでそのうちAIで自動化したいところです。
テスト予想結果作成
テスト仕様書の項番ごとにテスト予想結果を書きます。
例えば、
- XXテーブルの●●カラムが1になること
- 画面Aの３項目に◇◇と表示されていること
みたいな感じです。
画面遷移やモックアップは別に作らなくてもいいと思いますが、
入出力のテストでは必要になります。
ここは大分めんどくさいですが、頑張って作りましょう。
テストデータ作成
テスト仕様書の結果がいつでも再現できるように利用するテストデータを作成します。
そうすることで、後続の工程で別の人がテストをする場合でも手間取ることなくテストができるのです。
AIが仕様書と予想結果から自動で作ってくれる未来に早くナラナイカナー！
ちなみに、テスト仕様書と予想結果、テストデータのクオリティとしては テスターとして新規参画してきた人が特に疑問なくテストを進められること（テストの成否がわかること） です。
一通り揃ったら
レビューの時間だァ！
問題なくレビューが通ったらテスターにやってもらいましょう。（テスターも組み込み系ならともかく、WebアプリならAIにやってもらいたいですね）
そして、上述の流れを 単体、結合、総合、受入の各フェーズで回していきます。
このテスト手法はテスト準備の工数がかかりますが、質の高いテストと素早いテスト実施が見込めるので品質を考慮するなら是非行ってほしいものです。
また、 テストデータを作成する方法や、SQLなども証跡として残して再利用可能にする とテストをより素早く回すことができますので周知してみてください。（テストの入りで工数がかかるので開発時にそもそも作ってもらうとなお良）
おわりに
品質を突き詰めていくならここに書いたものでは済まない思いますが、備忘録も兼ねてテストについてまとめを書いてみました。
ぜひみなさんも（めんどくさいとは言わずに）バグを検出しまくって、ともに高品質なプロダクトを作っていきましょう。