この記事は セゾンテクノロジー Advent Calendar 2024 14日目の記事です。
シリーズ2は HULFT10 のエンジニアによる投稿をお届けします。
はじめに
私はHULFT10プロジェクトでWindows版やLinux版などを開発するオープン系のチームリーダー(TL)を務めました。役割としましては、チームマネジメントに加え、設計書やソースコード、テスト項目のレビューを主に担当しました。プログラミングに関わる業務は多くありませんでしたので、今回はプログラミングに直接関わるようなものではなく、私自身が課題に感じている「テスト項目作成」に焦点を当ててみようと思います。なお、本記事は自動テストではなく手動テストについての内容になります。
テスト項目作成にて発生する問題点
テスト項目の作成は意外に大変な業務だと感じています。観点を洗い出して、それを手順に落とし込んで、期待値を明確にする。こう書くとシンプルなのですが、実際にはいろんな壁にぶつかります。そこで、どんな問題があるかを振り返ってみようと思います。
1つ目は「観点はしっかり書かれているけど、手順が曖昧」であるパターン
「こういうケースをテストする」という観点はきちんと書いてありますが、具体的にどうやってテストするかの情報が不足していることが多々ありました。結果、テスト実施者が「これはどうやって確認するの？」と迷う場面が出てしまい、作成者に確認が戻ってきてしまいました。
2つ目は「手順は細かく書いているけど、観点が不明瞭」であるパターン
具体的な手順がきちんと書かれていますが、それがどんな観点を検証しているかが読み取れないものがありました。この場合、テスト項目をレビューする人が観点を一つ一つ洗い出す必要が出てきて、効率が悪くなりました。
3つ目は「確認する期待値が曖昧」であるパターン
例えば「エラーメッセージが表示される」とだけ書いてあっても、それが具体的にどんなメッセージなのか分かりません。これだと実施者が結果を判断できず、作成者に確認が戻ってきてしまいました。
これらの問題は、スケジュールを理由にして細かく見直す時間を取らなかったことが原因にあります。「もっと丁寧にやりたかった」と思いつつ、特に手順と明確な期待値が用意できていない場合が多くて、テスト実施工程の負担にしてしまっている感がありました。
理想
本当はどうしたいかというと、以下の3つをしっかり整えたいと思っています。
テスト観点を明確にする
テスト観点に漏れがあるとバグの検出漏れに直結するため、テスト項目作成において最も重要なことだと思います。まず、観点とすべきポイントはどれで理由はなんなのか？洗い出されたポイントの組み合わせから本当に必要なパターンはどれなのか？を明確にすることで、レビュアが「漏れがないか」を簡単に確認できるようしたいです。
テスト手順を詳細に書く
観点から展開されたテストケースそれぞれに手順をしっかり書き込むことで、テスト実施者が迷わず進められるようにしたいです。但し、この件については悩ましいところがあって、どのレベルのテスト実施者に合わせた手順とすべきかは考える余地があります。本件でいえば理想はHULFT初心者でも困らないほど明確に書くのが良いですが、ではIT初心者でも困らないほど明確に書くのかと言うとそれはやりすぎだと思いますし、バランスが難しいところです。
期待値を具体的に記載する
判定基準を誰が見ても分かるレベルで明確化したいです。曖昧な内容はなるべく避けたい。例えば、「処理が正常に終了すること」ではなく、「コマンドの終了ステータスが0であること」とか「『処理が正常に終了しました』というメッセージボックスが表示されること」のように。他にも「ファイルに出力される」とかも具体的にどのファイルに何が出力されるのか具体的に書くのが望ましいです。
今後の取り組み
では次回以降どうするのか。時間が無いなりに改善できるポイントを考えてみました。
テンプレートの改善
現在使用しているテンプレートはテスト観点と手順が混在して記載されることが多く、項目の構造が分かりづらい状態です。これを改善し、観点・手順・期待値の3要素を明確に分けて記載できるテンプレートに改善できれば、記載の統一性が向上し、作成者・レビュア・実施者それぞれの作業効率を高められると考えています。
ルールの周知
これまで、テスト項目が各個人の裁量が委ねられ、ルールが特に設けられていない状況でした。今後は観点と手順、期待値に関するルールを明文化し事前に周知することで、作成段階からルールを意識させます。この取り組みによりレビュー時点でのテスト項目の質を向上させることで、レビュー時の指摘箇所を減らし、且つ、妥協を余儀なくされるポイントを抑えられると考えております。
まとめ
テスト項目作成は一見地味ですが重要な作業です。観点・手順・期待値、この3つを意識するだけで、みんなに優しいテスト項目が作れるのではと思います。今回のプロジェクトでは課題が残りましたが、それを次に生かしていくのが開発者として必要なことなので、限られた時間の中でも少しずつ改善していければと感じています。
読んでくださってありがとうございました。皆さんのテスト項目作成の一助になれば幸いです。