システム開発におけるテスト工程を勘違いしている人が多い。システム開発数多く立ち会っていて、そう思う場面に多々遭遇します。
その勘違いとは何か？
それはテスト工程が品質を上げる工程だと思っている事です。
「テスト工程で品質を作りこむ」これは大きな勘違いです。
え？テストに時間を掛ければ掛けるほど品質は上がるでしょ？
この考えに支配されている人がすごく多い。
そこで改めてシステム開発におけるテストについて纏めてみました。
実際に知っているつもりでも突き詰めてみると「？？」となったり、「どういう事？」という事もあったりするかも知れません。
特にこれからITの現場に飛び出る若手には是非とも読んでもらいと思います。
テストについて
まず、本題に入る前にテストについてを大雑把にまとめます。
テストとは？
システム開発におけるテストとは何でしょうか？
分かりやすい様に開発手法をウォーターフォール型として説明します。
システム開発におけるテストとは何でしょうか？
端的に言うと「実装に問題がない事を確認する」事です。
テストをする理由・目的
テストをする理由・目的とは何でしょう？
テストを実施する理由・目的は主に次の様に言われています。
- 品質の担保
- バグの検出
- 品質の改善
この3つの内、一番重要なのは品質の担保です。テストはその為にあると言っても良いでしょう。
この成果物はこのテスト項目をクリアしたので品質に問題ありません！
と太鼓判を押すためにテストが存在します。
バグの検出、改善は副産物的なものだと言えます。
完全に私個人の意見ですが、テスト工程はバグを潰すのが目的では無いと考えています。仕様通り、要求通りに動作する事を確認して次工程、出荷して良いかを確認する事がテスト工程の本来の目的です。
テストの要点
テストは品質の太鼓判を押す、品質を担保する為にするという事はわかりました。
何をどうしたら担保する事が出来るのでしょうか？
細かいことは置いておき、大雑把に考えるとそれは至極単純な事です。
利用者が想定する全てのルートで意図する結果になる
これだけです。
重要な事は「利用者が想定する全てルート」であって、「コードから見た想定する全てのルート」ではない点です。
テスト項目の洗い出しでは、利用者が想定するルートを洗い出す事が非常に重要です。
その全ルートとはなんぞや？を効率良く求めたり、理論的にまとめられているのが各種テスト手法となります。
テストの種類
実際の現場で出てくるテストの種類としては次の物があります。
- 単体テスト
- 結合テスト
- 総合テスト
呼び名はプロジェクトや現場によってマチマチだったりします。
テストの観点がプログラム寄りであったり、ユーザー寄りであったりします。
テスト工程は品質を作りこむ場ではない
さて、いよいよ本題です。
システム開発の現場で勘違いされやすいポイントとして、「テスト工程で品質を上げる」と意識されている点です。
この考え方の人はテスト工程に時間（工数）を掛ければ掛けるほど品質が上がると思っています。
この考え方はNGです。
何故でしょうか？
テスト工程は品質を上げるための工程ではなく、品質を担保するための確認作業を行う工程なんです。この段階ではテスト項目は全て合格になっていないといけない訳です。この段階では既に品質は決定づけられていて、利用者に提供できるレベルなのかどうか？を確認する工程なんです。
出来上がったもののデバッグは非効率
そもそも理解しておく必要があるのが、出来上がったもののデバッグは非常に非効率であるという事です。出来上がる前にデバッグしてしまえば修正コストは大幅に下がります。
この観点からもテスト工程でバグを抽出して品質を改善する考え方は間違っていると言えます。
正直、テスト工程でバグを沢山抽出して「品質上がったね！」なんてプロジェクトは見たことがありません。品質が良いプロジェクトはテスト工程でバグが検出されてきません。
品質を作りこむ場はどこなのか？
では、品質を作りこむ場はどこなんでしょうか？
テスト工程で利用するテスト項目の内容で合否を判定するとなると、テスト項目が品質を握っていると言えます。では、テスト項目の作りこみが品質の作りこみになるのでしょうか？
この考え方は正解です。
テスト項目は何をベースで作られるのでしょうか？
- 単体テストであれば詳細（プログラム）設計書
- 結合テストであれば基本設計書
- 総合テストであれば要件定義書
これらの設計書をベースにテスト項目が作成されていきます。
この時のテスト項目を作る意識が重要です。
「テスト項目は設計書の確認」の意識で作成している場合、品質は何も向上しません。
ここが大切なポイントです。テストの手法とか色々と出回っていますが、テスト項目を作成する際に確認事項だけを纏めている限り品質の限界突破はありえません。
テスト項目を抽出する際に一番大切なの事は「設計書の検証を行いながらテスト項目を作成する」事です。
「設計書の検証を行いながらテスト項目を作成する」意識で作成している場合、テスト項目の洗い出しをしながら同時に品質の作りこみがなされます。要するに設計書に潜むバグを全て洗い出す意識でテスト項目を作成する事が重要になります。机上デバッグなんです。設計書の机上デバッグ。設計書通りに机上で動作させながらシミュレーションするのがテスト項目作成で重要な事なんです。
この意識の差がすごく大きな差を生みます。テスト項目の作成は設計書の検証工程です。テスト工程の作成はスキル的には非常に高い能力を求められます。品質上の最後の砦と言っても過言ではありません。
テストファーストの考え方
テストファーストの考え方もこの考え方に則っています。
テスト項目を洗い出す事で検討を行い、早めにバグを抽出する事が大きな目的です。
担当を全て分ける事が重要
設計者、テスト項目作成者、テスト実施者。これらの担当者を全て別にする事も品質を上げる上で非常に重要です。
設計内容やテスト項目にバイアスが無いニュートラルな状態な人が実施する事で、ナチュラルなランダムテストの実施、また矛盾点のツッコミが増えます。また、システム習熟度が低い人により掘り下げて説明をする必要が出てきます。その段階で考慮漏れなどの気付きが生まれやすいです。
全てを自己完結させると設計の段階で「これは分かってるからいいや」と記載を省いたりしがちです。これは効率ではなく手抜きです。それらを回避する為にも担当は別にする事が肝心です。
当然バグは検出される
テスト工程は確認作業といってもバグが検出されない訳ではありません。当然、検出されます。しかし、それはヒューマンエラー系、ケアレスミス系のバグに限定されてきます。仕様に関する事、実装漏れなどの障害はテスト段階で発見されるのは致命傷です。これらは少なくともテスト項目の洗い出し段階では検出されるべき内容になります。もしも、テスト工程でそれらが発見されるとなると、そのシステムは品質が著しく低い状態です。
また、テスト項目の洗い出し中に見つけた不具合もバグとしてカウントしておく事が必要です。バグ抽出数が品質を担保する指標になります。
まとめ
まとめます。
以上が本記事で伝えたい内容になります！
コメント