#はじめに

また、久しぶりに過去のSIer時代を思い出して、テストの大切さやポイントについて
振り返ってみたいと思います。

システム開発にとって「テストは切っても切り離せないもの」と頭では理解していても、
いざ、テストフェーズになると、プログラムを書きながら動くものを見て「おぉー、できた！できた！」
とやっていたときに比べ、どうしてもやる気が起きませんよね、、、。

でも、最初にちゃんとテストをやっておかないと、あとでデータの不整合など発覚した際、
それを修正するためにシステム停止を伴ったり、最悪損害賠償なんて話も持ち上がるかもしれません。

そのため、テストはとても重要なフェーズになりますが、
皆さんはなぜテストを行っているのでしょうか？

#なぜテストは必要なのか？

テストを行う理由や考えは人それぞれあると思いますが、
一番大事なのはユーザーの要求を満たせているか（要件通りの機能になっているか）を確認する
ためではないでしょうか。そのために一つ一つ動作を確認して、システムの不具合がないかを検証する
ことが必要になります。

もちろん、それ以外にも下記のような考えもあるかと思います。

システムが要求通りに動いているか確認するため
不具合を早期に発見するため
不具合が発生した際の修正工数が大きいから
不具合が発生した際のシナリオ確認、再テスト工数を減らすため
会社の信用を落とさないため
納品物だから（請負時など）　etc..

不具合を修正する工数って大きくないですか？

今まで案件対応を行ってきた中で、みなさんもご経験があるかと思いますが、
不具合を対応する工数って非常に大きくないですか？

そう、上記の理由のうち、何気に大きいのが**「修正工数の大きさ」**になります。

もちろん簡易な（影響範囲の少ない）不具合であればサッと対応することも出来ますが、
本番稼働後に見つかった不具合は、開発中に仕様通り実装するよりも、
「何処でどんな不具合が起きているのか」を見つけるのも本当に大変ですし、
修正するにしても影響範囲を調査して、何処まで修正する必要があるのか確認し、
リリース手順やタイミングも検討して、クライアントとも早急に調整しつつ結果を報告するなど、
謝罪も含めると対応工数が機能を開発するよりぐんと掛かることもよくあります。

また、想定外の修正工数によってスケジュールが遅延するなんてことも起きるかもしれません。
テストを疎かにすると、色んなところに影響するので、やっぱりテストって大事ですよね。

#テストを行うタイミングは？

テストは概ね下記のタイミングにおいて実施されます。
それぞれ設計段階で作成したドキュメントをインプットとし、テスト仕様書を作成するため、
ユーザーの要求をテスト内容に反映することが出来ます。

逆に言えば、要件定義フェーズの抜け漏れや、設計フェーズにおいて上流工程からの仕様の抜け漏れが
発生すると、当然テストケースも抜けることになるため、しっかり要件を確認しつつ設計を進めること
が重要になりますね。参考：こんな時代だからこそ要件定義の重要性を思い出せ！

（ウォーターフォールモデルにおけるV字モデル）

#テストケースってどう書いているの？

テストドキュメントには色々種類がありますが、例えば下記の画面の
結合テスト（ブラックボックス）のケースはどのように作成するのが良いのでしょうか。

私も、所属した会社によってテストドキュメントのフォーマットが様々だったので、
どの書き方が良いとか悪いとか言えるほど知見があるわけではないのですが、、
過去経験したことがある書き方には下記の2つがありました。（ご参考までに）

例えば下記の画面におけるテストを実施するとした場合、

1．テストケースを文言で記載する方法

この方法はシンプルなため、比較的誰でも作り易く、サッと作ることが出来ると思います。
ただし、ちゃんとレビューをしていないと、テストケースの漏れや、同じようなテストケース（重複）、
人による表現の違いなど、時間を無駄に使ってしまうこともあるかもしれませんね。

2．デシジョンテーブルを利用する方法

この方法は、文言で記載するより条件の組み合わせ（ロジック寄り）で記載するため、
網羅性は上がり、テストの無駄も少なそうですが、ちゃんと考えて作らないと、
おかしな（あり得ない）組み合わせのケースを作ってしまうかもしれないです。

簡易なテストなら、1．の方法でもサクッと作成／実施することが出来ますし、
複雑な画面や状態遷移を含むテストであれば、2．の方が網羅性の担保が行えると思います。

ただし、どちらにも言えることは仕様をしっかり理解した（している）人が記載する必要があります。

※ テスト計画書やテスト仕様書の記載は割愛しますが、テスト観点の整理、シナリオ／手順、
テスト環境／データなどを事前に準備しておく必要があります。

特にテスト観点（何をどんな切り口で評価するのか）はしっかり整理しておかないと、
テストケースが漏れたり、逆に不要なテストケースを作ったりと無駄な工数が発生してしまいますし、
作成者による評価基準のバラつきが生まれるため、初めに定義しましょう。

#その他、記載する上で気を付けること

その他、テストケースを記載する際に気を付ける（意識する）こととして、
「誰がテストをしても同じ結果を得ることが出来る」ではないでしょうか。

もちろんテストケースの抜け漏れがあっては、そもそものテストになっていませんが、
記載内容が曖昧で、AさんとBさんがテストした結果、AさんとBさんで異なる結果が出てくるような
書き方は注意しないといけないですね。

余談ですが、メールを書くときも同じで、自分では伝わるつもりで書いていても、
言葉が足りなかったり、省略していたりで、思ったように伝わらないことってありますよね。
テストケースもテストする相手に伝わらなければ意味がありません。

そのためにはテストを実施する前の準備・条件もしっかり定義しておく必要があります。
私が過去関わった案件でもテストケース作成者と実施者が異なるケースは良くあったため、
自分だけが分かる書き方は注意が必要です。

#ユーザー視点でテストケースを考えることも大事

なぜテストを実施し、品質を上げる必要があるかというと、上述したように
ユーザーの要求を満たせているかを確認することを目的としています。

そのため、テストケースを考える際は、ユーザーの視点に立って
「こんな使い方もありそう」「こんな使い方をしそう」という観点・意識を持つことで、
想定外のケースを未然に防げるかもしれませんね。

#まとめ

テストはユーザーの要求を満たせているかを確認する作業
リリース後の修正工数／作業はとても大きく大変である
設計資料とテストケースは対である
要件定義や設計段階で抜け漏れがあるとテストケースも抜ける
テストケースは仕様を理解している人が書く
テストケースは曖昧に書かず、誰もが同じ結果になるように書く
ユーザー視点に立った使い方を考慮する（想定外の使い方も考慮する）

#おわりに

テスト作業は開発に比べ地味で大変な作業のように感じる方もいらっしゃるかと思いますが、
一つ一つのテストをおざなりにすると、不具合が発生した際に後でとんでもない工数が掛かったり、
場合によっては会社の信用にかかわったりと、後悔してもしきれない状況になることがあります。

もちろん不具合を起こさない、リリース前に発見して修正している、ことは理想ですが、
大規模なシステムになればなるほど、難しいですよね。。。
そんなときこそ単体テストからしっかりテストをしておくだけで、後になってのやり直しや、
改修作業によるスケジュール遅延など起こさずに済むのかもしれませんね。

私の過去の経験では、すごく作るのが早くてバグが多めなメンバーがいました（トホホ）。
ただ、開発をグッと進めるにはすごく有益なメンバーだったので、
当時はテストをしっかり見てあげれば進捗が捗るのかも！？と思ったこともありましたが、
やっぱりテストの観点だったり、慎重なメンバーの方が結果的に早く終わった気がしますね。

少しでもこの内容が何かのお役に立てれば幸いです。