勝手に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

Software

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