現在私はQAマネージャーとして、テスト設計経験豊富なテストエンジニア（QA）を集めて良いテスト設計を行う体制ではなく、教育や仕組みによって開発者自身が良いテスト設計を行える体制を作ろうとしています。
今回は、私がそのような体制を作る上で重要だと思う「作業工程の言語化」のメリットを2つ紹介したいと思います。[1]
メリット1：ベテランの作業を模倣することができる
作業工程の説明が抽象的な場合は、具体的な作業は各人の解釈に委ねられます。しかし、作業工程が細かく分割されて具体的に言語化されていれば、その具体的な作業を模倣することができます。
上記のテスト設計チュートリアル ちびこん編資料のスライドを例に説明します。従来のテスト開発プロセスは大きくテスト設計をやるという工程しかなく、具体的に何を行うかわかりません。私が初めてテスト設計をしたときは、テスト仕様書の雛形を埋める作業を見よう見まねで感覚的に行っていました。
JSTQBやテスト設計チュートリアルのプロセスは作業工程が分割されているため、従来のテスト開発プロセスよりもテスト仕様書を作成するために何を行えば良いかがわかります。
ただ、この段階でもまだ作業工程が抽象的なので、私は教育を行うという視点では更に作業工程を具体化した方が良いと考えました。
作業工程の具体化の過程は以下のスライドをご参照ください。
作業工程を詳細化する際の注意点は、ある人のやり方が他の人には合わないことがある点です。
例えば、私は「画面＞画面内の部品＞テスト観点＞テスト条件」のようなツリー構造で考えるのが好きですが、過去の経験をベースにテスト条件から考えて連想ゲームのようにテストする内容を考える方が得意な人もいます。
なので、人によって作業の仕方が変わるような工程については、あえて詳細化しないという判断もあり得ます。
メリット2：振り返り時に課題の根本原因がわかりやすくなる
作業工程が抽象的な場合、作業に何か問題が発生した場合に根本原因がどこにあるかがわかりづらくなります。
例として、テストが漏れた場合の振り返りを行ってみたいと思います。
従来のテスト開発プロセスの場合は「テスト設計」という抽象的な作業工程しかないため、作業工程からテスト漏れの原因を振り返ろうとしても「テスト設計をしたけどテストが漏れた」ということだけしかわかりません。そのため、テスト漏れを解決策は、テスト漏れした観点のチェックリストを作ろう、漏れたテストの自動テストを作ろう、といったものになりがちです。大抵の場合、このような解決策だと別の機能で同じようなテスト漏れが発生します。
作業工程が具体化されている場合、以下の例のようにテストが漏れた原因がより具体化されます。
- テスト設計に必要な情報収集が不足していた
- テスト設計に必要な情報収集は十分だったが、この機能は不具合発生のリスクが低いと思ってテスト不要と判断した
- テスト設計に必要な情報収集は十分だったが、テストする条件の洗い出しが不十分だった
そうすると、テスト漏れの解決策が以下のような作業のやり方にフォーカスした具体的なアクションになりやすいです。
- 情報収集プロセスの見直し
- リスク分析方法の見直し
- テスト条件洗い出し方法の見直し
なお、作業工程が決まっていないタスクの振り返りについては、問題の原因となる作業が行われるまでの過程を時系列で言語化して振り返ってみましょう。
おわりに
いかがでしたでしょうか。
作業工程の言語化は実はやってみると結構難しいのですが、うまくできるようになれば教育や振り返りの効果が顕著に変わります。
皆さんもぜひ試してみてください。
参考文献
-
実は執筆中にたまたま5/16のJaSST nanoで似た内容の発表（テストプロセスを用いて、テストケース作成の思考を整理しよう）があったので記事を公開するか悩みましたが、既に記事を執筆していたのと観点が若干異なると考えたので公開することにしました。 ↩︎
Discussion