5. 6W2H

adventar.org

アドカレ5日目は「6W2H」。

上の図の最源流にある「テストベース」を木構造で書き写したものが「6W2H」である。書き写す目的はテストベースをだいたい頭に入れて、FV表を作成するためだ。

だから、前回の繰り返しになるが、すでに丸太（＝大きいテスト対象）を薪であるバックログ（＝小さなテストアイテムやテスト条件）に分割（スライス）できていたり、ごく小さな機能拡張なら不要な活動だ。

まずは、6W2Hのフォーマットを示す。

私の腕時計の6W2Hだ。テストベースを読みながら、そのメモを青色の枠である、Why, What, How to, When, Where, Who, Whom, How muchの下に置いていく。

6W2Hは、テストベースを読み返さなくて済むようにテストベースを格納するタイミングで、大事なところをメモ📝するだけ。

メモなんか無くったって覚えてるって人はつくらなくても構わない。でも、他人に説明するときにまとまっていると便利ではある。

そういう点で手書きではなくマインドマップツールを使うのもいいだろう。私はEdrawMind（エドラマインド）を使っているけど、なんでもいいと思う。
なんでもいいと書いたが、それは嘘だ。狭いエリアにみっちり密集して書けるものがお勧めだ。ずっと、freemindが手放せなかったのはそのためだ。
そういう意味で、PowerPointのSmartArtでマインドマップを描くのはお勧めできない。と書いていながら上の腕時計の6W2HはSmartArtじゃないか！

ということで、テストベースを読み返さなくて済むための便利ツールが6W2Hだから、時間をかけてつくるようなものではない。テストベースを読みながらメモして終わりである。長くても1日だ。

念のため書いておくが、NGTのようにツリー構造のリファイン（良い構造に書き換えること）はしない。
極端な話、Whatツリーは、仕様書の目次で構わない。6W2Hでリファインしてもテストベースとのずれが大きくなるだけであり、メリットは感じない。（NGTのように、テスト観点を再利用しようというのならメリットはあると思うが、私は6W2Hを再利用することはしない。）
6W2Hをリファインする時間があれば、仕様書のレビューに時間をかけて仕様書の構造の問題を指摘するほうが良い。

最後に、6W2Hを描くときのコツを述べる。上にも書いた通り、素早く描くこと。色も黒一色がいい。そして、文は書かない。出来るだけ単語にする単語の方が抜け漏れや階層の違いに気がつきやすいからだ。

そして3Wは、3つずつにする。極端な2つと代表的な1つだ。
そうすればL9という直交表にうまく割りついて、様々な利用環境をテストできることになるからだ。