ソフトウエアの品質を守る最後の砦はテスト
ソフトウエアをリリースして良いかを判断する重要な指標の一つにテストの結果があります。
テストは開発者と別の人が、仕様書と付きあわせて検査項目を作り、一つ一つ検査していきます。
開発者は自分でプログラミングしているので問題ないはずと思っていますし、またある程度の規模以上では複数人で開発することがほとんどなので、個々の部分には問題がなくても全体で動かすとお問題が起きることもあります。
ですので、第三者がソフトウエアの全体をくまなく検査することが求められます。
テストはソフトウエアの品質を決める最後の砦なのですが、問題はきちんと検査項目をしっかり出し、機能のほとんどをカバーできているか、ということがとても重要になります。
テストは期間の定めもあり、人員の制約もありますので、テストの網羅率を高めた上で効率的に進めていくことが求められる、非常に重要な仕事です。
検査項目は正常系と異常系をカバーする
検査項目を作るとき、仕様書の記述に沿って検査項目を作っていきます。
開発者はプログラムのコードのすべてをカバーできるようにプログラムベースのテストしますが、テストで行う工程ではプログラムがどう作られているかではなく、機能が仕様書通りに動くのかで検査します。
機能的には大きく正常系と異常系に分かれ、正常系とは通常の操作で問題なく動作する場合のことを言います。エラー処理も決まっている場合は、これも正常系に含みます。
例えば、入力画面で入力できない文字を入力したときにはじくようにするのは正常系に分類されます。
異常系とは、正常な動作をしたにもかかわらず起きる場合で、入力がサーバーに通知されたのに保存されていないとか、保存できていないことがわかり別の部分がアラートを出したとか、そういったときの処理になります。
正常系、異常系、どちらもシステムの機能として不可欠です。
両方をカバーしてはじめて検査項目としてできたということが言えます。
異常系のテストが難しい
異常系もテストに必要なのはわかっていても、異常系とはそもそも通常の仕組みの中で起きにくいことなので、なかなか現象を起こせないというジレンマがあります。
そのテストのためには、いかにして異常に近い状態を発生させるか、ということがカギになります。
そのためには開発者の協力が不可欠になる場合もあります。
やりたい異常系の状態にもよりますが、例えば内部的に異常な状態を作り出すわけですね。
なかなかこういうテストは難しく、機能の100%をカバーしていくことは至難の業です。
それでもテストが最後の砦である以上、できる限りカバーしていくことが求められます。
どうしてもテストできないものは、開発者がテストしていることでよしとする場合もあります。
網羅性の高い検査項目を作る
検査項目を出すとき、組み合わせとして多くのことをカバーするのが大切です。
やみくもにたくさんやっても、同じことを検証しているだけということになりかねませんし、いかにテストの網羅性を上げるかということに注力しましょう。
網羅性を上げるためには、組み合わせとして違うパターン作ったり、値として意味の違うものを与えることによって、プログラムの違う経路を確認したりします。
そのためにも、機能仕様を理解して、通常はこういう動作をするが、これこれのときは別の処理をしているなということを理解して、通常と別の処理をしているパターンを分けてテストをするということになります。
その辺の検査項目の組み方は少々熟練する必要があるとは思いますが、既存のテスト項目をみながら学んでいくことが大事でしょう。
テストの効率化を目指す
テストは最後の砦ですが、何でもかんでもテストでカバーすることはできません。
時間は限られますし、テストの人員も必要な分だけ提供されるわけでもありません。
そこで効率的なテストの実施が求められます。
検査項目の順序の組み方次第で、1つの手順で2つ以上の検査を実施できる場合もありますし、組み合わせとして減らせる場合もあります。
テストの順番によって同じことを繰り返す手間を減らせることもあります。
テストの進捗やテストの目的にもよりますが、テスト項目に書かれた通りに順にやるのではなく、効率的な実施方法も考えながらやることも大事です。