テストって何でしょう？

だいぶ時間が空いてしまったが、2024/03/28に開催された、Findy主催のオンラインカンファレンス「伊藤 由貴さん、ブロッコリーさんに聞く！シフトレフトテストの推進と今後の展望」を視聴したので、その感想をまとめておきたい

興味深いなと感じたのは、伊藤さんが「テストの分解＆可視化をする」として、各テスト工程で何を行うのか？ということを定義していたことだった
この辺りは、黒柴もずっと気になっていたところだった

黒柴が過去に経験した開発は、おおよそ上記のような感じが大半だった
プロジェクト開始時に「単体テスト」、「結合テスト」など、マスタスケジュールが作成されるのだが、定義されたテスト工程の中で、何をするのか？何をどのように確認するのか？ということがまったく定義できていなかった
「単体テスト」と言っても、中堅以上は「ああ、だいたいこんなことやるんだな」と経験をもとに想像していたが、若手は「何を、どのようにテストするんだろう」ということが、まったく理解できていなかった

製造もある程度進んできた段階で、プロジェクトリーダーが「単体テスト」を指示するのだが、その時点で何をやるのか個人任せだった
そのため、経験者と言えども、ある程度きちんとできる人、過去の失敗事例を更新できないまま同じやり方をする人、何をやるのか理解できていない人など、プロジェクト内での統一感はまったくなく、結果として後工程に「単体テストで確認すべき欠陥」が流出しているのは、日常茶飯事だった

「結合テスト」においても、状況は同じような状態だった
いまでこそ、「テストを行うために、テスト対象とテストベースを明確にする」ということが意識できているが、当時は何をテストベースとして結合テストを行うかということが、きちんと定義できていなかった
仮に設計書をテストベースとしても、その設計書がメンテナンスされていなかったり、レビューを実施されていなかったりしていた

2010年代以降にJSTQBの存在を認知して以来、テストそのものというよりも、プロジェクト全体の品質管理をどのように行っていくかを考えたうえで、プロジェクト開始時に「品質管理計画書」なるものを作成して、プロジェクト関係者に周知するのが良いのでは？と思うようになった
一旦、黒柴が叩き台を作成し、社内のPMOグループなどとレビューを重ねて、対象なりとも満足できるものが出来上がったので、この記事に貼付しておく

もはや時代はアジャイル開発で、この計画書が適応できるウォーターフォール型の開発は主流ではないのかもしれないが、請負で委託開発などを実施する際には、役に立っているようだ
もっとも、例によって内容を理解しない営業が勝手に流用して、客先に持ち出しているのには、多少辟易させられているが・・・

話しが長くなったので、ブロッコリーさんの『継続的テストモデルを実現するためにスリーアミーゴスを用いた10Xでのシフトレフトの事例』については、次回感想を述べたい