こんにちは！QAエンジニアのはなみです。 今回は参加したワークショップ「WACATE」で紹介された本を通して、ワークショップで感じていたあれこれを咀嚼しなおしてみる記事になります。
WACATEとは
Workshop for Accelerating CApable Testing Engineers：内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ
です。夏と冬の年2回、1泊2日の泊りがけで開催されています。
詳しくは↓
wacate.jp
私はWACATE2024夏、2024冬、2025夏と参加しました。
楽しくて大好きなのですが、次に参加する場合は常連カードを下げることになりそうですこし怯えています。
(QAエンジニアとしてはまだまだ学びが多い日々のため…)
QAだけでなく開発者の方も参加されていたりするので、テストに興味関心がある色々な方におすすめです！
この話題に決めた経緯と理由
そもそもこの開発者ブログに書く内容として、WACATE2025夏に参加するしWACATEの話をしようかなとはふんわりと考えていました。
話題として何を取り上げようか迷いながら、とりあえずWACATEで紹介されていてかつ気になっていた本を読んでみようというところから始まりました。
該当の本は下記になります。
WACATEレポをするか本の紹介をするかどうしようか迷った結果、どうせならどっちも絡めて何か書こうと思って表題に行き着いています。
なぜ「具体と抽象」なのか
2025夏の招待公演者である吉澤さんが選ぶポジぺ賞の副賞本として「具体と抽象」が紹介されているのを見て、2024夏の水野さんの招待公演を思い出しました。
この本については2024夏で水野さんが紹介されていた時からじわじわずっと気になっており、今回また出会ってしまったのでこれはやっぱり読んでおこうと思い、1年の時を経てこのタイミングでようやく手に取りました。
ちなみに本の内容については、ここではほぼ書きません。
テスト関係なしに個人的に一番うわ！と思ったところをちょっとだけ紹介しておきます。
数学者と哲学者として有名な人物が被っている理由について書かれている部分です。
数学と哲学では大学の学部などで考えると理系と文系で全く違うところにあるイメージなのに、同じ人物の名前が出てくることが不思議だなと以前から密かに思っていました。なので「第6章 往復運動」の下記の記述に大変衝撃を受けました。
徹底的に抽象度を高めた学問の代表が数学と哲学です。
とても興味深く読みました。面白かったです。
具体↔︎抽象に当てはめて考えてみる
グループワークの気づき
2025夏の2日目モーニングセッションで"「テストで使う具体的な値」を起点に「テストプロセス」を考えてみよう"というワークがありました。テストで使う具体的な入力値などから遡っていつもの考え方をプロセスに表し、工程を自分の考えで括ってみようというものでした。
グループ内で共有した時に、プロセスを記入するために用意されていた枠が全部埋まっている人は分析・設計と工程を分けていて、枠が全部埋まっていない人はすべてをテスト作成で括っているという傾向が出ているという話が出ました。
私は最近転職して今ユニファにいるのですが、転職にあたってテスト関連の知識を勉強しなおしたり、転職してからQAエンジニアとして働く中で項目を作成する前の分析の時間を積極的に取るようになっていたので、「テスト分析」という概念が自分の中に生まれている自覚がありました。「テスト分析」という抽象概念を知ったことで、あれ？自分が今まで「テスト作成」の過程でやっていたこの作業はテスト分析なのでは？と考えることができ、そうすると「じゃあテスト分析ってみんなどうやってるんだろう」とか「効率的なやり方・進め方ってあるのかな」というところに進んでいけるんだと実感した感覚がありました。抽象概念を知ると具体も見えるようになるというのは、こういうことなのかなと思いました。
余談なのですが、実は勉強し始めのころは「テストプロセス」って作成と実行以外にそんなに工程あるの？！「テスト作成」で十分わかりやすくない？！という思いがよぎったこともありました。が、これはまさしく表層の分かりやすさというか具体的な分かりやすさ(テストを作成するという作業の認知のしやすさ)であり、抽象度が高いことによる分かりやすさ(理解のしやすさ・考えの広げやすさ？)ではないということなんだなと改めて考えたりしました。
グループワークの反省
夏のWACATEは、2日間を通して1つのテーマについてがっつり取り組む構成になっています。2024夏と2025夏ではそれぞれ置かれたテーマとシチュエーションに沿ってグループでテスト活動に取り組んでいきました。
このワークにて個人的に課題に感じている部分が、テスト設計技法を使う場面で「この設計技法を使えるところってどこ？」という視点で考え始めてしまうところです。デジションテーブルを使えるそれっぽい機能ってないかな？になってしまうのです。
これは目的と手段がごっちゃになっているということもありますが、「デジションテーブル(具体)→入力値と条件が複雑そうな機能(具体)」という、具体の部分しか見れていない状態なのではないかとも思いました。
まず「こういった入力値があるからこの設計技法を使う」と考えるべきだし、もっと丁寧に見ていくと「入力値(具体)→モデリング(抽象化、どんな構造なのか理解する)→設計技法の選定(具体化、どんな手法が効果的か判断する)→効果的な設計技法(具体)」となるべきなのかなと考えました。
とはいえグループワークだと時間も限られるし、抽象/具体レベルの認識合わせをするだけで一苦労だったりします。こういった考え方を身になじませて、自分からすばやく提示・説明できるようになれるとまずはいいのかなと思いました。そのためにはまず設計技法を熟知している必要があります。テスト設計技法を使いこなしたいという思いは漠然と持っていましたが、ここに来てテスト技法をしっかり学んで馴染ませるためのはっきりとした目的ができたなと思いました。
おわりに
こんなこと考えてWACATEに参加してたよ、帰ってきてからまた考えたよという話でした。
自分が参加した回の招待公演について、2024夏の「モデリングのそだてかた」での「考え方を鍛える」というお話や、2024冬の「テスト設計技法をチョット俯瞰してみよう」での「網羅したいことを網羅できているのか？」という問いなど、どちらもちょっと1歩引いて見てみる的な話をされているなあと思っていました。
これに加えて、2025夏でもテストが全国的に統一した考え方を持っていない頃から奔走していらっしゃったという吉澤さんが選ぶ本が「具体と抽象」であるというのを受けて、標準や共通認識を作っていくのに必要な考え方なんだろうなとさらに感じました。
(尚、2024夏の水野さん、2024冬の鈴木さんの招待公演についてはスライドが公開されていて、WACATEの公開資料からアクセスできます。)
テスト・QAをしていてなんか上手くいかない、どこに向かったらいいかわからないと思ったときに、1回引いて見てみたり、今自分がどの抽象レベルで考えているのか？具体に固執していないか？と考えられるようになっていきたいなと思います。
ユニファでは一緒に働く仲間を募集しています！
気になった方はぜひ採用ページをチェックしてみてください！
jobs.unifa-e.com
