経緯や理由はともかく、現物（コード、ビルド成果物）しか存在しないプロダクトが商品ラインナップに並んでおり、いろいろありすぎて、とにかくテストをしよう、という状況になること、悲しいがある
ないものはないので、あるものでどう戦うかを考えるしかない
本題に入る前の愚痴と前提
「とにかくテストをしよう」という心は尊いが、心のままに行動を起こしては（本来は）いけない
（本当は）テストの前に、プロダクトが目指すべき品質目標の定義が必要だ
品質保証はテストしてはい終わり、ではない
「テスト」が品質保証活動にとってどういう役割なのか定義が（実際は）必要だ
この文書はそういった大前提を無視して、テストの役割もふわふわさせたまま「とりあえずテスト」に取り掛かるための準備について述べる
テスト計画を立てるための材料を探す
テスト計画には最低限以下の項目が欲しい
- 品質目標
- テスト実施計画（日程）
- 実施するテストの内容
これらの項目は独立して策定できるものではない
品質目標を立てる前に、結局いつまでにどんなテストができそうなのかの目安はほしいし、品質目標がないとどんなテストをどこまでやればいいのかわからない。どんなテストをやればいいのかわからない状態で日程は決まらない。
これらに手を付ける前に、まずありったけの情報を収集・確認する
- 仕様書がなければ、当時の議事録やメモが残っていないか調べる
- gitでコードを管理していたら、遡れる限りのコミットログやレビューコメントを確認する
- 当時の関係者が残っていたらインタビューする
- ソースコードを読む
こんなことする余裕はないから、結局今まで通り、積み上げたパズルを更に積み重ねるような修正と、半ば神頼みのコードレビューと動作確認に落ち着いてしまうのかもしれない
ここで踏ん張れるかどうかが分岐点になる
集めた情報の読み込みや整理・分類についてはAIが広がっている現代であれば、実はどうとでもできる
しかし、どんな優秀なAIでもローカルな組織の中にさまざまな形態で潜んでいる情報をいい感じに収集することはできない
ここでは頭の良さやスキルセットよりも、図太さと上っ面の愛想の良さが効く
結局、一番面倒で泥臭くて労力が必要な部分は人力で解決するしかない
非常に大変だが、ここまで経験済という諸兄は少なくないはずだ
ソースコードこそが最も信頼のおける仕様なのだ
ソースコードが正しいとは限らない
前項をひっくり返すが、ソースコードが正しいとは限らない
ソースコードの挙動とユーザーに説明していた仕様が異なっている、ソースコードのアウトプットが業界で定められている規格と異なっている、など、いわゆる不具合が大量に埋め込まれている場合、ソースコードへの信頼性は揺らぐ（１→０）
単純な不具合なら良いが、リリース当時は正しいが、経過により状況が変わったが適切にアップデートされず、結果的に不具合になってしまったり、過去に特別に行った対応がなぜか標準になってしまい、仕様の整合性が取れなくなってしまったり、不具合判定すら単純に下せなくなる場合もある
ソースコードを正とできない
情報も断片的にしか残っていない
正解が定義できないのにテスト設計などできるわけがない
権威に頼る
- 砂浜から砂粒をより分ける覚悟でいちから仕様を起こす
- プロダクトに関連する、外部のガイドライン・規格・規約・仕様・要件に頼る
この文書では、後者のアプローチを勧める
例えば、UIならばUI設計ガイドラインを参考にする
- Apple HIG https://developer.apple.com/design/human-interface-guidelines/
- Material Design https://m3.material.io/
- Fluent UI https://developer.microsoft.com/en-us/fluentui#/
- Carbon https://carbondesignsystem.com/
現在のソースコードからテスト対象のページを洗い出しつつ、ガイドラインを参考に、テスト観点のフレームワークを作成する（テンプレート的なものでも良い）
基本はガイドラインの内容を正として、プロダクトのユースケースや要求や実装から読み取れる元々の「やりたかったこと」とすり合わせを行う
そこまでやれば、品質目標の落としどころが見えてくる
やってみてそぐわなければ、直せばいい
そう、直せる状態になるのだ（０→１）
組織内でプロダクトのあるべき姿を見失っている場合、その組織内で新たに正解を定義しようとすることは困難だ
しかし、仮置きでも良いので「正解」を置くことで、その「正解」を評価することは難しくない
「＊＊がこう言ってるんだから、でたらめではないだろう」
ある程度信頼できる組織が定めているという「権威」は、混沌する状況において救いになる
さいごに
ここで記載した内容は、途方にくれてしまった場合のひとつの道しるべになるかもしれない
こういうことに頭を抱えて唸っていると、テストエンジニアはテストすることだけが仕事ではないのだな、と痛感する