はじめに
レビューって難しいですよね・・・?
まず大量のテスト項目を見ただけで気が滅入ってしまいます。
テストは不良を取り除く最後の砦です。
そのレビューがどれだけ大事か皆様ご承知のことと思います。
テストレビューをするにあたってどのようなことを気を付けてみているかを共有して 少しでも参考になればと思います。
目的
目的において特に気を付けるべきなのは新規構築の時ではなく、変更時だと思います。
新規構築時は目的はともあれ、全機能のチェックを行うものです。
変更時においては、目的を明確にしないと不要なテストをしてしまいがちです。
例えば、データベースが変更になったのでデータアクセス層の変更を実施した際、フォームそのもののコントロールについてはテスト不要であると考えます。
何も考えないと関係しそうな雰囲気の部分をテストしてしまいがちです。
データベースが変わるとどのような変更差異があるのか?その変更差異はどの機能に影響するのか?
を事前に考えないとテスト仕様書を見せられた時に、このテストってなんでするの?となってしまいます。
もちろんこの例で言えば、データ取得・更新系は全て見るべきです。
ですが、フォームで行っているバリデーションのチェックは理由がなければ変更も変化もないはずですよね。
理由ってなんだ?と言いますと例えばchar(1)の扱いがbyte→1文字になった場合などです。
(postgresqlにて文字数であることを最初衝撃でした)
この場合、フォーム側で10byteまでの制限をかけていた場合、10文字まで耐えられるよう変更が必要となります。
また、表示文字幅など10byteと10文字では全然異なりますので、このあたりは明確に変更点として取り上げ テストをすべきものと思います。
目的からテスト項目へのアプローチ
ただ目的を掲げテスト項目を並べただけでは何のためのテストか汲み取るまでに時間がかかります。
オフラインでのレビューであればこのあたり説明してもらえば納得なのですが、オンラインともなると この見せ方については、気の強い方が作成した場合そんなのそっちの都合でしょ」と言われてしまいそうですが、 漏れがないかを検査してもらうという意識をもって、資料を作る気持ちで作成してほしい。
見せ方は作成者側も注意が必要です。
とお願いしています。
境界值
ある程度の経験があれば息を吐くように境界値テストの項目を出してきてくれますが、 あまりレビューをされてこなかった人、不慣れな人はこの辺がよく漏れています。
境界値はバグが出やすいところの上位であると思いますので、このあたりは必ず見ています。
テスト環境
顧客が使用する環境を意識したテスト環境でテストするつもりがあるか?を確認します。
画面一つとっても解像度、縦横比によって画面が見切れたり、不要なスクロールが発生します。
また、OSやOSに付随するソフトウェアのバージョンによって思わぬ動作の違いが出たりするため、必ず顧客と同等の環境でテストする必要があります。
一方、大衆に向けた製品である場合はサポートする環境がなんであるか?をよく確認し、 それぞれの環境で必要なテストを行う必要があります。
テスト条件と期待値が明確か
「ボタンを押下し正常に終了すること」
もはや何をテストするのかわかりません。
期待値としていくつか後ろに隠れているのだと思います。
- データがテーブルに正しく入っているか
- 正常終了を契機にダイアログが表示されるか
- 画面を再読み込みし、最新の状態を表示するか
など、一例ではありますが、本来見たい内容というのは頭の中にたくさんあるのだと思います。
また、「テーブルに正しく入っているか」 確認するためにどのようなデータを用意するか?も重要です。
フォームの中にたくさん入力項目があって、全てに100と入力しても正しく入っているか?はわかりませんよね。
条件についても同様です。
網羅的に条件を満たしてテストできるのか?を私は見ていますので、少なくとも条件が整理されていることが 重要となります。
終わりに
どちらかというと、細かい内容のチェックよりかは大枠のアプローチが正しいか?を見るようにしています。 確かに細かい内容の誤記などもあるでしょうが、多くはテスト中に間違っていた・・・と気付くと思います。 全く見ないとは言いませんが、まずはアプローチが正しいか?が重要ではないでしょうか。