その実施しているテストケースには、どのような意味がありますか？
テストを行う中で感じたことをまとめた記事になります。
そもそも、開発で行うテストとは？
システム開発において、欠かせない工程の一つが「テスト」です。
テストは、ユーザーがシステムを利用する前に、システムエラーやデータ不整合などの不具合がないかを確認するために行います。
テストを行わないままリリースしてしまうと、リリース後にシステムが使えない、不正なデータが作成される、そもそも正常に動作しない、異なるデータが表示されるといった、さまざまな障害につながる可能性があります。
最近では、自動テストによって、想定した結果が想定どおりに出力されているかをプログラムで確認する方法も一般的になっています。むしろ、現在では自動テストが業界標準に近い位置づけになっていると言ってもよいかもしれません。
しかし、古いシステムであったり、自動テストの存在を知らない、あるいは導入する予定がない現場では、テストケースを作成し、人の手でテストを実施する必要があります。
人の手でテストを行うこと自体は、決して悪いことではありません。
ただし、手作業によるテストは、どうしても手間も時間もかかります。
その分、コストが大きくなりやすい工程でもあります。
だからこそ、人の手で実施するテストでは、
「そのテストケースには本当に意味があるのか」
「誰が実施しても同じように確認できる内容になっているのか」
を考える必要があります。
テストケースの意味は、テスト工程によって変わる。
一言で「テスト」といっても、すべてのテストケースが同じ目的で作られるわけではありません。
現場開発では、UT,IT,ST,(UAT)といった工程ごとにテストを行うことがあります。
それぞれの工程では、確認したい観点や、テストケースに求められる役割が異なります。
UTでは処理の正しさを確認し、
ITでは機能同士の連携を確認し、
STではシステム全体として業務が成立するかを確認します。
この違いを意識しないままテストケースを作成すると、確認すべき内容が曖昧になります。
その結果、同じような確認を何度も行ったり、逆に本来確認すべき観点が抜けたりする可能性があります。
テストケースは「何を確認するためのものか」を明確にする
テストケースを作成するときに大切なのは、作業として項目を埋めることではありません。
そのテストケースが、何を確認するためのものなのか。
どの不具合を見つけるためのものなのか。
誰が実施しても、同じ判断ができるようになっているか。
これらを明確にすることが重要です。
特に、人の手でテストを実施する場合、テストケースの内容が曖昧だと、実施者によって確認方法や判断基準が変わってしまいます。
ある人は問題なしと判断し、別の人は不具合と判断する。
ある人は確認できるが、別の人は手順すらわからず確認できない。
このような状態では、テストケースが品質を守るものではなく、ただの作業一覧になってしまいます。
無駄なテストケースになていないか？
無駄なケースとは、単に「数が多いテストケース」のことではありません。
必要な確認であれば、テストケースの数が多くなること自体は問題ではないのです。
問題なのは、品質向上につながらない確認を、理由もなく繰り返している状態です。
例えば、本来確認すべき範囲を超えて必要以上に細かい確認をしているケースがあります。
また、同じ操作やおなじ結果を何度も確認しているだけで、実質的には同じテストを繰り返しているケースもあります。
特に注意したいのは、ビジネスロジック上、結果が変わらない処理を何度も確認している場合です。
入力値や条件を変えているように見えても、内部的には同じ処理を通っており、期待結果も変わらないのであれば、その確認を何度も行う意味は薄くなります。
また、「なぜこの確認をするのか」が説明できないテストケースも、無駄になりやすいです。
過去のテストケースをコピーしただけの項目や、仕様変更後も見直されていない項目は、実施しても品質向上にはつながらない可能性があります。
さらに、UT,IT,STで同じ観点を重複して確認している場合も注意が必要です。
UTで確認すべき処理単体の結果を、ITやSTでも同じ粒度で繰り返していると、テスト工程ごとの役割があいまいになります。
もちろん、重要な処理を複数の工程で確認する事自体は問題ではありません。
しかし、その場合でも、UTでは単体処理の正しさ、ITでは機能間の連携、STでは業務として成立するか、というように確認する目的を分ける必要があります。
テストケースは、数を増やせば品質が上がるものではありません。
大切なのは、そのテストケースが何を確認するためのものなのか、実施することでどのような不具合を防げるのかを説明できることです。
無駄なテストケースが増えると、実施時間が長くなるだけでなく、本当に確認すべき重要な観点が埋もれてしまいます。
複雑なテストケースになっていないか？
実際にテストを行う上で、とても重要になるのが「テスト手順」と「想定結果」です。
テスト手順は、必ずしも1操作ごとに細かく記載する必要はありません。
しかし、「ログインする」「ファイルをアップロードする」といったように、最終的に何をするのかだけが記載されているテストケースは注意が必要です。
また、想定結果についても同じです。
「正常に終了すること」「データが登録されていること」のように、確認内容が大まかにしか書かれていない場合、実施者は何をもって正常と判断すればよいのか分かりません。
たとえば、「データが登録されていること」と書かれていても、どの画面で確認するのか、DBを確認するのか、どの項目がどの値で登録されていればよいのかが分からなければ、確認する人によって判断が変わってしまいます。
一見すると簡潔に見えますが、実施者はその手順を見ただけでは、どのユーザーでログインするのか、どのファイルをアップロードするのか、アップロード後に何を確認するのかを判断できません。
その結果、テスト実施中にデータを探したり、設計書を確認したり、作成者に確認したりする必要が出てきます。
このようなテストケースは、見た目はシンプルでも、実施する側にとっては複雑なテストケースです。
複雑なテストケースとは、手順が長いテストケースだけをさすわけではありません。
むしろ、必要な情報が不足していることで、実施者が自分で判断しなければならないテストケースの方が危険です。
例えば、以下のような情報が不足している場合です。
- 使用するログインユーザー
- 事前に必要なデータ
- 使用するファイル
- 入力する値
- 操作後に確認する画面
- DBや出力ファイルなどの確認方法
- どの状態になればOKなのかという判断基準
これらが記載されていない場合、実施者はテストケース以外の情報を探しながら確認することになります。
その時点で、テストケースは「誰でも同じように確認できるもの」ではなくなります。
テストケースに必要なのは、細かさではなく、実施者が迷わず確認できるだけの情報です。
詳細すぎても読みにくくなり、情報が少なすぎても実施者の判断に依存します。
重要なのは、確認に必要な前提・手順・期待結果・確認方法が明確になっていることです。
自己満足なテストケースになっていないか？
テストケースを作成するときに注意したいのが、自己満足なテストケースになっていないかという点です。
ここでいう自己満足なテストケースとは、品質を確認するためではなく、作成者自身が安心するために入れているテストケースのことです。
例えば、以下のような考え方で追加されたテストケースは注意が必要です。
- やっておけば安心できる
- いつもやっているから今回もやっておく
- レビューで指摘をもらうかもしれないから入れておく
- テストケース数の多い方が、しっかり確認しているように見える
- 不安だから、関係しそうなところを全て確認しておく
- 過去に実施していたから、そのまま残しておく
もちろん、不安な個所を確認すること自体悪いことではありませんし、過去のテストケースを参考にすることも必要です。
しかし、そのテストケースが「何を確認するためのものなのか」を説明できないのであれば、品質向上にはつながらない可能性があります。
テストケースは、作成者が安心するためのものではありません。
実施者が迷わず確認でき、レビュー者が確認意図を理解でき、最終的にシステムの品質を担保するものです。
そのため、「念のため」「いつもやっているから」「指摘されそうだから」という理由だけでテストケースを増やしていくと、テスト全体が重くなっていきます。
結果として、本当に確認すべき重要な観点が埋もれてしまい、テストケースの数は多いのに品質にはつながらない状態になってしまいます。
テストケースに必要なのは、作成者の安心感ではなく、確認する目的と判断できる根拠です。
属人化したテストケースになっていないか？
テストケースを実施するために、特定の人の知識や経験が必要となている状態は好ましくありません。
もちろん、専用のツールの利用権限や、システム権限などのセキュリティ上の理由により、実施できる人が限られる場合はあります。
そのような制限は、運用上必要なものです。
しかし、本来は誰でもできるはずなのに、テストに必要な手順や前提を知っている人でなければ実施できない状態は問題です。
例えば、以下のような状態です。
- どのようなデータを使えばよいか、作成者しか知らない
- どのような画面から操作すればよいか、経験者しか知らない
- どの値を入力すればよいか、使用を理解している人しか判断できない
- どこを確認すればOKなのか実施者によって判断が変わる
- 事前準備の方法が書かれておらず、知っている人の聞かないと進められない
- エラーが出たときに、それが不具合なのか、手順ミスなのか判断できない
このようなケースは、表面上はテストケースとしては成立しているように見えますが、実際には「その人だから実施できるテスト」になってしまいます。
属人化したテストケースが増えると、テスト工程全体の負担が大きくなります。
実施者はテストケースだけでは、作業を進められず設計書を確認したり、過去の資料を探したり、詳しい人に確認したりしなければなりません。
また、特定の人が不在になるとテストが止まる可能性もあります。
理解している人がいなければ、テストケースの意図が分からず、正しく実施できないまま形だけ確認が進んでしまうこともあります。
これは、テストケースの品質だけでなく、テスト結果の信頼性にも関わります。
テストケースは、作成者の頭の中にある前提を捕捉するためのメモではありません。
誰が実施しても、必要な前提・手順・確認方法・期待結果を理解できるようにするためのものです。
そのため、テストケースを作成するときは、「自分ならわかる」ではなく「初めて実施する人でも迷わず確認できるか」という観点で見直す必要があります。
テストケースは、作成者が分かるためのものではなく、実施者が迷わず確認するためのものです。
テストケースは、誰が実施しても同じ品質に近づけるためのもの
テストケースは、数を増やせば品質が上がるものではありません。
重要なのは、そのテストケースが何を確認するためのものなのか、実施することでどのような不具合を防げるのかを説明できることです。
無駄なテストケース、複雑なテストケース、自己満足なテストケース、属人化したテストケースが増えると、テスト工程の負担は大きくなります。
そして、本当に確認すべき重要な観点が埋もれてしまう可能性があります。
テストケースは、作成者が安心するためのものではありません。
実施者が迷わず確認でき、誰が行っても一定の品質で判断できるようにするためのものです。
だからこそ、テストケースを作成するときは、
「この確認には意味があるか」
「実施者が迷わず確認できるか」
「品質向上につながっているか」
を常に意識する必要があります。
テストケースは、現場やシステムの特性によって必要な内容が変わります。
だからこそ、今一度、皆さんの現場で実施しているテストケースを見直してみてはいかがでしょうか。
「私の現場では、こんなテストケースがありました」
「このようなテストケースは無駄になりやすいと思います」
「逆に、この確認は必要だと思います」
など、さまざまなご意見をいただけると幸いです。