チームのテストが遅い、落ちる、直せない。
そんな状態を前にして「テストを増やすべきか、減らすべきか」を決めるのは、テックリードの役割のひとつです。
判断の物差しとしてよく持ち出されるのがテストピラミッドで、言葉だけは知っているという人も多いと思います。
ただ、比率の図を眺めるだけでは、明日のチームで何を変えればいいのかは決まりません。
私自身もテックリードを目指して学んでいる最中なので、一次情報をたどりながら「導入の手順」として組み直してみました。
テストピラミッドは「粒度を混ぜる」ための道具
テスト自動化のピラミッドを言い出したのは Mike Cohn さんで、著書『Succeeding with Agile』で提示された考え方です。
その後、Ham Vocke さんが Martin Fowler さんのサイトに書いた解説記事が、実務向けの定番として読まれています。
The Practical Test Pyramid（Ham Vocke）
この記事は、ピラミッドの本質を2点に絞っています。
ひとつは粒度の違うテストを混ぜて書くこと、もうひとつは高いレベルになるほど本数を減らすこと。
裏を返せば、「どの層を何本」よりも先に、自分たちのテストが今どの粒度に偏っているかを知るほうが大事ということになります。
そして著者は、「unit」という言葉の意味は人によって食い違うとはっきり書いているのです。
3人に聞けば少しずつ違う4つの答えが返ってくる、という書き方です。
上の層を減らす理由は、速さだけではない
なぜ上の層を減らすのか。
その根拠としてよく引かれるのが、Google のテストブログに2015年4月22日付で載った Mike Wacker さんの記事です。
Just Say No to More End-to-End Tests（Google Testing Blog）
ここではユニット70%・結合20%・エンドツーエンド10%という配分が目安として示されました。
ただし記事自身が「正確な比率はチームごとに違う」と断ったうえで、ピラミッドの形だけは保てと言っています。
理由として挙がっているのは、実行が遅いこと、環境要因で不安定に落ちること、そして落ちたときに原因の切り分けに時間がかかること。
現場感覚に近いのは3つ目でしょう。
失敗の原因がすぐ分かるテストほど、開発者は直しにいきます。
逆に、朝いちばんで赤くなっている E2E を誰も見にいかないチームでは、テストは品質の防波堤として働いていません。
導入は「今の形を測る」ところから
新しい比率を宣言するより先に、現状を数える手順を置くほうが動きます。
第一歩は、既存の自動テストを実行時間と対象範囲で棚卸しすること。
1本あたり数秒で終わるものと、数分かかるものを分けるだけでも、いまの形は見えてきます。
第二歩は、直近3か月に落ちたテストを拾い、「本物の不具合で落ちた」ものと「環境都合で落ちた」ものに仕分けること。
後者の比率が高い層は、増やしても信頼されないので投資先から外せます。
第三歩に来て、ようやく比率の話。
目標は「ピラミッドの形に近づける」で十分で、70/20/10 という数字そのものを社内規約にする必要はありません。
第四歩は、新しく書くテストの置き場所をレビューの観点に加えること。
既存のテストを書き直す前に、これから増える分の置き場所をそろえるほうが安く済みます。
落とし穴は「名前争い」と「比率の丸暗記」
導入時につまずきやすいのは、層の呼び名をめぐる議論です。
「これは結合テストか、それともコンポーネントテストか」という論争は、たいてい成果物を生みません。
先ほどの Practical Test Pyramid も、元の名前には欠点があるので独自の名前を付けてよいと書いています。
条件は、チーム内で一貫していることと、意味が明確であることの2つだけ。
もうひとつの落とし穴が、比率を先に決めてしまうこと。
上の層を減らす目的は数合わせではなく、壊れた箇所を素早く特定できる状態を作ることです。
E2E を削った結果、誰も通しの動作を確認しなくなったチームは、形だけピラミッドになって中身が抜けています。
上が細いのに下がスカスカなら、それは三角形ではなく棒でしかありません。
Practical Test Pyramid が警告するアイスクリームコーン型（上が重い逆三角）と同じくらい、痩せた土台にも注意が要ります。
テスト戦略の合意を文書に残すなら、設計レビューの型がそのまま使えるはず。
最後に
テストピラミッドは、比率の正解表ではなく粒度を混ぜて上を軽くするための考え方です。
導入するときは、棚卸し、落ちたテストの仕分け、比率の調整、レビュー観点への追加、という順番で置くと合意が取りやすくなります。
数字より先に、自分たちのテストがどこで時間を溶かしているかを測るところから。
技術的負債の話と同じで、測って見せられるようになった時点で半分は片付いています。
以上です。
コメントを残す