「良いシステム像」を求めて泊まり込みのテストワークショップに参加した話 ~Day2~
前置き
ひぐちと言います。社会人6年目になります。
「WACATE」というテストワークショップの参加レポート三本だて最後の記事です。
今回はワークショップ二日目のレポートになります。
前回までの記事はこちらです。
以下、ワークショップの各セッションについての振り返りです。
セッション⑦ 「品質管理の歴史学」
気付きは以下の通り。「品質の歴史を学ぼう」みたいな深いテーマを扱えるのは
時間をかけてテストや品質を学べるこのイベントならではですね。
- 日本における品質管理
- 「品質は従業員全体で上げていく」という価値観
- 製品自体→工程→企画や提供後と、品質を求める範囲を広げる形で進化
- 欧米における品質管理
- 「品質の定義はQC技術者が決めるのでそれに従う」という価値観
- 各企業が定めた定義が後に規格化
-
1980~90頃に上記それぞれの考え方が輸入され、考え方が逆転
- 日本：規格（ISO9001）信仰（規格さえ守れば品質は保たれる）
- 欧米：「労働者の貢献を引き出す」ことに着目
- 最近のトレンドは、実は日本には元々古くからあった価値観
- 「品質は従業員全体で上げていくもの」であり、誰もが考えるべきこと
均質な国民性で、義務教育の行き届いた日本で、従業員全体での管理が普及し、
人種の坩堝で、教育格差の激しい欧米で、規格による品質統制が普及したのは、
いずれも当然の成り行きだよなと思いました。
現場の人を信頼せず、システムや仕組み、決まりを重んじる欧米と、
全体的な仕組みや決まりを徹底せず、現場の決定や改善を重んじる日本。
AIや自動化などツールを使いつつ両者のいいとこどりができれば良いのですが、
なかなかバランス感覚が難しいですね。以下の書籍の内容にも近かったです。
セッション⑧ 「初めてのリスクベースドテスト」
気付きは以下の通り。
「リスク」という漠然と分かったつもりになっていたトピックについて、
その解像度を上げつつ、扱い方を知ることができました。また、リスクポーカーについて
「カード一つで議論はこんなに楽しいものになるのか」と言う新鮮な感動もありました。
- リスクとは「将来起こるかもしれない悪いこと」であり、以下二種類が存在
- 「プロジェクトリスク」：プロセスやリソースなどに関するリスク
- 「プロダクトリスク」：製品品質に関するリスク（テストで軽減できる）
- 大きなリスクに優先的に対応することで、効率的なテストが可能
- 考えうるリスクを洗い出し（リスク識別）それぞれに対して重みづけ（アセスメント）
- 重みづけは「影響度」と「可能性」の掛け算で定量化
- それぞれの数値はチーム内で議論して決める（リスクポーカー）
- リスクポーカーは合わせるゲームではなく、合ってないことを可視化する手法
以下内容詳細です。
大前提、楽するための手法
「なるべく労力をかけず、リスクを軽減しよう」と言うモチベーションを感じました。
基本面倒なことをしたくない自分にとってはこの考え方が一番
「じゃあやってみようかな」と言う気になります。
「洗い出したリスクは全て潰せ」みたいな（出来もしない）完璧を求める文化で
この手法を導入しようとすると、そもそも毛嫌いされたり、
やったとしてもリスクを隠蔽したりする方向に話が進みそうなので、
「できないものは割り切る」文化とセットで使っていくべきと感じました。
リスクポーカー
本セッションのワークでは、
与えられたお題に対してそれぞれがリスクを見つけ（リスク識別）
それぞれの「ヤバさ」をリスクポーカーで定量化しました（リスクアセスメント）
リスクポーカーの手順は以下の通り
- 洗い出したリスクの影響度、可能性について、個々人で点数をつける（1~4）
- 手元の数字が書かれたカードからつけた点数を一斉に出す
- 一番大きい/小さい値だった人の意見を聞き、議論する
- 全体の合意が出るまで、上記を繰り返す
この手法でチームとしての値を一つずつ決めていき、
「影響度」と「可能性」の値の掛け算をしてリスクの重みをつけていきます。[1]
大事なのは定量化自体ではない
自分の班で、あるリスクについてポーカーをしていた際に
「可能性」を自分だけがやたらと低くつけた項目がありました。
そこでチーム内で議論を行ったのですが、その際に
「その機能にバグが混在する確率は低い」として点数をつけた自分と、
「バグが混在した際に不具合が発生する確率が高い」と点数をつけた他メンバーで
考えていた前提に乖離があることが分かりました。
皆さんの意見を聞いて「なるほど」と納得し、結局高い数値に決まりました。
最初数字を出した瞬間「あ、これ自分何か間違えたかな」と不安になったのですが、
おそらく重要なのは「最初から合っている」ことではなく、
「合っていない事を可視化して認識し、議論する」ことなんだろうなと思いました。
差異を議論することでなんとなくあった暗黙知を再認識できた、と考えると、
むしろ多様な値が出て、チームとしてそれをすり合わせていく方が健全かも。
リスクベースドテスト以外でも、チームでの意思決定の際には是非応用したいです。
セッション⑨ 「直行表に触れてみよう」
直行表という概念の解説と、二因子抽出による網羅性をワークを通して学びました。
気付きは以下の通り。３の気付きのための手を動かすワークがメインだったので、項目は少なめ。
- 直行表を導入することで、組み合わせ爆発を抑えつつ、ある程度の精度が保証できる
- 具体的には1024通りから16通りを抽出してテストする事で、ある程度の精度を保証できる
- （独立であれば）抽出してくる因子がどれであっても結果は変わらない
以下内容詳細です。
用語の理解
直行表の概念を理解するために、以下二つの用語について先に解説します。
- 因子：組み合わせの中で出てくる要素のこと
- 水準：それぞれの要素がとりうるパターンのこと
言葉より例の方がわかりやすいと思うので、以下例です。
（セッションとは少し内容を変えています）
例
ある音楽サブスクシステムでは、以下の組み合わせの条件を指定し、利用を開始します。
| 支払い方法 | ユーザ区分 | 性別 | 好きなジャンル |
|---|---|---|---|
| クレジットカード | ノーマル | 男性 | J-Pop |
| PayPay | スーパー | 女性 | Rock |
| 銀行振込 | プレミアム | 未選択 | クラシック |
この例の場合、上記の表内の
「支払い方法」「ユーザ区分」「性別」「好きなジャンル」が「因子」
「ノーマル」「スーパー」「プレミアム」が「ユーザ区分」因子の「水準」となります。
この組み合わせを全網羅テストをしようと思うと、3×3×3×3=81通りのテストが必要です。
セッションにおける例では要素が5つ。各水準は4つで4×4×4×4×4=1024通りでした。
要素と水準の数が大きくなるほど、テストの数は爆発的に増加していきます。
L9の直行表を作成
次は上記の例をもとに直行表を作成。なのですが、ちゃんと１から作ろうと思うと
mod演算とか群論、体論の話になりそうだったので、今回はありもののL9直行表を採用します。
（左から順にmod0, mod1, mod2を作用させてるのかな、、？）
| 番号 | 因子1 | 因子2 | 因子3 | 因子4 |
|---|---|---|---|---|
| 1 | 水準1 | 水準1 | 水準1 | 水準1 |
| 2 | 水準1 | 水準2 | 水準2 | 水準2 |
| 3 | 水準1 | 水準3 | 水準3 | 水準3 |
| 4 | 水準2 | 水準1 | 水準2 | 水準3 |
| 5 | 水準2 | 水準2 | 水準3 | 水準1 |
| 6 | 水準2 | 水準3 | 水準1 | 水準2 |
| 7 | 水準3 | 水準1 | 水準3 | 水準2 |
| 8 | 水準3 | 水準2 | 水準1 | 水準3 |
| 9 | 水準3 | 水準3 | 水準2 | 水準1 |
参考にした記事は以下です。
同じ行の各因子を見て、該当する水準の組み合わせでテストを実施します。
番号がテスト番号になったりします。今回の例で言うと、以下のような感じです。
- テストケース1：「クレジット」支払いで「ノーマル」ユーザ、「男性」の「J-Pop」好き
- テストケース9：「銀行振込」支払いで「プレミアム」ユーザ、「女性」の「J-Pop」好き
この表内のテストケース9通りを網羅することによって、
全網羅しようと思うと81通りあったテストケースを9通りにまで抑え、
かつある程度の精度を保証することができます。これが、直行表（HAYST法）の威力です。
ソフトウェアテスト技法ドリル[2]によると、この手法によるテストケース数は
因子の数を「n」、水準の数を「k」として「(k-1)×n+1」で表せるそうです。
今回の例で言うと、因子数 n=4、水準数 k=３なので、「(3-1)×4+1=9」
セッションの例で言うと、因子数 n=5、水準数 k=4なので、「(4-1)×5+1=16」
（どうしてこの式が導かれるのかは不明ですが）確かに合っていそうですね。
分野の深みを感じた
セッションの中では「そう言うものか」と無理やり受け入れるだけでしたが、
復習するにあたって一番内容の深さを見た気がするセッションでした。
大学時代に勉強して、もう一生使うことはないと思っていた群論の知識が
まさかこんなところで再び顔を出すとは。
意外なところでシナプスが繋がるから、色々知るのは楽しいです。
セッション⑩ 「WACATEの体験を持ち帰ろう！」
これまでセッションの合間に書き留めてきた気付きのシートをもとに、
それを持ち帰るには？と言う題材でワークを行いました。
気付きは以下の通り。ひたすら時間と作業に追われて大変でした。
- 体験を通して学んだことを、体験を持ち帰ることで広める
- 全く同じルートでの気づきでなくても別に良い
- 大切なのは、伝えわかってもらうためのストーリーライン
以下詳細です。実は本ワークで使った気付きシートを基にこの記事を書いています。
まずは「What」「Who」「Why」
最初のワークは、気付きシートを見ながら以下について考えると言うものでした。
- 特に持ち帰りたい気付きは何か？
- それを伝えたいのは誰か？その人と自分の関係性は？
- なぜそれを伝えたいのか？
自分は、今日のリスクポーカーの体験が結構楽しいものだったので、
チューターをしている後輩にその楽しさを知ってもらいたいなと思いました。
なので以下のような感じになりました。
- → リスクポーカーで認識の差異を可視化し、議論するのは大切だし楽しい
- → チューターを担当している後輩
- → 理解度や誤解を楽しく可視化できそう＋相手のコメントを引き出せそう
次に「How」
次のワークは、上記の成果物を見ながら以下についてチームで考えるものでした。
- どんな体験をしてもらったら、相手に気付いてもらえる？
- その体験をしてもらう上での気掛かりなポイントは？
- その体験をしてもらう際に使えそうなリソースは？
チームの方々と一緒に考えた結果、以下のようになりました。
- → やりとりをする頻度を上げ、そこでポーカーしてみる
- → コミュニケーションを無理強いすることにならない？
- → 立ち振る舞いの改善（なめられるくらいの態度で！笑）
最後にストーリー作成
最後のワークで以下の表を埋め、「体験のパッケージ」を完成させました。
| いつ | どこで | 相手にやってもらうこと | 自分がやること | 狙い | 準備するもの |
|---|---|---|---|---|---|
| 全体の朝会後 | Team会議 | 雑談会に参加してもらう | 会議設定してフランクに話を聞く | 気楽に話せる場の設定 | 会議設定＋ポーカーの説明 |
このストーリーをもとに、班の他のメンバーに相手の役を演じてもらい、
さまざまなフィードバックをいただきました。一番「なるほど」と思ったのは、
「教える、ではなく一緒に考えたい、の姿勢だと会話が弾みやすい」と言うコメント。
これらをもとに年末に第一回を開催してみたのですが、
普段よりは向こうからも話をしてくれたように思います。
この制作過程、実は、、
この内容、実は今回のようなワークショップをデザインする際に考えるフォーマットだそうです。
ワークショップで得た体験をワークショップとして伝えると言う発想は新鮮でした。
心理的なハードルや、普段の忙しさなど、さまざまな要因がある中で、
誰しもがこうしたイベントに参加できるわけではないことを考えると、
「もっとみんなも同じ体験したらいいのに」とぶん投げるよりは
「参加できなくともこうしたら同じような効果を得られるのでは？」と
相手に応じた体験のデザインができる方がフレンドリーだよなと思いました。
セッション11 招待講演
気付きは以下の通り。これまでの学習内容を概観しつつ、
その先の展望もチラ見せする大ボリュームな内容でした。
- テスト設計のプロセスは規格では以下の通りらしい
- テストアイテム（テストする対象）を指定
- 適切なテストモデルを作成（ベン図、テーブル、CFD図、etc...）
- カバレッジアイテム[3]の識別（同値パーティションなど）
- テストケースを導出
- テスト手順を作成
- テスト設計技法を考える上で、「効果」と「効率」と言う二つの観点がある
- 「ディシジョンテーブル」に順序性を加え境界に着目するのが「ドメイン分析」
- 有則の対象は「関連の正しさ」を、無則の対象は「関連の無さ」をテストする
以下詳細です。ついていくのが結構大変なセッションでしたが、
個別に学んだことが繋がったり、頭の片隅で疑問だったことが氷解したりと、
聞いていて楽しい講演でした。
テスト設計技法の概観
講義はこの表を一つずつ上から完成させていく形で進行していきました。
「値 → 順序付きの値（単体 → 複数） → 値の組み合わせ（有則・無則） → 値の順序」と
カバレッジアイテムに情報量を付加していく形で整理していくことで、
技法を選択する際に過不足ない適切な候補をチョイスできそうです。
技法をみる観点 「効果」と「効率」
テスト技法を見る際の一つの観点として「効果」と「効率」があるようです。
以下の図がわかりやすいのですが、要は以下のような見方のようです。
- 効果的なテスト：バグのヒット数が多い
- 効率的なテスト：バグのヒット率が高い
絶対バグを許したくないならば、多少非効率でも効果の高い技法を選択する。
精度よりスピードを優先したいならば効率を優先した技法を選択する。
みたいな使い分けの際に良い指標ですね。
二日間で得てきた武器の使い所がセッションを通じて明確になっていく感じがしました。
この先の展望
概観を見た上で、この先のことについても言及がありました。
「この表が絶対不変の完成形なのではなく、これから皆んなで作り上げていくものである」
と言う最後のメッセージはとても感銘を受けました。
自分はAI関連の仕事をしていることもあって、
- AIがシステムに入ることによって、似た入力でも同じ出力が確約できない → 「テストケースはなるべく少なく」と言うパラダイムが崩れるかも
と言うお話について、一番興味深く聞いていました。
生成的なAIを介在させる以上、完全に固定の出力は期待できないので、
「出力に期待する核の部分（ブレてほしくない部分）」を定義して、
大量にテストケースを入力して、出力全体における核のヒット率を導き出す。
みたいな確率論的な形になるのかも、とか考えていました。
セッション12 クロージング
最後に挨拶と、本が当たる抽選の当選者発表。
そしてポジションペーパーの表彰が行われました。
なんと、自分は「特別講師賞」を受賞させていただきました！
「日々の苦悩や悩みが見てとれた」というのが受賞理由だそうです。
次回参加する時にはもう少しその悩みが改善できているように、
副賞としていただいた書籍を勉強しながら、頑張りたいと思います。
全体まとめ
各種テスト技法、レビュー、ユーザビリティ、などの関連するトピックを
班の方々と手を動かし、議論もしながら学習を進めつつ、
その歴史や概観もインプットできて、本筋だけでも大満足のイベントでした。
ですがそれ以上に、
それぞれ違う場所で品質にこだわる人たちに出会って、
そんな彼らと特別な空間で遠慮や忖度がない議論ができて、
学んだ以上に奥深い世界も垣間見ることができたこと。
これがとてもありがたかったです。
決して無理強いはできないですが、
「品質」や「テスト」について現状に少しでも違和感をお持ちの方は、
思い切って飛び込んでみることをお勧めします。
最初のBPPセッションに再び戻るようですが、
「参加してみる」という「自己表現」がなければその先に「変化」もないと思うので。
-
調べてみると、色んな計算方法があるようです https://anzen-gakuen.com/riskassessment-part1/ ↩︎
-
これを確認すれば全体を網羅できる、と言うリスト。モデルを基に洗い出す ↩︎
Discussion