勝手にHayst法勉強会リリカルver

勝手にHAYST法勉強会
リリカルver.
開催報告
藤沢耕助（リリカル：@mhlyc）

自己紹介
2017/8/17勝手にHAYST法勉強会リリカルver. 2
発表者
• 藤沢耕助
所属
• 某SIer 品質保証部門
業務
• 設計書レビュー
• システムテスト
発表の理由
• テスト技法に興味がある
• 仕事に活かせるかも？
品質保証部
藤沢耕助

本発表の流れ
1. 私の関心事（私がテスト分析・設計手法を通して
やりたいこと）
2. 私の思うHAYST法の良いところ（３つ）
3. 私がHAYST法でよくわかっていないところ（２つ）
4. まとめ（私の思うHAYST法のポイント）
5. 付録

私の関心事
立場：
SIerのQA。システムテスト工程のテスト設計〜実行
を担当

私の関心事
立場：
を担当
バグを見逃したくない

立場：
を担当
私の関心事
バグを見逃したとしても、
許せる範囲だといい

立場：
を担当
私の関心事
バグを見逃したとしても、
許せる範囲だといい
リスクや影響に基づく、
テストの説明ができる
ようにしたい

私の関心事
私がテスト分析設計手法を通してやりたいこと
自分が設計したテストに、納得のいくような
説明をつけたい。
「なぜこのテストをするのか／しないのか？」
という質問に明確に回答できるようになりたい。

本発表の流れ
5. 付録

HAYST法とは
• 因子どうしは直交している前提
• 直交している因子どうしを組み合わせた時に「本当に
問題が起こらないこと」を確認するための手法
参考：ソフトウェアテスト技法ドリル

HAYST法の流れ（違っていたら教えてください）
# 内容
1 6W2Hでテストの分析
2 FV表（テスト分析結果）の作成
・目的機能（ユーザストーリー）
・検証内容
・テスト技法
3 ラルフチャートを描画してテストの設計
4 FL表を作成して、テストとして取り上げる因子と水準
を整理
5 直交表への割付

# 内容
・検証内容
・テスト技法
を整理
①６W２H

①６W２H
思ったより色々出てくる
“Where”や“Whom”
など、普通に考えたら
見落としてしまう

①６W２H
この書き方は間違っているらしい

解説１：６W２H
 間違い①
 Whyの直下には要素はつかない
（あえて描けなくしているとのこと）
 Why
 Whom（ユーザのお客様）
 …
 How much（量、金額など）
 …

 間違い②
 6W2Hは、全てが同列ではない
 「ユーザー」「開発者」「お客様の
お客様」の３つの視座から８つの視
野（6W2H）でテストの分析をする

①６W２H

 なぜ、Whyの下に直接要素をぶらさげない
のか？
 一般に、仕様は要求を元に決定され、Why
（要求）は理由に基づく
 How toはその実現方法（設計）
 設計の結果、作成された成果物が納品される
 参考文献：[入門+実践]要求を仕様化する
技術・表現する技術 –仕様が書けています
か?-

 製品のリリースには、根本的な「目的」がある
 HAYST法では要求ではなく「根本」を狙いたい

ここを狙いたい！
理由要求仕様決定
設計
リリース目的

 「理由」というのは「誰かが昔『欲しい』と言っ
たから」
 これを満たしたところで、その人は喜ぶかもしれ
ないが、みんなが喜んでくれるかはわからない
 理由ができた頃から時間も経っている・・・その
時と今で状況が変わっているかもしれない

 3年後に「これ買っててよかったな〜」と思って
もらえるようにするには？
 苦情やクレーム（Why）に対応するのでは、後追
いになってしまう
 そのため、Whyを直接考えるのではなくWhomや
How muchを考える。そのほうが根本により近づ
ける

# 内容
・検証内容
・テスト技法
を整理
②目的機能の抽出

②目的機能（ユーザストーリー）
目的機能を考えないと、
バグを見逃すことがある
「そもそも必要なのはこの
機能ではないのでは？」
といった疑問にも気づける

# 内容
・検証内容
・テスト技法
を整理
ここが間違い

解説２：FV表はテスト分析結果ではない
 FV表はテスト分析結果ではない。テスト対象を
分割したもの
 要素が大きすぎると考えづらくなるため、分
割して小さくして扱いやすくする
 分けた後に使いやすくするため、目的機能ご
とに分割する

解説２：FV表はテスト分析結果ではない
 FV表はテスト分析結果ではない。テスト対象を
分割したもの
 目的機能ごとに分割することで、非機能系の確認が
しやすくなる
 例：プロジェクターの投影機能
 台形補正
 色調整
 明るさ
 個別の確認を行うだけではダメ。組み合わせた結果
目的を達成していることを確認しなければならない

②目的機能（ユーザストーリー）
ここの番号も間違い
（ただの順番ではない）

解説３：FV表の左のNo.列に記載する番号
 FV表の左のNo.列に記載する番号は、ただの順番
ではない
 対応する仕様書の章番号を記載することで、仕様に
対する抜け漏れのチェックが行える
 ある章が抜けていた場合：目的を考えられていない
or 不要な機能の可能性がある

# 内容
・検証内容
・テスト技法
を整理
③ラルフチャート

③ラルフチャート
「ノイズ」と「アクティブ
ノイズ」に分けて発想すること
で、多くの因子を見つけ出せる

解説４：ノイズとアクティブノイズ
 ノイズ：セーフティ。自然の脅威。
 アクティブノイズ：セキュリティ。人為的な脅威。
 入出力の関係を妨げる要因のことをノイズと呼ぶ。

本発表の流れ
5. 付録

# 内容
・検証内容
・テスト技法
を整理
①テスト技法

①テスト技法
「テスト技法」の列には
どんなことを書くのが
いい？
ここはテストにおける
Howの部分のはず。How
（どうテストするか）が
わかるようなことを書く
べき？

解説５：FV表のT（テスト技法）に書く内容
 FV表のT（テスト技法）にはどのようなことを書いたら
良いのか？
 FV表のT（テスト技法）は、分担を考えるために使う。
 UTチーム、統合テストチーム、システムテストチーム・・・
 分担しない場合は、Tを書く必要はないのか？
 書かなくていい。ただ、書いておくとテストの順番を決めると
きに役立つ。
 Tを書くときは、V（検証）は見ない。Fr（目的機能）だけ
を見る。（個人的にモヤモヤポイント。後日また確認する
予定）

# 内容
・検証内容
・テスト技法
を整理
②ラルフチャート

②ラルフチャート
ラルフチャートにうまく
ハマらないケースがある
Ex) 大規模業務システム
のテスト
よりテスト対象を
よく表したモデルを使用
する方が、良い分析を
行えることもあるのでは。

解説６：ラルフチャートとFV表
 FV表の１行がラルフチャート一つに対応する
 沸騰ポットで言えば、ミルクを沸かす機能、お湯
を沸かす機能それぞれに対して別々のラルフ
チャートを作成する
 FV表の１行が正しく分割できているかは、
INVESTの原則で確認する（次スライドで解説）
 大規模システム開発においては、ある程度分割し
た単位でないとラルフチャートを作成するのは難
しい

解説６：ラルフチャートとFV表
 I(Independent) 独立している
 N(Negotiable) 交渉可能である（別のものと交換できる）
 V(Valuable) 価値がある（目的、意味を持つものである）
 E(Estimable) 見積もり可能である
 S(Small) 適切な大きさであること、大きすぎないこと
 T(Testable) テストできること
要求がとらえられているか？
仕様化・具体化が行えているか？
(Specify)

本発表の流れ
5. 付録

私の思うHAYST法のポイント
• とにかく「どうやって因子を漏れなく出すか」だと思う。
やり方にこだわる必要はない
• 因子の漏れ＝テストの漏れ
• ６W２Hやラルフチャートといった、因子を抽出する
ための仕掛けをどううまく使うかが鍵

本発表の流れ
5. 付録（VSTeP、ゆもつよメソッドとの比較）

VSTeP、ゆもつよメソッドとの比較（独断と偏見）
HAYST法ゆもつよメソッド VSTeP
得意な
ドメイン
組み込みエンプラ？全般？
テスト
レベル
システムテスト
？
システムテストシステムテスト
表現の
自由度
低い低い高い
あると
良い知識
基本的なテスト
技法
クラス・
インスタンス
クラス・
インスタンス
つまずき
ポイント
因子・水準の
出し方
テストカテゴリの
出し方
ツリーの要素の
抽象化・具象化

VSTeP、ゆもつよメソッドとの比較（独断と偏見）
HAYST法ゆもつよメソッド VSTeP
得意な
ドメイン
全般（一部例外あ
り）
全般全般
テスト
レベル
結合〜システムテス
ト
システムテストシステムテスト
フォーマット
の提供
ありあり NGT準拠だが、実質
ほとんどなし？
あると
良い知識
基本的なテスト技法
オブジェクト指向設
計技術
目的工学
テストケースのリバース
エンジニアリングの経験
構造化分析・設計技術
つまずき
ポイント
目的機能の抽出（特
に、内部機能や安全
機構に関する機能）
テストカテゴリの出し方ツリーの要素の抽象
化・具象化

参考
• ソフトウェアテスト技法ドリルテスト設計の考え方と
実際秋山浩一著日科技連出版社

勝手にHayst法勉強会リリカルver

Recommended

Recommended

More Related Content

More from Kosuke Fujisawa

More from Kosuke Fujisawa (18)