「Wモデルをどうやって実践するか？をどうやって考えるか」を考えた。

9/13～14に行われたSQiPシンポジウムでもWモデルについてのセッションがありました。JaSSTでもここ数年毎年Wモデルに関するセッションが企画されています。Wモデルは「テストプロセスを設計、実装プロセスと並行して実施する」というように説明されることが多いですが、いざ実践しようとすると、テストプロセスの何をどの程度前倒しすれば良いかが難しいです。
「テスト手順書を前倒しして書けばいいんだろう」という人もいますが、単純にテスト手順書を前倒しすると仕様変更に対して修正すべきドキュメントが増加し収拾がつかなくなります。

この点は過去にEMWESTの記事でも述べられています。
(Wモデルに興味のある方は是非読んでください！）

http://www.manaslink.com/em/emwest/vol-2-2/

私が今までやっている中で効果を実感しているのが「ささやかなWモデル」です。
これは、「全体をWモデル化しよう」というのではなく、得たい情報に狙いを定めて小さなWモデルを実施することです。

例えば、ハードウェア開発を伴う製品開発では、予め機能を確認するための仕組みをハードウェアに実装してもらう必要があります。テストのことを何も考えずに開発していざ、機能テストを行う際にモニタリングをする仕組みがないということでは取り返しがつかない場合があります。
このような後回しにするとリスクが高い情報を得ることにポイントを絞った分析を行うことで少ない労力で大きな効果を得ることができます。

この考え方をもう少し進めて、効果が実感できるWモデルの実践方法を議論できればと思っています。「テスト設計を前倒しすると設計にフィードバックすることができる」という漠然としたところを「テスト設計をすると何が明らかになるか？」「設計に何がフィードバックできるか？」「後で不備がわかったときの被害はどのくらいか？」を細分化して考えて、それぞれがテストプロセスのどの段階で得られる情報なのかを考えてみると良い思っています。
テストプロセスの前の方で得られて、流出して被害が大きいものは、テスト設計を前倒しする効果が高いものに分類されます。逆にテストプロセスの後の方で得られて、テスト工程で見つけても被害が少ないものは、前倒ししなくても良いと考えられます。
テストプロセスの後の方で得られて、被害が大きいものは、設計そのもののやり方を改善することでリスクを減らせないか、あるいはさらに情報の分解して、一部分だけでもテストプロセスの前の方で得ることができないか、を考えれば良いと思います。

腕利きのテストエンジニア、開発者が一緒になって、ワークショップでもして議論できれば良いアウトプットが得られそうな気がしているのでどこかでやってみたいと思います。