JaSST'18 Tohokuに行ってきました
こんにちは。私です。
今日はテスターちゃんはおやすみです。
というのも、今週はJaSST'18 tohokuが開催されそれに出席、ついでに実家の青森に戻り（超・山の中）映画三昧をしているからです。
リアルスティールという映画が面白かったですw
さて。
学んだことを整理しようと思ったのですが、まとめついでにブログを書けばいいか、と思ったのでまとめてしまいますw
JaSST'18 tohoku 午前の章（HAYST法紹介部分）
HAYST法によるテスト設計の考え方〜因子水準の抽出方法まで〜
HAYST法って何？
組み合わせテストをより実践的に行うためのテスト技法。
詳しくは本などでw
事例とツールで学ぶHAYST法―ソフトウェアテストの考え方と上達のポイント
- 作者: 秋山浩一
- 出版社/メーカー: 日科技連出版社
- 発売日: 2014/07/01
- メディア: 単行本
- この商品を含むブログを見る
HAYST法を行う理由
IoTの発達により、多様な機器の組み合わせによるサービス構成が増えている。
機器間の相互運用についてのテスト必要性が出てきている！
組み合わせテストって何？
組み合わせテストは、様々な条件を組み合わせて行うテストのこと。
けど全組み合わせのテストは不可能なので、理論的に組み合わせパターンを減らす必要があったりする。
組み合わせ爆発↓
効率化するために直交表やオールペア（作者はペアワイズといってるけど）といった方法がある。
組み合わせテストのステップとしては以下。
- 組み合わせる条件を決定
- 組み合わせ表を作成、テスト実行
- テスト結果を分析する
３のテスト結果を分析する部分は抜けがちなので要注意！
Failが出たら、どんなパターンがおかしいのか分析しよう。
ちなみに組み合わせテストは大きく分けて２種類が挙げられる。
- 有則（仕様書に書いてる組み合わせ。書いてるからわかりやすい）
- 無則（仕様書に書いてない組み合わせ。書いてないから頭を捻る必要あり）
＊＊＊ 2018/05/29追記
有則、無則について
http://www.jasst.jp/archives/jasst07e/pdf/A7.pdf
15Pより。
有則……ソフトウェアのロジックがあるもの。定義された機能が動作する入力セット
無則……ロジックは特になく組み合わせても何の影響がない（と思っている）もの。組み合わせによって悪影響（意図しない影響）がないか、のテストをする。
HAYST法で取り扱うもの、取り扱わないもの
様々あるが、ここでは１つずつピックアップする。
もっともっと！な人は資料公開を待ちましょうね！
取り扱うもの
- アジャイル（ユーザーストーリーごとの組み合わせテストとナラティブフローの組み合わせテストの２段構えで使える）
取り扱わないもの
- 内部構造（プログラマが夜にステキな案を思いついて直してもそれはそれで良し。外部構造のテストはちゃんと通るようにしておいてくれれば問題ない）
ソフトウェア開発/テストを妨げる五悪
開発、テストを妨げる負のループがあったりする。
- 大規模・複雑化
- ↑により変化を予測しなかったりできなかったり
- ↑によりコードを読まなかったり読めなかったり
- ↑によりテスト戦略立てないしテストアーキテクチャつくらなかったり
- ↑により個人、組織のノウハウを蓄積しなかったり活用しなかったり
この五悪についてのHAYST法による対策は以下
- 大規模・複雑化＞6W2Hで全体把握、FV表で小さく分解してからの直交表
- 変化の予測不能＞3Wと直交表でキワをねらう
- コード読めない＞ラルフチャートでモデル化
- テスト戦略・アーキテクチャなし＞D-Caseで戦略づくりと合意
- ノウハウなし＞FL表でノウハウ蓄積
HAYST法のプロセス
プロセスは以下のような感じ。
JaSST Tohokuでは6W2H~ラルフチャートまでがワークショップ対象であった。
- テスト戦略（D-Case）
- テスト要求分析（6W2H、ユーザーストーリー、FV表）
- テスト設計（ラルフチャート、FL表）
- テスト実装（HAYST法ツールなどなど）
- テスト実施
- テスト結果分析
ワークとしてはこんな感じ。
3W(When/Where/Who)を出す
↓
3Wからユーザーストーリーを作る
↓
ユーザーストーリーからFV表を作る
↓
FV表からラルフチャートを作る
テストは最終的には人類平和（！）のためだけど、そんな超大きな目標を達成するために今日やる活動がどう結びつくのか考える必要がある。
そんなわけでプロセスは大きくて抽象的な目的を、今何に集中していくかに変換するために目的を分解、具体化している。
6W2H
6W2Hはテスト対象、要求の理解をするために実施する。
これは以下の３つの視座で分解して樹形図に起こしていこう。
- 開発者（Why, What, Howto)
- ユーザー(When, Where, Who。これら合わせて「3W」)
- お客様のお客様(Whom, How much)
Whomの「お客様のお客様」はわかりにくいけど例としては・・・
お母さん(who）が、マラソンをする子供(Whom)のためにジュースを買う、といった感じ。
6W2Hの使用シーンは以下。
- When / Where / Who：ユーザーのコンテキスト作成に使用
- Whom / How mach : ユーザーストーリーの理由に使用
- What : ユーザーストーリーとFV表に使用
- Howto：FV表、ラルフチャートに使用
3W
3W(When, Where, Who)でお客様のコンテキストを明らかにしよう。
3Wからユーザーストーリーを作ってFV表を作るのが目的。
作り方としては、When/Where/Whoをそれぞれ出して、直交表で機械的に組み合わせを作っていく。
直交表で組み合わせることによって恣意的ではない表が作れる。
直交表ができたら、横１行がユーザーストーリーとなる。
ユーザーストーリーがあると目的機能が見つけやすくなる。
例えばキッズスマホとして・・・
- お昼（when), 学校（where）、お母さん（who）
この組み合わせの場合、例えば以下のようなユーザーストーリーが考えられる
- お母さんの役割として、子どもに連絡を取ることを達成したい。お弁当に箸を入れ忘れたから先生から割り箸をもらえと伝えるためだ。
ちなみに3Wを作る時はデフォルトと「キワ」を用意する。
キワは「極端な例（とはいえ保証範囲内のギリギリ）」を指す。（図は資料公開されたら見て欲しい）
キワでオッケーならゆるくてもオッケーなはずである（大雨が大丈夫なら小雨も大丈夫理論）
FV表 （Function Verification Table)
先ほどから何度か出ているけど、Function Verification Tableの略。
大きいテストは作れないから小さくするのが目的。
目的機能（仕様に書かれていないあるべき姿）やユーザーストーリーについて、仕様書番号、検証内容、テスト技法を紐付けて整理した表だ。
目的機能単位で因子を洗い出して明確化する。
仕様書番号を紐付けることで抜けの確認ができる。
作り方としては、Functionの列には目的機能、そしてVの列には目的機能を満たす条件（因子）を記載する。
Tの列もあって、そこには因子を検証するためのテスト技法や手段を記載していこう。
組み合わせテストやシナリオテスト、などだ。
ラルフチャート
図は以下資料１ページ目。
http://www.juse.or.jp/sqip/workshop/report/attachs/2016/5_hinshitsu_furoku.pdf
FV表の１行を分類する。
- 入力：ユーザーが行う操作
- 出力：目的機能の動作結果
- Read(状態変数)：DBの値や、仕様にある動作環境など
- Write(状態変数)：機能が動作するにあたって内部に書き込むもの
- ノイズ：入出力の関係を妨げる要因。
- アクティブノイズ：悪意を持ったイタズラなど
ラルフチャートは目的機能の理解、因子水準の洗い出しに使う。
整理されるのでテスト条件の抜けを発見しやすくなる。
作り手ではない人はグレーボックス的な考え方から観点出しができるようになる。
FL表（Factor Level Table)
今回のワーク外なり。
FL表は因子水準表のこと。
- 因子＝条件
- 水準＝具体的な値
例えば・・・
因子がブラウザ、水準がIE、Firefox、Chrome、safari、など
あと、FL表には「意図」も書くべし！
理由は、今後保守をするときに「なんでその水準を選んだか」を書いておかないと、水準の削除とかができなくなってしまうため。
例えば・・・
Android 4.2(もっとも古い！）
Android P（最新！）
こんな感じで書いていたら、Android Qみたいなものが出たときには「Android Pはいらないや」と消すことができる。
注意事項としては、水準は厳選する、水準は「正常系テスト」を想定して選ぶ、水準１は普通のケースを記載する（最初のハッピーパスが通らないなら続きの組み合わせテストはする意味なし）、といったところ。
ツールとしては以下がある
- PICT
- PICT Master
ワークショップの章
お題と流れ
ワークショップのお題は「キッズ携帯」。
細かい仕様はやっぱり資料公開されたら見てもらうとして・・・
- 子ども用の最低限の機能がついた携帯
- 防犯ブザー付き。鳴ったら位置情報とSMSを飛ばす。
こんな感じで想像してもらえば良い。
ワークは以下の流れで行われた
- 3WとWhomを出す
- 3Wを直交表に当てはめていく
- 直交表の行をピックアップしてユーザーストーリーを作成する
- ユーザーストーリーからFV表を作る
- FV表を中心においてラルフチャートを作る
3WとWhomを出そう
流れとしてはこんな感じ
- Whenをまずは個人で出す。
- 個人で出したWhenを３つピックアップする。１つはデフォルトの内容。２つは「キワ」の内容。
- 一回Whenがでたらグループで共有。ここでやり方の認識合わせをする。
- 続いて、Where/Who/Whomを個人で出す。Where/WhoはWhenと同じで１つデフォルト、２つがキワ。Whomは好きに出す
- 個人が終わったらグループでWhere/Who/Whomをまとめよう。
単体でテスト観点となるようなのがでるけど、それは別途普通にテストしよう。
3Wを直交表に割り当てよう
直交表を作っておいて、作ったWhen/Where/Whoそれぞれを直交表にペタペタしていく。
付箋でやっているので、付箋はマニュアルコピーしよう！（つまり手で書き写そう！）
こんな感じになった
直交表から１行選んでユーザーストーリーを作ろう
直交表を作ったら、そこから１行を選んでユーザーストーリーを作ろう。
作る時はフォーマットがあるのでそれに合わせると良い。
- 「ユーザー（When/Where/Who)」として
- 「ゴール（What）」を達成したい。それは、
- 「理由（Whom）」ためだ。
以下が私たちのチームの例。
ユーザーストーリーからFV表を作ろう
ユーザーストーリーができたら、そこから検証内容とテスト技法をFV表としてまとめよう。
で、以下が私たちのチームの例
FV表からラルフチャートを作ろう
FV表１つからラルフチャート１枚を作ろう。
情報の整理、因子の洗い出し、水準はできる範囲で出そう。
分類が終わったらもう一周して因子の抜けを見つけて行こう。
発散フェーズであり、足りない因子を見つけるのも一つの目的。
で、私たちのチーム例
このような流れで６時間にも及ぶワークショップが終了。
ほんと、あっという間でしたw
徒然なるままに
仙台に入る者は鉄道むすめに一礼し心身を清めなければ、仙台駅に向かうことを許されないばかりか住民からずんだ餅を投げられたり牛タンを頼んでも3mm薄くなったりすると言われてはいない。
撮影は作者の趣味だ。
仙台の日本酒うまー♪
牛タン牛タン♪
示し合わせてないけど、店にJaSSTメンバーが集結してた。
俺のゴボウは天を衝くゴボウだ！！
レッツゴー青森♪
福岡青森だからプチ日本縦断。
豆知識
青森県民３０代に「好きです！」というと「青森県！」と返ってくるゾ。
たまに返ってこない場合があるけど、そのときはガチで告白してると思われている。
住民票の移動は考えておこう！
※失敗した場合責任は負いかねます。
妹とゲーセンに行ってワニのジオラマをとってきたワニw
今は実家の玄関に飾ってるワニよ。
