上流工程からテストを考えるワークをしてきたお話 ～WACATE2022夏の参加レポート～
2022年6月18日と25日の2日間で開催された「WACATE2022夏〜テストできないと言う勿れ〜」に参加してきました。
その参加レポートを複数回に分けて報告したいと思います。
今回はWACATEとは何かを簡単に説明した後、上流工程からテストを考えるワークを通して感じたことをお伝えできればと思います。
上流工程からテストを考えるワークをしてきたお話（←今回はこれ）
WACATEの招待講演（アジャイル開発におけるQAの在り方）を聞いて感じたこと
発表経験を通して感じたこと（まとめれば書く）
おことわり
今回のレポートは非公式なものであり、自分なりに整理したものです。
また所感の内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。
「こんなこと言っているんだな~」と思ってみていただければと<(_ _)>
お伝えしたいこと
WACATEはワークショップ型の勉強会で、今回はユーザーストーリーからハイレベルテストケースを考えるワークに参加した
ユーザーストーリーから受け入れ条件を考える際は、ユーザーにとって価値があるかどうかという基準で考えること
受け入れ条件を確認するテストには正常系、異常系を含める必要がある
いろんな背景を持った方と議論をしたことで、自分にはなかった/足りなかったものが見つかった
WACATEってなに？
公式ページには以下の記載があります。
Workshop for Accelerating CApable Testing Engineers：内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ
簡単に説明すると若手エンジニアを対象としたソフトウェアテストの勉強会です。ワークショップ型の勉強会のため、ソフトウェアテスト技術以外にも学べることが多い印象です。
今回のテーマは「設計者や開発者が何かを作ってくれないとテストできないという状況から脱却しようぜ！」ということで、上流工程からどうやってテストを作っていくかを体験する2日間でした。
何で参加しようと思ったのか？
テストを考えるときにはいろいろな視点が必要だと思っています。
ただ、私はその視点の数が足りていないと感じていました。
実際にレビューを受けた時に、そこは考えていなかったなと思う場面が多々ありました。
そのため、このワークショップをすることで自分に足りない視点が見つかるのではないかと思い、参加しました。
要件からテストを考えるワークでどんなことしたの？
ワーク実施背景などはこちらの資料で公開されています。
近年、テストを取り巻く環境が変化しており、開発の早期からテスト活動を行うようになってきました。
そんな環境変化に対応できるよう、実行委員の皆様がワークを企画していただきました。
そのワーク内容は上流工程からテストを考えるということで、ペルソナ(※1)とバリュープロポジションキャンバスから出たユーザーストーリー(※2)を基に受け入れ条件（※3）を作成し、そこからテストケースを作るという内容でした。
スコープとしては、システムテスト部分になります。
ワーク1はユーザーストーリーから受け入れ条件を作るというセッションと受け入れ条件からテストケースを作るというセッションの2構成でした。
ワーク2は別のお題でひととおり頑張るっていう形です。1日目に学んだことを2日目でやってみようっていうことですね。
このワークではじめて知ったのが、バリュープロポジションキャンバスでした。（名前を覚えるのに時間がかかりました）
バリュープロポジションキャンバスとは
アレックス・オスターワンダーさんのの「バリュー・プロポジション・デザイン（※4）」にて、詳しく紹介されています。
ざっくり説明すると自分たちの製品やサービスとユーザーのニーズを比較するためのフレームワークになります。
以下の図がとてもわかりやすかったです。
実際ワークをやってみて学んだこと
学んだ部分は3つありました。
①受け入れ条件の粒度
このワークをやるまでは受け入れ条件を設定したことがなかったため、どのくらいの粒度でやるべきかが分かりませんでした。
（テストケース並みに粒度を細かくするのか？大きくまとめてしまっても良いのか）
その粒度の部分で班の皆様と議論する中で、
ユーザーストーリーは顧客価値であり、ビジネス視点で受け入れ条件を考えるのが良いということで腹落ちしました。
つまり、受け入れ条件をクリアすることでユーザーに価値のあるものかどうかという基準で考えれば良いということです。
例えば、何かの登録処理の場合、「入力できること」が受け入れ条件になりません。
入力出来たところで登録が出来なければユーザーにとってはうれしくないからです。
このような目的の部分でユーザー（相手）にとって何がうれしいのかを考える視点はあまり持っていなかったため、非常に勉強になりました。
②上流工程から不明確/曖昧な部分を明確にすることで、バグの作りこみ防止に貢献できる
今回のワークでユーザーストーリーに不明確/曖昧な部分がいくつかあり、実行委員に質問したところ、チームと実行委員の間でギャップがあったため、受け入れ条件を修正する場面がありました。
これは普段の業務でも起きることだなと感じています。（例えば、開発者とテストエンジニア間、開発チームと経営層間とのやり取り）
またソフトウェアの書籍（※4）では、ソフトウェアのエラーのほとんどは情報の伝達と変換の時の破壊・誤解・雑音に原因すると言われています。
そのため、早期から携わり認識を合わせる活動（シフトレフト）を行うことでバグの作りこみを防げる可能性が高くなるなと感じました。
③フレームワークに依存しすぎない
1日目の分科会と2日目の実行委員のコメントで言われたことですが、今回のワークで使ったフレームワークは最小限のものであり、本当はもっと使用する場合があります。（ex.ユーザーストーリーマッピング(※5)やデジタルサービスデザイン(※6)等）
ただ、フレームワークをどう使うかというより、「何を実現したいか」を優先させることが重要だとおっしゃっていました。
目的をまず考えることはとても重要であると学んだとともに、私はすぐにツールを使うことに走ってしまう時があるなと感じました。
目的に立ち返れるような仕組みを作る必要があると思いました。（何かいい方法があれば教えてください（））
このワークを通しての感想
このワークショップでいろいろな方と議論することで、上流工程からテストを考える時に気を付けるポイントや自分に足りない視点などが見つかり、非常に有意義な時間でした。
1日目はファシリテートを担当しましたが、班の方々が優秀で、とても楽しくスムーズに議論できたな～と感じています。（テスコンとかしたら楽しそうだなと。。）
ただ、ファシリテートに関してはいくつか課題があるなと感じました。
議論がずれた時の修正力や進め方であったり、話の振り方であったりと普段人見知りでしゃべり慣れてない感じが出てしまったのが反省点です。
徐々に慣れていきたいと思います。
最後に
WACATEはワークショップ中心の勉強会で、いろんなことが経験できる場になっていると思います。
次回は冬(12月)に開催されるので、興味を持った方はぜひ参加してみてください。
注釈
（※1）商品やサービスを利用する架空のユーザー情報。職業やライフスタイル、趣味嗜好や価値観まで詳細に設定する。
（※2）日常言語またはビジネス言語で表現された、1つの文で構成されるユーザー要件またはビジネス要件。ユーザーが必要とする機能、その背後にある理由、何らかの非機能、および受け入れ基準を含む。（ISTQB用語集）
（※3）ユーザ、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない基準。(ISTQB用語集)
（※4）
（※5）
（※6）
（※7）
この記事が気に入ったらサポートをしてみませんか？