〜“自分にしかわからない設計”を卒業する〜
「このテスト、〇〇さんがいないとわからない」
「設計書が読みにくくて引き継げない」
「テスト観点が設計者の頭の中にしかない」
こんな“属人化”は、テスト現場あるあるです。
特にプロジェクトの後半や引き継ぎのタイミングで、痛いほど問題になります。
今回は、私が属人化しないテスト設計のために意識していることを実体験ベースでお伝えします。
属人化の大きな原因は、「自分ならわかるから」と情報を省略することです。
操作内容は可能な限り具体的に記述
✗「ユーザ情報を入力」
〇「氏名・メールアドレス・電話番号をそれぞれテキストボックスに入力」
前提条件・準備作業を明記
例：「ユーザAでログイン済みであること」「商品データが登録されていること」
用語や略語をチーム共通の言葉に統一
「明日、自分が倒れても誰かが実行できる」レベルを目指します。
「なんでこのテストが必要なの？」という疑問に答えるのが“テスト観点”です。
属人化している設計書は、手順だけが並んでいて目的や意図が不明確になりがち。
テストケースのグループごとに観点（目的）を明記
例：「ユーザ登録時の入力バリデーションを確認するため」
各ケースに、1行コメントで補足（「バリデーションエラーのメッセージ確認」など）
観点一覧表を最初にまとめておくとレビューも効率化
“なぜこのテストをするのか”が伝われば、設計の意図が他者にも伝わりやすくなります。
テストケースの「タイトル」や「ID」も属人化の温床になりがちです。
番号がバラバラ、順番が飛ぶ
タイトルに主語がなくて意味不明
Excelのシート名が「テスト1」「テスト2」…
ケースIDやシート名の命名規則をプロジェクトで統一
タイトルには「何をどうするか」を含める
〇「商品登録画面で必須項目を未入力にして登録」
過去の類似プロジェクトを参考にするテンプレートを活用
名称の統一だけでも、設計書の“読みやすさ”が格段に上がります。
属人化を防ぐ最強の方法は、**“人に見せる前提で作ること”**です。
テスト観点設計の段階からレビュー対象にする
ケース単位ではなく、設計の流れ・抜け漏れレビューを意識
「説明できるか？」を自分へのチェックにする
設計者だけでなく、周囲が見てフィードバックできる文化が属人化を防ぎます。
設計の質は、ケースの粒度やカバレッジだけでなく、**“引き継げるかどうか”**でも判断すべきです。
他のメンバーが実行しても誤解がないか？
テスト設計書を読めば、仕様もある程度わかるようになっているか？
納品後に「問い合わせ」が来ないか？
自分だけで完結する設計ではなく、「チーム全体が使える設計」を常に意識しています。
属人化しないテスト設計とは、**「自分の考えや意図を言語化し、形にして共有する作業」**です。
最初は手間がかかりますが、
テスト実行の質が安定する
引き継ぎがスムーズになる
プロジェクト全体の品質が上がる
という、大きなメリットがあります。
「自分がいなくても回る設計」を目指して、ぜひ明日からのテスト設計に活かしてみてください。
入会申込
ログイン
