テストエンジニアのためのワークショップ「WACATE 2022夏」の参加レポート
こんにちは、QAEチームのぜにです。
6/18（土）、6/25（土）の2日間開催された「WACATE2022 夏」に参加してきましたので、感想や学びについてまとめました！
WACATEとは ：https://wacate.jp/
Workshop for Accelerating CApable Testing Engineers：内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ
もくじ
- 参加の目的
- やったこと
- 学んだこと
- WACATE初参加の感想
- これから
参加の目的
日々の業務の中で悩んでいることなどを解消できるヒントを見つけることと、他社で働いているQAエンジニアの方々と交流の機会を持つことが目的でした。
また、WACATEのワークが始まる前に「2日間で持ち帰りたいこと」を各個人で決める時間があったので、そこでは下記を持ち帰ることを目標にして2日間取り組みました。
- 出来上がったものだけではなく要件に対してのテスト方法を知りたい
- テスト活動のシフトレフトにつなげたい
やったこと
今回は「設計者や開発者が何かを作ってくれないとテストできないという状況から脱却しようぜ！」がテーマで、V字モデルの「要件定義」と対になっている「システム/受け入れテスト」を作成するワークを行いました。
1日目と2日目それぞれどちらも下記のような流れでグループワークを行いました。
- 例題の事前情報をインプット
- 受け入れ条件を考える
- システム/受け入れテストのテストケースを考える
- 各班の発表
- 振り返り
まず、例題の事前情報をインプットします。
事前情報には「ペルソナ」「バリュープロポジションキャンバス（VPC）」「ユーザーストーリー」が用いられ、それを基に受け入れ条件を考えます。
ペルソナ ：引用「wikipedia」
サイト、ブランド、製品を使用する典型的なユーザーを表すために作成された仮想的な人物像のことである
バリュープロポジションキャンバス ：引用「MarkeTRUNK」
自社の製品やサービスと顧客のニーズとのあいだのずれを解消するためのフレームワーク
=> バリュープロポジションキャンバスから複数のユーザーストーリーが考えられます
=> その中の「一つのユーザーストーリー」から受け入れ条件を考えます
受け入れ条件を考えるのが個人でもグループでも一番苦戦していたと思います。
苦戦した点としてはこちらです。
- 細かな機能の仕様ではなく、あくまでユーザーストーリーに沿った要件なので抽象度の高い要件を考える必要がある
- 事前情報にない、前提にどんな条件があるのかをグループ内 / 実行委員の方とすり合わせをする必要がある
- 事前情報の「ユーザーストーリー」以外にフォーカスしすぎるとユーザーストーリーに沿った受け入れ要件ではなくなる
- ユーザー（プロダクトを受け取る側）に受けれ入れられる条件ではなく、作る側の都合の良いように受け入れ条件を考えてはいけない
受け入れ条件に対するテストケースを考える時も、その場にプロダクトの実体がないので難しかったと感じました。
普段は要件定義、仕様策定済みのデザインやプロダクトに対して具体的にテストケースを作成していますが、ユーザーストーリーに沿って抽象度の高い要件、テストケースを作成するとなると、頭の切り替えが必要で大変でした。
学んだこと
要件定義などの静的レビュー
- ユーザーストーリーを自分たち（開発側）の都合で解釈せず、ユーザーが求めていることを読み解く
- 要件定義にはユーザーのpainを取り除くことでビジネスに繋げる想像力が必要
- 限られた時間の中で要件定義（または要件のレビュー）を行うときは、前提条件と考える範囲を決める
WACATEに参加して、自分の中で何が重要なのかを限られた時間で判断できるスピード感と想像力が課題だなと感じました。
toCのサービスでテスト活動を行なっていたときは、自然とユーザーの立場になってか考えることができたのですが、現在のtoBのサービスではなかなか実際のユーザーに対しての想像力が足りていないと感じました。
また、今回の要件定義 / 受け入れテストのワークの経験を生かして、Carelyのテスト活動のシフトレフトにつなげていきたいと思いました。
QMファンネル
講演などのカリキュラムの時に「QMファンネル」という言葉をよく耳にしましたが、WACATEに参加するまで聞いたことがなかったため印象に残りました。
ざっくり自分の理解で書くとこちら
- 「QMファインネル」には「TE」「SET」「QA」の3つの要素があり、スペシャリティがそれぞれ異なること
- 「QA」は「QMファンネル」の中にある3つの要素の中の1つだということ
- 「TE」：テスト実行、設計、管理などをする人
- 「SET」：テストの自動化を進める人
- 「QA」：チーム全体の品質向上、プロセス改善する人
- 3つの要素をバランスよく活動しないと品質の向上が難しいこと
もっと詳しく、QMファンネルとは: 参考「品質を加速するために、テストターを増やす前から考えるべきQAファンネルの話」
QAエンジニアとしてのこれから
テストは要件定義や開発段階など、自分の専門性を活かすことができないフェーズにも必ず関係するものなので、全てのフェーズにおいて一緒に考えて生み出すことができる能力が必要だということを学びました。
WACATE初参加の感想！
率直に楽しかったです！
初参加で怯えていましたが、同じく初参加の方が多くみんなで成長しようという雰囲気だったので、2日間楽しく過ごせました。
グループワークを進めていく時に、時間がない中で一定の成果物を出さなければいけない状況が多々ありましたが、同じ班の方々との雰囲気作りや時間管理が徹底できてスムーズに議論できたのが良い経験だったなと思います。
実行委員の方や班が一緒だった方々に感謝です🙏
また、参加するときにPP（ポジションペーパー）を書いたのですが、急いで雑に書いてしまったので次回参加するときはしっかり力を入れて書きたいと思いました💪
また2022冬にもできれば参加したいなと思います！
