こんにちは。IT業界のはしっこでQAをしている、しらみともうします。

2023年6月10日～11日に開催された「WACATE2023 夏 〜オフラインだョ！全員集合！〜」に参加してきました。
最近もの忘れが甚だしく、きっと一か月後には「あれ、あれ、なんだっけ？こないだ…勉強したやつ…」となるので、未来の自分へブログを残します。

WACATEとは

毎年、夏と冬に開催されているテストエンジニアの勉強会です。
コロナ前は、神奈川県の三浦海岸にあるマホロバ・マインズ三浦というホテルで合宿形式で開催されていました。コロナ禍が始まってからはオンラインで、今年は久しぶりのオフラインで開催されました。
詳しくはこちらをどうぞ！
https://wacate.jp/workshops/2023summer/

参加のきっかけ

山﨑さん！

招待講演が、ベリサーブの山﨑さん（@yamasaki696）だったからです。
昔、テストレベル・テストタイプ・テストプロセスがよく理解できなかった時に山﨑さんのスライドに出会い、こんなわかりやすい図をかいてくれた神はだれだ？忘れたくない！と、お名前とともに仕事用ノート（数冊）に写経してました。今回…生で講演聴けて……ほんとよかったです………。

仕事上の理由

私は事業会社のQAというポジションで、ずっとテストを中心に活動してきました。ただ最近はQAとして求められることが変わってきたなと感じています。
「開発が終わったから、QAとしてテストしてほしい」ではなく、
「開発チームで品質担保のためのテストができるよう、QAとして支援してほしい」という風に。

さて、困りました。
私はテストが好きです。なので「テストしてほしい」って頼まれた方がハッピーだし、気が楽です。これまでの経験から、テストに意欲的な開発者さんは少ないというすりこみもあり「開発者さんにテストをしてもらう？どうやって？」と、悩んでいました。

ともあれ仕事として求められるなら、応えられるようになりたいです。
今回のWACATEは、グループでテスト分析やテスト設計に取り組むというもの。グループでのテスト分析からのテスト設計。これは開発者さんと一緒にテストする時の参考になる…！！と思ったのも、参加を決めた理由です。

WACATE 1日目

BPPセッション

WACATEでは参加申込時に、ポジションペーパーをかきます。自己紹介や参加の意気込みみたいな内容です。
参加者はポジションペーパーを読み、もっともよいと思ったものに投票します。投票の結果1位になると、Best Position Paper賞が贈られ、次回WACATEに無料招待＆セッション登壇権利を得ます。

今回は、2022 冬でBPP賞に選ばれた ふじなkさん（@neko_is_rune）が登壇されました！

テストをしない監査QAという役割が導入され、それに任命されたこと。
それまでのテスト中心の業務から、成果物のレビューなど監査的な動きをする業務内容の変化に戸惑ったこと。
監査という言葉の意味を調べ、基準が必要だと分かったが、明確な基準がまだ存在しないこと。
社内の先輩は基準がないことを経験値で補っているが、自分の経験値では難しいこと。
その後自分なりの試行錯誤を重ねつつ、開発チームの中での動き方を模索し、現在はインプロセスQAとして動かれていること。（監査QAは他の方に交代）

私の状況にも似ていて、とても共感しながらお話を聞くことができました。
ふじなkさんの動きを整理すると、

• 情報を集める（監査という用語を調べる）

• 理想と現実の差異を出す（監査の基準がない、自分の経験値不足）

• 課題を設定し行動する（開発チームの困りごとに注目）

という流れかなと思われました。
私は新しい環境や未経験の業務だと、パニックになって動きが止まるくせがあるので、ふじなkさんの動き方はぜひ参考にしたいと思いました。
ふじなkさん、発表ありがとうございました！

セッション1 テスト分析

実行委員の方による、テスト分析のセッションです。

冒頭から印象に残ったことは「テスト分析やテスト設計を、自分の言葉で説明できますか？」という問いかけです。
スライドにも出てきますが「理解してたつもりだけど実際やろうとしたらわからない」というお悩みは多いですよね。
知識として頭に収めることと、それを引き出して使いこなすことの間には乖離があるから、手を動かしてちゃんと身につけようね、というメッセージに聞こえました。

また、このセッションでは

• フィーチャー

• テスト条件

という、定義がややあいまいで、人によって解釈幅がでてしまう言葉の取り扱いについても学びました。言葉を正確に定義するよりも、エッセンスを抽出して実践で使えることの方が大事とのこと。
過去、フィーチャーとテスト条件どちらの沼にもハマった身としては、身につまされるお話でした…！

セッションは、この後のワークを踏まえた具体的なお話へ。
テスト分析では「このシステムの中で、ここは絶対テスト外せないよね！」が大事。特定部分を深く分析しすぎて、タイムアップを迎えるのは避けてほしいというお話がありました。

また、テスト分析でのアンチパターンのお話も。
〇〇画面、△△ボタン、といったテストアイテム列挙は、避けた方がよいとのこと。
現場でテスト分析していても、これは結構ハマるパターンだと思います。
画面名やUI部品名を羅列しちゃうと、その名称に考えが引きずられて、テスト観点が単純になってしまいやすいと感じてます（登録画面＝登録できることみたいに）。ここは気をつけていきたいです。

セッション1のまとめとして、今の私が考える「テスト分析」をメモします。

私のテスト分析は、
テスト対象を知ること（仕様理解）と、
テストの関心ごと（テスト観点）を重ねて、
テストの全体イメージをつかむ行為です。

なので、実務でテスト分析する際も「仕様理解」「テスト観点」の2種類のマインドマップを作ることが多いです。ちなみに「仕様理解」のマインドマップは、仕様理解しやすいのでテストアイテム列挙をしています。
※アンチパターンと言われたテストアイテム列挙ですが、仕様理解（こんな機能がこの配下にあるのね～）しやすいので、個人的によしとしてます。

セッション1 ワーク

ワークのお題は、公共の施設予約システム。
システムの概要や、ユーザー区分などのデータ、抽選や予約などの機能と仕様、画面一覧などがまとまった資料（テストベース）が配布され、まずは個人ワークとして資料を読み込んでテスト分析、その後グループでのテスト分析という流れでした。

個人ワーク…私はちょっと勘違いして「記載もれやあいまいな記述がないか？」というレビューっぽい読み込み方をしてしまいました。
そのため「テストで何をみたいのか？」を、あまり抽出できなかったです。
落ち着こう。

グループワーク。うちの班では、抽選と予約の機能を中心にテスト分析をしました。
個人ワークで抽出したテスト観点（ふせん）をホワイトボードに貼っていったのですが、まず難しいと感じたのは、階層化です。
テスト観点（ふせん）を抽出する前後で考えてることがひとりひとり違うので、そこのずれを少しずつ会話ですり合わせていくのが、難しかったです。

次に感じたのは、テスト観点（ふせん）が「ユーザー区分」とか「日付」とか、名詞で書かれていること。個人ワークの時は、自分の脳内で完結しているので違和感ないのですが、グループワークとして貼りだしてから眺めると、
「ユーザー…で、ユーザーの何をみたかったんだっけ？」と個人ワークまで思考を巻き戻さねばならず、時間がちょっともったいなかったな、と思います。（ここに関しては、途中から @Sammy さんがふせんに補足をずんどこ書き足して下さっててすごく助かりました！ありがとうございます！）

セッション2 テスト設計技法

テスト分析のグループワークが終わったところで、テスト設計技法のセッションに進みます。
グループワークで脳みそがオーバーヒートしているわれら参加者に対し、
実行委員の方が「この技法、使ったことある人？多いね！ではサクッといこう！」「これは手厚めに！」とテンポよく進めてくださり、脳が気持ちよくクールダウンできました。

このセッションで取り上げられていたテスト技法は、全部で5つ。

• 同値分割法

• 境界値分析

• デシジョンテーブルテスト

• 状態遷移テスト

• ユースケーステスト

同値分割では、「テストしたいことによって、考慮すべき有効 / 無効の値が変わってくる」というお話がありました。
例えば、「配達地域」という項目について

①配達地域によって、料金が変わることをテストしたい

• 沖縄 1400円

• 北海道 1000円

• それ以外 650円

②配達地域によって、発送できるかをテストしたい

• 日本

• 日本以外

②の日本という条件は、沖縄 / 北海道 / それ以外（本州など）を含んでいます。が、テストしたいこと（①②の違い）によって、同値として扱う範囲が変わるよというのがよくわかりました。

セッション3 テスト設計技法の選択

1日目最後のセッションは、テスト設計技法の選択です。

テスト設計の目的は、効率的で効果的なテストをすること。
そのためには、テスト設計技法の特徴を理解していることと、テスト分析で何をテストするのか？（テスト観点）の分解と言語化ができてることの両方が必要という内容でした。

説明を聞いた後は、ワークです。
まずは個人ワーク。テスト分析のグループワークで抽出したテスト観点に対して、適用したいテスト設計技法をわりふっていきます。
「テスト設計技法は不要」「適用できない」もOK。その場合は理由も添えます。

個人ワークの後は、グループワーク。
うちの班では、すべてのテスト観点とテスト設計技法の適用を議論するのは時間的に難しいと判断し、テスト観点をしぼることになりました。
テスト観点に個人ワークで考えたテスト設計技法のふせんをはりつけた後、意見（ふさわしいと考えたテスト設計技法）が割れているものから議論しました。

どうしてそのテスト設計技法がいいと思ったのか？をメンバーで共有するうち、お互いの認識やテスト観点の捉え方の違いがわかり「他の人はこういう風に考えるのかぁ」と、とても勉強になりました。

親子関係があるテスト観点で、はじめは子のテスト観点ひとつひとつにテスト設計技法をあてようとしましたが、議論の中で「親のテスト観点の方が、抽象度としてはふさわしいのでは？」という話になったのも面白かったです。
親のテスト観点と、子のテスト観点、どちらを扱った方がよいのか迷ったので「どっちでもテスト設計技法あててやってみよう！そして、できあがったテスト設計を見比べてみよう。」となったのも、個人的にとっても楽しい試みだとワクワクしました。さすがWACATEだ。

WACATE 2日目

モーニングセッション

2日目は、実行委員の方によるレビューのセッションからスタート。

レビューもテストの一種。静的テストと呼ばれるものというお話を聞きました。
日々の相談もレビューのひとつ。ペアプロもSQuBOKだと、レビューのひとつという扱いと聞き、レビューの範囲は広いんだなぁと感じました。

モブプロについて「生産性が悪くなるのでは？」という懸念があるそうです。
モブプロではなく複数人でタスク分担制の場合、①準備　②作業　③確認という工程が必要になります。モブプロでは同じ場で全員が暗黙知や思考の流れまで共有できるので、①と③のコストがかなり節約でき、分担制と比べても生産性が著しく下がることはないそうです。
モブワークやモブプロを考えた外国の企業では、メールの返信もモブでやるとか…。

また、モブワークでのポイントも教えてもらいました。
モブワークではとにかく「発信」が大事！

考えや疑問を言わないままだと「個人の問題」となりますが、
発言することで「チームの問題」になり、メンバーで対応できるとのことです。

このセッションで一番心に残ったのは、どうしてモブプロをやるのか？というくだりで「問題 vs わたしたち」という姿勢になれるから、というお話でした。

私は人の顔色を気にしやすく、テストの進め方やテスト観点のすり合わせ等で「相手が不要というなら、いっか」と議論を手放すことがあります。
（そして、後からこっそり探索的テストで補強したりします。）

その時の私の脳内では、相手は「わたしたち」の中に入っていません。
「わたし vs 相手」になっているのです。
そしてこの状態では、問題より相手を意識してしまっているので、問題とも向き合っていないな…と思い至りました。
脱線してしまいましたが、自分の悪いくせに気づかせてもらえたという意味で、このセッションはとても心に残りました。

セッション4-5 テスト設計技法ワーク

前日のグループワークの続きで、グループワークで選択したテスト設計技法✕テスト観点で、テスト設計を行うワークです。

今回は、グループ内で2-3人に分かれテスト設計してくださいと指示がありました。私はそうすけ（@formulaPanda1）さんとペアを組みました。
お題は以下。

お題：施設の空き状況 ✕ デシジョンテーブル

施設の予約機能のうち、「施設の空き状況」に応じて予約できるかをデシジョンテーブルで設計するというもの。

まず初めに困ったのは「究極に簡略化するなら、因子が施設の空き状況だけで、水準が空いてる/空いてないの二つになっちゃわない？」でした。

そんな、テストが、あるもんか。セルフつっこみしつつ、そうすけさんと考えました。

まず、施設の予約できる時間帯は、午前・午後・夜と分かれています。午前だけの予約や、空いていれば午後・夜など連続した時間帯でも予約ができます。逆に、午前・夜などの飛び石のような予約もできます。

なので、因子：施設の空き状況のままで、水準を：午前・午後・夜とわけ、空き状況の細分化とパターンが表現できるようにしてみました。

ただ、これだけだと「予約できるか」をテストするには足りないと思いました。「予約できるか」をテストするためには、ユーザーがどういう予約をしたいかの情報が必要そうに思いました。こちらは期待値に以下のように組み込むことにしました。

• 午前のみ予約

• 午後のみ予約

• 夜のみ予約

• 午前＋午後

• 午後＋夜

• 午前＋夜

• 終日

デシジョンテーブルの因子と水準と期待値が決まったところで、〇✕（YN）を入れていくのですが、私この作業がとても苦手で…
まごついていたら「テスト設計はあまりやったことがない。」と言ってたそうすけさんが、サクサク埋めてくれました。ソフトウェアテスト技法練習帳で学ばれたそうで、このあたりは迷わずできるそう。ありがとうございます！

ペアでのテスト設計後、グループ内での共有タイム。
うちのグループは、親子関係にあるテスト観点で、親のテスト観点と子のテスト観点に分かれてテスト設計を行っていました。
（私がペアで行っていたのは、子のテスト観点の一部。）

親のテスト観点をテスト設計したペアは、デシジョンテーブルでテスト設計したものの、少ししっくりこなかったそうです。
それに対して実行委員の方から、テストしたいこと（テスト観点）に対して、影響を及ぼす因子を組み合わせること、とアドバイスがありました。
実際のテスト設計を見ながら受けるアドバイスなので、とても腹落ち感がありました。

※うちの班のテスト設計成果物は、当日許可もらい忘れ＆全員のご連絡先を知らず許可がとれていないため掲載しておりません。

招待講演

山﨑さんによる招待講演「テスト開発について改めて考えてみよう！」です。
テスト分析→テスト設計→テスト実装までを「テスト開発」とし、さまざまな角度からテストの考え方を伝えて頂きました。
とにかく、テストに対する熱量がすごく、それを伝える声にも力があるなぁと圧倒されながら、ノートを取りました。

山﨑さんのスライドは大事なこといっぱい書いてあるので、ぜひ↑読んでみてください。私は脳と心がいっぱいすぎて、まだ消化不良です…
講演中に心に残った山﨑さん発言集だけおいておきます………

「絶対的な正しいテストはない。」
「どんなテストをするかを利害関係者とすりあわせて合意をえることが重要であり、そのためにはテストを説明（理解）する必要がある。」
「仕様書以外も暗黙的なテストベース。」
「いかに仕様書を汚せるか。」
「テストにおける全体感を持つ。」
「いかに自分たちのテストを本質に近づけるか？を考え抜く。」

うまく言語化できないのですが、2日間のワークの経験があったからこそ体感として染み入るお話でした。
テストもっとうまくなりたい！！と強く感じました。

参加した感想

久しぶりのオフライン開催のWACATEでしたが、参加して本当によかったです！セッションもワークも招待講演も、学びがてんこもりの2日間でした。

いろんな参加者さんとの出会いもありました。
何人かの方とは、WACATEのあともSNSでやりとりさせて頂き、小さいですが自分にとってのネクストアクションにもつながっています。
このブログもそのひとつです。

実行委員のみなさん、招待講演の山﨑さん、参加者のみなさん2日間どうもありがとうございました！

最後に

今回のWACATEで、一番びっくりして嬉しかったことがあります。
ポジションペーパーのBFP賞を頂きました。BFP賞とは招待講演の方が選出する賞です。招待講演、そう、山﨑さんです…！

仕事（転職したばかり）や家庭のバタバタで、なんとか参加できたWACATE。
思いがけず山﨑さんの名前いりの賞状もらえて、とってもとっても元気を頂きました！山﨑さんありがとうございました！！