1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

バグを事前に防ぐテスト設計

Posted at

テスト設計について学んだこと

今回テスト設計の案件にアサインしてみて学んだことや疑問点やプログラムを見る視点が変わりました。
ソフトウエアを作るにあったてどうしても付きまとうのがバグだと思います。
このバグの原因関しては設計書が間違っていたり様々な要因でバグが発生すると思います。
その多く8割はヒューマンエラーだと考えます。
今回のテスト設計は、テスト項目書の作り方でバグを生み出さないように誘導することを第一に考えて作成してます。このことについてまとめます。

試験方針と重要ポイント

試験の方針として重要なポイントが3つあります。

範囲

テスト計画で大まかなテスト範囲を定め、具体的にどのシステム内のどの機能をテストするのかを決めます。
すべての機能をテストすることが理想ではありますが時間や工数の問題的に現実的ではないので重要度の高いものや新しく追加されたものなどを中心に範囲を設定することが重要です。

観点

各テストの範囲と目的を鑑みて、テストで確認すべきことを定めます。
例えば、仕様書通りに動作するか、類似システムや機能と比較したときに一般化されている動作をするかなどを確認します。観点が定まらなけれ統一性のないバラバラなテスト項目書ができてしまうので作成者全員が共通の観点で作成する必要があります。

条件

テスト観点を確認するために必要な入力データや操作などのバリエーションを決めます。バリエーションは範囲と同じで多いほうがバグは検出しやすくなりますが、多すぎると工数やスケジュール、予算を圧迫することになるのでバランスが必要です。
例えば検索の抽出条件が10個あるとします。ここで10個抽出条件を1つ1つ確認してしまうと工数も手間も多くなってしまいます。このような場合は下記のようにすると網羅的にかつ工数も少なくできます。

試験1 すべて条件が抽出できる場合データ
試験2 すべての条件が抽出できない場合のデータ
試験3 抽出条件のうち1つだけ抽出できない場合のデータ(抽出できない項目は任意で選択)
試験4 複数の抽出条件が抽出できない場合のデータ

データシート
データシート作成するとより見やすくわかりやすいと思います。
データシート作成関しては今後また別でまとめます。

試験方針に関してまとめ

上記の3つのポイント抑えることがとても重要だと思いました。
よくある課題としては、属人的になりやすいことが挙げられます、作成者の知識や経験の差によりテストとしての妥当性に疑いが出てしまう場合やテストケースに漏れがでたり、反対に無駄なテストケースが増えてしまう場合などテスト品質に大きな影響を及ぼします。この3つ重要ポイントをしっかり定めテストの定型化をすることで属人的にならず作成者ごとに差が出ることが少なくなると思います。

テストケースの作成

テスト方針を定めた後、テストケースの作成に入ります。
確認すべき項目の欠如やテスト結果の基準の正誤が発生してしまうとバグの原因になると思います。
そのためテストケースには、下記の4つを記載し漏れや重複などが発生しにくい状況を作ります。

テスト観点(確認内容)

これは当たり前ですが、確認内容の記載をします。テスト実行者がシステムの動き方の理解の有無に関わらずどうゆう意図で観点をつくり、どこを確認したいかを具体的に明確に記載します。
例えば、コンボボックスとそれに連動するテキストボックスのテスト観点だと、選択したコンボボックスの項目に該当する内容がテキストボックスに表示されること。このように具体的に記載することが需要です

テスト条件

テストの条件としてはテスト観点どおりの動作をするデータを事前に指定しておいたり、テスト事項者に用意してもらうデータの条件を記載しておきます。ダイアログが出るようなシステムなどではダイアログ内の動きの記載してあげるとよりわかりやすいと思います。

テストの手順

テストを実行するための手順を記載しておくことも重要です。
これを記載しておかないと類似したテストなどで見たい観点は共有できているのに手順が違うせいで違う結果が出てしまいテストの妥当性を保てなくなるからです。
実行者にも記載してあげることで有識者でなくてもスムーズにテスト実行できることにもつながると思います。

期待値

これは簡単に言ううとテストの結果です。
しかしこの書き方によってはテスト結果としてほしいエビデンスを間違ってしまう可能性も出てくるので注意が必要です。この期待値の書き方でバグを減らすことも誘導できると思います。例えば、「この正しい値がでること」とだけ記載してしまうとその数字が出ることしか確認させることができません。しかし書き方を工夫して、「〇〇テーブルの××項目の値が出ること」記載すれば、テーブルの動きや該当の項目まで確認させることができるので書き方でバグを事前に防ぐことができます。

まとめ

今回はテスト構築に関して重要な方針とテストケースについてまとめました。
テスト方針はバグを事前に防ぐためには重要なことでテストケースでそれを具体的に示すことができます。
テストの定型化を進めることでだれでも網羅的にテストをできるようになると思います。
期待値の書き方やデータシートやテストパターン表について理解が深まりしだいまとめたいと思います。

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?