mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

勝手にHAYST法勉強会に参加した時のメモ

勝手にHAYST法勉強会

勝手にHAYST法勉強会に参加してきたのでその時のメモを残しておきます。

 

当日発表した資料に、当日教えていただいた話を加えてアップデートしたものをSlideshareで公開しています。 

www.slideshare.net

さて、当日は以下の流れで解説をしていただきました。(構成の都合上、一部除外しています)

それぞれについて紹介していきます。なお、見出しのページ番号はスライドのページ番号と対応していますので、合わせてご覧ください。

6W2H(p.15〜p.22)

HAYST法でテストの分析を行う際に、6W2Hを使用します。ここでは、その書き方について勉強会中の議論内容をまとめています。ポイントは、Whyを直接考えるのではなくWhomやHow muchを考えることで間接的にアプローチしていく点です。詳しくはスライドの該当ページをご覧ください。

FV表はテスト分析結果ではない(p.26〜p.27)

HAYST法ではFV表というマトリクスを成果物の一つとして作成するのですが、私はこれが「テスト分析結果のアウトプット」と思っていました。しかしそうではないそうです。FV表はあくまで、テスト対象を目的機能ごとに分割したものです。 

FV表の左のNo.列に記載する番号(p.29)

FV表の左のNo.列に対応する仕様書の章番号を記載することで、仕様に対する抜け漏れのチェックが行えます。

ノイズとアクティブノイズ(p.32)

ノイズとアクティブノイズの区別をする際は、セーフティ:ノイズ、セキュリティ:アクティブノイズ という対応を考えるとわかりやすいです。ノイズはあくまで自然に発生する脅威であるのに対し、アクティブノイズは人為的に発生する脅威です。ノイズを洗い出す際は、「入力がきちんと出力されないのはどういった場合か?」と考えるとよいです。HAYST法では、「入出力の関係を妨げる要因」をノイズと呼んでいます。

FV表のT(テスト技法)に書く内容(p.36)

FV表のT(テスト技法)の欄は、テストの分担を考える時に使います。なので、極端な話ですが分担を全くしないのならTを書く必要はありません。(ただ、書いておくと後々テストの順番を考えたりする時に役立ちます)

また、Tを書く時はV(検証)を見る必要はなく、Fr(目的機能)のみを見ればよいとのことです。ここは個人的にモヤモヤポイントなので、後日再調査する予定です。 

ラルフチャートとFV表(p.39〜p.40)

HAYST法で用いるラルフチャートですが、大規模システムを対象に作成しようとするとうまくハマらないことがあります。

そもそもラルフチャートは、FV表の1行1行に対して一つずつ作成するものです。なので、それ以上の規模になってしまうとうまく表現しきれなくなってしまいます。FV表の各行がきちんと分割できているかどうかは、ユーザーストーリーのINVESTの法則で確認できます。

 

このほか、HAYST法を学ぶ時にあったほうが良い前提知識やHAYST法のつまずきポイント、他の手法との比較についても議論しました。ここでは詳細を述べることはしませんが、スライドには載っていますので興味ある方は参照してみてください。