📂
『テスト項目書』をやめてみる
TL;DR
- 『必要以上に細かすぎるテスト項目書』は、レビュー観点が操作手順やらボタンの名前やら枝葉末節に偏ったり、作成しているだけで『仕事してる感』が出てしまったりするリスクがあると思う。
- 必要性が薄いと感じたのでやめてみたところ、現状あまり困っていない。しばらくやめてみて、問題が起きたら見直す。
前提
-
当記事の『テスト』はシステムを操作して結果を確認する、E2Eテストを指す。
-
当記事の『テスト項目書』は、以下の特徴を持つ。
-
以下の組織規模・形態を想定している。
- 開発・テストの人員が合計で20人以下。
- テスト成果物を納品する必要がない。
- 業界の規制・規格の縛りはない。
経験から感じたこと
- テスト設計[3]段階でテストの内容は決まっているため、テスト項目書作成は 『どう操作するか』『何が起きればOKか』を事細かに書く作業になりがち。
- そもそもなぜ事細かに書くのか？
- テスト実行にチーム外の毎回違う人員がアサインされる現場だったから。
- 逆に、毎回同じ人員がテストを実行するなら事細かな手順＝項目書は不要では？
『テスト項目書』のメリット
実施手順・期待値が明確で、人によるブレが少ない。
- テスト実行を外注しているなど、システムを初めて見る人が実行する場合があるならこのメリットは大きいというか、事細かに書くことが必須になる。
『テスト項目書』のデメリット
書くのに時間がかかる割に、それ自体に大きな価値はない。
- アカウント作成機能のテストを例に挙げる。
- 『管理者アカウントでログインする』『サイドメニューの"設定"を押す』『"アカウント管理"リンクを押す』『"新規登録"を押す』……以下省略。
- 作成したユーザーでのログインや初回パスワードの設定など定番の手順を加えると、これだけでなかなかの手間だ。
書いているだけで「仕事してる感」が出てしまう。
- 少し過激な物言いだが、個人的には強く感じる。文章を丁寧に書く、書式を整える、条件付き書式や関数を使って進捗率を算定する……など。どこまでもこだわれるが、やはりこれ自体に価値はない。
- 『進捗率』も眉唾だ。項目の内容によって実行スピードはバラつく。開発作業より不確実性は低いと思われるが、「1時間で10%進んだから必ず10時間で終わる」とは言い切れないはずだ。
『テスト項目書をやめる』アプローチ
- JSTQBでいうテスト設計＝何をテストするか考えることはやめていない。テスト項目書＝最もローレベルのテストケースからひとつ前の抽象度で止める、というアプローチだ。現状ではテストを実行するのが自分だけなので、思い切ってこのアプローチを採用した。
『テスト項目書をやめる』アプローチのメリット
- 作成が速くなる。
- ユーザー登録機能のテストなら、『管理者アカウントで、ユーザーを新規作成できること』『作成したユーザーで初回パスワードを設定し、ログインできること』の2行で済む。
- 実施時に読む文章量が減る。
- どんな人であれ文章をちゃんと読むには体力を使うし、物量が多いとなおさらだろう。
- これにより、テスト設計・実装・実行がボトルネックとなるリスクを低減できる。
『テスト項目書をやめる』アプローチのデメリット
- 実行する人によって結果のブレが出る。ただこれは、テスト項目書を作成しても起こりうる問題だ。なぜなら項目書自体も読み飛ばしや誤読、あるいはサボりによって結果にブレが出る可能性はあるからだ。
- 少し脱線して話す。「テスト実行のエビデンスを撮らせれば、ブレがないことを証明できる」と考える方もいるだろう。しかしスクリーンショットはその気になれば偽造できるだろうし、正しいものが撮れているか確認する工数もかかるはずだ。すべての項目をダブルチェックするのなら、作業を依頼している意味がない。どこかで性善説に倒す必要がある。
- 読み飛ばしや誤読が頻発するなら、まずは文章自体を見直すべきだろう。
まとめ
- 『テストを実行する人員が限られている(というか自分ひとり)』『量をこなす必要がある』という背景から、テスト項目書の作成をやめるというアプローチをとっている。
- ただし操作パターンが多い場合は例外で、デシジョンテーブルと実施状況を記載した項目書を作成している。『どんな場合でも作る(作らない)』ではなく、状況に応じて使い分けるつもりだ。
Discussion