こんにちは！早く夏になって毎日アイスを食べたい、SJC共同開発推進室の對島です。
早いもので、4月からはついに3年目がスタートし、エンジニアとして丸2年が経ちました。嬉しいことに去年同じ部署に後輩が一人増え、「教わる側」から「教える側」としての責任も感じています。また、最近は見積もりや設計といった「上流工程」に関わる機会も増え、仕事の重みを改めて実感しています。
そんな節目の今だからこそ、あえて書き残しておきたいテーマがあります。
それは、1年目の新人の頃から今日まで、ずっと泥臭く向き合い続けてきた「テスト」についてです。
正直、最初は「テストなんて、確認してチェックをつけるだけでしょ？」なんて思っていました。その甘い考えが上司からのレビューによって打ち砕かれた「記録」をここに残しておこうと思います。このブログが、皆さんにとっても今一度テストについて考えるきっかけになれば嬉しいです。
1. テストの全体像について
「テスト」と言っても、その種類は開発のフェーズに合わせて多岐にわたります。まずは全体像を軽くおさらいしてみましょう。
-
単体テスト：関数やクラス単位など、プログラムの最小の仕組みが正しいか確認する。
-
結合テスト： 画面や機能同士を繋げたときに、データが正しく受け渡されるか確認する。
- シナリオテスト： 実際のユーザーの動きを想定し、一連の業務が問題なく完結するか確認する。
-
運用テスト：本番と同じ環境で、システムを問題なく稼働・運用し続けられるか（バックアップや障害対応など）を確認する。
- 受入テスト：完成したシステムがお客様の要望通りに作られているか、最終的な承認をもらうために行う。
-
ランダムテスト： 予測不能な操作をぶつけて、予期せぬクラッシュ・不具合が起きないか確認する。
今回フォーカスするのは、すべての土台となる「単体テスト」です。
（※ちなみに私たちの現場では、厳密な関数レベルのテストだけでなく、画面ごとの細かい動作確認も含めて広く「単体テスト」と呼んでいます。）
当時の私が「まぁ動けばいいんでしょ？」と舐めてかかった結果、どうやって地獄を見たのかをお話しします。
2. 最初のレビュー記録を見てみる
入社して間もない頃、私は単体テストの項目作成を「ただの事務的な作業」だと思っていました。しかし、自分なりに「なかなかいい出来でしょ！」と思って提出したテスト項目は、上司のレビューによって指摘だらけの状態で返ってきました。
当時の「指摘事項」のメモが今でも残っています。一部を抜粋してみましょう。
当時のリアルな指摘事項
1016-0005 他： 「ボタンが非活性であること」とあるが、仕様上は「活性」が正解。そもそも仕様を読み違えている。
1016-0015 他： 「『』というカラム名の下にマウスカーソルの位置を示す『□』が表示されていること」……空白のカラム名は目視できない。「一覧の一番左に」等、具体的な表現を使え。
1016-0041 他： 期待結果に「▶の状態であること」とあるが、何を確認したいのか不明。「マウスカーソルの動きに▶が追従すること」と動作の本質を明記せよ。
1016-0052： 「状態の変更がないこと」……どの状態からの変更がないのか明記せよ。
1016-0068 他： 記載に「YESボタン」とあるが正確ではない。画面上の表記である「はい」ボタンに修正せよ。
1016-0123： 「ロールバックの実行確認」はどうやるのか？DBにデータがないことを見るのか、ログを見るのか。実施者の迷いをゼロにせよ。
いかがでしょうか。今読み返すと、当時の自分を説教したいくらいです。 特に「YESボタン」の指摘。「どっちでも通じるじゃん」と思うかもしれません。でも、実際にテストをやる人（テスター）は画面上の「はい」という文字を探しているんです。「YES」なんてボタンは画面のどこにも存在しません。
「テスト項目は、自分が分かればいいメモではなく、初めてその画面を見る人が絶対に迷わないものじゃないといけない」。これが、身をもって痛感した最初の教訓でした。
3.「良いテスト項目」の本質ってなんだろう？
ここで少し立ち止まって、「じゃあ、良いテスト項目の書き方ってなんなの？」という本質について、私が思うことを書いてみます。
結論から言うと、「誰がテストを実施しても100%同じ結果になること」。これに尽きるのではないかと思います。
一番良くないのは、実施する人によってOK/NGの判断が変わってしまうテスト項目です。本当はOKなのにNGにされてしまうのも二度手間で困りますが、最悪なのは「本当はNG（バグ）なのに、テスト項目の書き方が悪くてOKと判断され、見逃されてしまうこと」です。これではテスト工程を行う意味がありません。
正直、自分たちがテスト項目を作って、自分たちだけで実施するなら、多少手順の書きっぷりが雑でも「まぁ、こういう意味だよね」と脳内で補完して進められるかもしれません。 でも、テストって基本的に「第三者にやってもらうこと」が前提のはずです。
実際、私も他のシステムのテスト項目や、過去に人が作ったテスト手順に沿って実施した際、めちゃくちゃ困った経験があります。
-
「この画面ってどうやって行くの？」
-
「手順が不足してて、次の操作が分からない」
-
「これ、何をもってOKと判断すればいいの？」
テスト項目の作成は正直、時間がかかるし、泥臭くて面倒な作業だと思います。
だけど、ここでテスト作成者が手を抜いてしまうと、ダイレクトにシステムの品質に響くし、結果的に後からもっと多くの時間を溶かすことになります。
「未来の自分が楽をするため」にも、そして「テスターの時間を奪わないため」にも、テストはしっかりとした表現で書かなければいけないということですね。
4.単体テスト項目を作成する本来の目的
ここで、テスト項目を作成する目的について、私なりに整理し直した内容を紹介します。
テスト項目を作成する目的
-
プログラムの最小単位でバグを早期に発見し、システムの品質を担保する
-
テスト手順の記載により、新人を含め「誰が担当しても」正しくテストを実施できるようにする
-
第三者視点によるレビュー獲得により、仕様の勘違いやテスト観点の抜け漏れを防ぐ
-
テストのOK/NGの基準を明確にし、どこまでやれば「完了」かを誰が見ても分かるようにする
単体テストは、システムにおける最小単位（ユニット）を対象とするため、とにかく実施回数が多い工程です。だからこそ、現場ではテストに慣れていない新人が担当することも多々あります。 つまり、単体テストでどれだけ確実にバグを見つけ出せるかは、「テスト項目の出来栄えにかかっている」ということですね。
じゃあ具体的にどう書けばいいのか。ポイントは2つあります。
① テスト観点を明確に、わかりやすくする（曖昧さを排除する）
| よくない例（NG） | 良い例（OK） |
| 空白の場合の動作を確認 | 空白の場合、○○というメッセージが表示されるか確認 |
NG例だと、空白にしたときに「エラー画面になればいいのか」「何も起きないのが正解なのか」が分からない。正解をはっきりと書くのが鉄則です。
②テスト観点が漏れないようにする
観点の漏れは、そのままバグの残存（品質低下）に直結します。本来、テスト項目を作る際は、まず「要件定義書」や「設計書」を基に、画面ができる前に抜け漏れなく洗い出しを行うのが基本です。「設計通りに正しく作られているか」を確かめるテストなので、できた画面に合わせてテストを作るような、「形だけのテスト」になってはいけないんですね。
これらを防ぐために、第三者によるレビューを徹底することが重要になってきます。
世の中には「テスト観点カタログ」なるものがあって、一般的なテストで見るべきポイントが網羅されているそうです。
「どんなデータに対して、何を目的としたテストをするのか」が記載されているため、自分で項目を作るときや、レビューするときに意識してみるとすごく良さそうだと思いました。
また、設計とテストに抜けがないかを確認するために、項目同士の繋がりを紐付ける「トレーサビリティ」を取ることもあります。実は今年、私はこのトレーサビリティを意識して開発を進める機会がありました。これについては話すと長くなりそうなので、PM（プロジェクトマネージャー）ではない、「開発者（下からの観点）」から見たリアルな話として、また別のブログで詳しく書きたいと思います！
5. テストは「時間」がかかる＝「お金」がかかる
3年目となり、最近は工数の見積もりやプロジェクト計画について考える機会が増えました。そこで改めて再認識したのが、「ちゃんとしたテストをしようとすると、かなりの時間がかかってしまう（＝費用が上がる）」という現実です。
開発工程の中で、スケジュールが厳しくなったときに一番削られやすい（削ろうと考えてしまう）のが、「テスト工程」です。 でも、これまでの話の通り、ちゃんとした品質を担保するためには、テスト工程は絶対に必要です。そこに多くの時間がかかってしまうのは、仕方のないこと、むしろ必要なコストであると思います。
ただ、お客様の視点に立てば「できるだけ費用は安く抑えたい」と思うのも当然の話。 だから、お客様から「テストになんでそんなに時間がかかるの？」という意見が出てしまうのも、これまた仕方のないことだと思います。
「品質を守るためにテスト時間は削れないエンジニア側」と、「コストを抑えたいお客様側」。この費用とスケジュールのバランスをうまく調整することって、本当に難しいんだなと、3年目の今、改めて痛感しています。
6.「テスト品質」について
私たちの現場では、「テスト品質（バグ検出率）」という指標を出していました。
全テスト件数に対して、何パーセントのNG（バグ）が出たかを表す指標です。
NG率（％）＝（NG項目数 ÷ 全テスト項目数）× 100
私のプロジェクトでは、この値を「15%」に設定していました。
-
NG率が 15% を超えた場合： 「実装コードの品質が悪い。プログラムの出来が良くない」
-
NG率が 15% に届かなかった場合： 「品質が良い」あるいは、「バグを見つけられない、質の低いテスト項目しか作れなかった」
テストの目的は、あくまで「バグを出すこと」です。「バグが出ないことを確認するテスト」ももちろん大事ですが、バグを炙り出すテスト項目が作れていない可能性を疑う、というこのモノサシは非常に面白いなと思いました。ただ、一般的にこの「15%」という数字はどうなのか、他のプロジェクトではどの程度のものなのか、ぜひ意見を聞いてみたいところです。
7.まとめ：3年目を迎えた私の「テスト論」
最初の頃の私は、テストを「開発が終わった後の、事務的な作業」だと思っていました。
でも、2年間いろんな経験をして身に沁みて分かったのは、ここで手を抜いて一瞬楽をしたとしても、結局あとから何倍もの時間と大きなバグになって、自分やチームにツケが回ってくるということです。
「YESボタン」か「はいボタン」かという画面の細かい文言にこだわること。手順の1ステップを「初めて見る人でも絶対に迷わないか」に気を配ること。そういう地味で、一見すると「細かすぎるかな？」と思うくらいのこだわりが、実はシステムの品質を守るために一番バカにできないし、大事なことなんだなと、丸2年経った今になって本当に思います。
最近では、「この仕様に対してテスト観点に抜け漏れがないか」をAIにレビューさせたりすることも増えました。自分では気づけなかった観点を出してくれるので、めちゃくちゃ心強いですが、ツールが便利になったからこそ、人間側の「見る目」が試されているなと感じます。
3年目がスタートしたこれからは、部署に入ってきた後輩に「なんでこのテストが大事なのか」を、自分の言葉でちゃんと教えられる先輩になりたいです。見積もりや設計のときにも、スケジュールが厳しいからって簡単にテストを諦めず、「ここは絶対に削れません！」と自信を持って突っぱねられるような、頼れるエンジニアを目指して頑張ります！
皆さんもぜひ、ご自身のテスト項目を「これ、初めて見る人でも100%迷わないかな？」という視点で見返してみてはいかがでしょうか。
それでは、また次回のブログでお会いしましょう！
エコモットでは一緒にモノづくりをしていく仲間を随時募集しています。弊社に少しでも興味がある方はぜひ下記の採用ページをご覧ください！
