テスト設計書もなく、仕様書もSlackに散らばっていて、「テストよろしく」とだけ言われる現場。そこで最初にやるべきことを整理してみた。
最初に正直に言うと、手順書を作ろうとしてはいけない。資料を整えようとしてもいけない。まずリリース予定のものを触る。それだけでいい。
スタートアップのQAは「整った環境でテストを回す」仕事じゃない。「何が壊れたら困るかを把握する」仕事だ。そのためにいちばん早いのは、自分が使ってみることだ。
最初の1週間でやること
まず、ログインからコアの操作までを一通り触る。仕様書がなくても動きを見ればわかることは多い。気になった挙動はスクショを撮ってメモするだけでいい。起票は後回しでいい。
次に、開発者に「一番怖いのどこですか」と聞く。これが効く。バグを出したくない箇所、触ると壊れがちな部分、リリースのたびに心配しているところ。そこが最初に手を入れるべき場所だ。
そしてSlackを読む。直近1〜2週間の開発チャンネルを流し読みするだけで、何を作ったか・何が問題だったかがだいたい見える。それが仕様書の代わりになる。
ドキュメントより先に動くものを作る
テスト設計書を最初から整備しようとすると、書くことが目的になる。ようやく書き終えても、仕様はどんどん変わっていく。スタートアップに必要なのは、完璧なドキュメントより先に「リリースを止めないこと」と「大事なところが壊れていないことの確認」だ。
シンプルなチェックリストで十分。「ログインできる」「注文が通る」「メールが届く」。このくらいのレベルから始めて、やりながら育てていく。完璧な設計書より、リリース毎に動作を確認するシンプルなチェックシートのほうがずっと価値がある。テスト観点の出し方に迷ったら、テストパターン集を出発点にするとよい。26カテゴリ70パターン以上をまとめている。
テスト中に「これってバグ？仕様？」と判断に迷う場面が多いなら、バグ判定AIツールも使える。スクショを貼るだけでAIが方向性を示してくれるので、確認待ちで手が止まらなくなる。
整っていない環境でこそ、何を確認すべきかを自分で判断する力がつく。それがQAとしていちばん大事なスキルだと、私は思っている。