QAが要件定義から入ってみた話 / QA-involved-in-RD

QA Tips LT会 - vol.3での発表資料です。

Transcript

1. QAが要件定義から入ってみた 話 投稿者：Carolina Kohatsu
2. 自己紹介 本日はよろしくお願いします！ QAエンジニアの小波津（コハツ）カロリーナです。 1 前職 第三者検証の会社で主にアジ ャイルQAを担う 様々な業界を経験 2 現在 2024/3~ グロービスにてLMS （学習管理システム）のQAを 担当 3 趣味 冬はよくスキーに行ってます
3. はじめに 1 取り組みの背景 POの提案： 「要件定義段階でもQA やデザイナーの視点を入れたら、 より効率的に開発が進むのでは？」 2 結果 要件定義専用のスクラムチームが発 足（PO、QA2名、デザイナー） 3 可能となった理由 開発フェーズでのテスト工程を開発 メンバーが主体的に担える体制がで きているため、QAメンバーが要件 定義フェーズに入ることが可能
4. 実際にやってること 1 ステークホルダーとのコミュニケーション 定例会を通じて、要望の確認・ヒアリング・仕様の提案・合意形成をする 2 要求定義〜要件定義の検討・決定 ユーザーの要求を具体的な要件に落とし込む。 ステークホルダーの要求をそのまま受け入れるのではなく、根本的な課題を考える 3 情報設計・画面設計のサポート デザイナーと協力し、使いやすさ・ 矛盾のない設計・パターンの検討 4 ユーザーストーリー作成 受け入れ条件を明確化し、開発チームが誤解なく実装できるようにサポート 5 開発チームとの連携 技術的な課題や懸念を事前に共有し、仕様に反映
5. 苦労したこと 「仕様を作る」考え方へ の切り替え 要件定義の知識不足 ステークホルダーとのコ ミュニケーション 開発チームへの説明の難 しさ QAとしての価値を見出すことの難しさ
6. 得られたメリット 仕様に詳しくなれる 早い段階で仕様の矛盾や不備に気づ ける テスト設計・テストケースレビュー が効率的になる 「なぜこの仕様なのか？」を考えら れるようになる
7. まとめ 1 QAが要件定義に入ることで、 仕様の理解が深まり、バグの 削減や開発のスピードアップ につながる 2 難しいことも多かったです が、得られたメリットも大き い 3 QA以外のところでも関われることでキャリアが広がっていくことに期 待できる
8. おわりに 以上、QAが要件定義から入ってみた話でした！ 今回の話についてこちらにも記事書いてますので、 よかったらご覧ください https://qiita.com/CarolinaKohatsu/items/f7ea4b0074369ff00055