はじめに
モチベーションクラウドの開発にQAマネージャー、テストエンジニアとしてジョインしている
masao-shimadaです。
日々プロジェクトの中でQAとしてどのようなことが出来るかを模索する日々です。。。。
概要
アジャイル開発において、QAの目線で失敗した経験談から実践すべきことを投稿させていただきます。
「アジャイルのQAってどうすりゃいいの？何すんの？」って方に読んでほしいです。
アジャイル開発プロセスについて
QAは、開発のスクラムチームと同一チームにする
開発とQAを別のスクラムチームとして実際に運用しましたが、遥かに同一チームでいることの方がメリットが大きいと感じました。
別チームによる運用した時の、体制と役割、起きた事象について説明します。
- 実際に運用したチーム体制と役割
| チーム | メンバー | 役割 |
|---|---|---|
| 機能開発チームA,B | PO、SM、開発メンバ | ストーリーから機能開発、単体テスト実施する |
| QAチーム | SM、QAメンバ | 開発された機能について結合テストし、 リリース可能か判定する |
-
運用して実際に起きた事象
- 機能開発チームは単体テストまで実施することに注力するため、QAチームまで意識がいかない
- 機能開発チームのPO,SMは自チームの開発に注力しているため、QAメンバーが仕様把握したくても時間が無い(チームメンバのフォローでいっぱいいっぱい)
- QAメンバーは、仕様把握不十分のためテスト設計、実行の考慮漏れがスプリント後半で発生し、手戻りが発生
- テストを設計、実行中に仕様変更が発生しても、別チームのためQAメンバが気づけない
プロジェクトがアジャイル開発に慣れてきた頃、KPIであるベロシティの数値向上に全力だった各チームにとって、別チームの状況を把握する余裕がなかったというのが現状でした。
同一チームに変更後、SM、PO、開発、QAが連携し、ベロシティの安定、向上することを目標にすることで
良い品質のプロダクトが生まれていくことを実感しました。
ストーリー内のタスクを開発とQAで分担する
開発するうえで、ストーリーを開発、QAで分割するか、同一にするかの運用も苦慮しました。
例えばストーリーを分割した場合、以下のようにしていました。
- 開発,QA分割ストーリーの完了条件(例)
| ストーリー名 | タスク担当 | 完了条件<機能> | 完了条件<タスク> |
|---|---|---|---|
| サーベイ担当者は、 エンゲージメントサーベイの スコアを表示したい |
開発メンバ | 結果画面にスコアに表示されること スコアの計算結果が正しいこと |
仕様把握 実装 単体テスト |
| サーベイ担当者は、 エンゲージメントサーベイの スコアを表示したい《結合テスト》 |
QAメンバ | 結果画面にスコアに表示されること スコアの計算結果が正しいこと |
テスト設計 テスト実行 |
ここでの失敗は、完了条件としての分割ではなく、担当者単位のタスクでの分割を安易に選択してしまったことでした。
-
運用して実際に起きた事象
- QAストーリーは、開発に依存するため、完了できないことがあった。（テスト設計タスクのみ完了している状態）
- スプリント計画後にバックログ内のQAストーリー入替が都度発生し、管理が煩雑になってしまった。（テスト実施出来ない為、新しいストーリー入れる、など）
- リリース時、ストーリー単位で管理しているため、開発、QAどちらもストーリーが完了しているか把握することに工数がかかってしまった。
正しい選択としては、①ストーリーの完了条件を分割、②スプリント期間内で終わらせる見積で計画を立て、③開発、QAでタスクを分担することでした。
結果、開発、QAが一つのストーリーに向け完了する動きが生まれ、計画やリリース管理もしやすい運用もしやすい状況が生まれました。
テストについて
テスト対象範囲は、ユーザーストーリーの完了条件から洗い出す
テストをする際、必要となる情報は以下のようなものがあります。
- 対象画面（対象機能）
- 実行手順
- テスト観点（画面表示、ページ遷移など）
- テスト結果
- テストパターン（バリデーションチェック、エラーパターンなど）
これらは、ストーリーの完了条件から推測し、洗い出すことが重要です。
逆を言えば、完了条件に無いものについては、対象範囲から外すことを意識しました。
仕様認識合わせは、PO、開発を巻き込んで対面で行う
テスト設計する上で仕様認識合わせは必須です。
テスト対象範囲と判断したものが正しいか判断が必要な為です。
私個人としては、ストーリーに関連するPO、開発、QAが対面で行うこと重要だと考えています。
実施タイミング
スプリント開始直後
事前準備
PO … 事前にストーリーの内容を把握
開発 … ストーリーから実装範囲、不明点を整理
QA … ストーリーからテスト対象範囲、不明点を整理
認識合わせでやること
①ストーリーの対象範囲を詳細まで洗い出し、実装漏れ、テスト対象漏れが無いように確認する
②各担当者の不明点を確認し、不確実性のあるものが無いようにする
スプリント開始直後でストーリーに対して共通認識を持つことで後半に発生する抜けや手戻りを最小限に抑えることが出来ます。
また、2者間(POと開発、開発とテストなど)のみで行った際の他者への共有漏れなども防ぐことが出来ます。
1,2週間のスプリントで、1時間、1日の遅延は致命的のため、無駄な工数は可能な限り発生しないように動いていました。
この考えは、コンサルとしてジョインしているRector社の広木さんに教わり、下記書籍を読んで実践したことにあります。
[エンジニアリング組織論への招待
～不確実性に向き合う思考と組織のリファクタリング]
(https://gihyo.jp/book/2018/978-4-7741-9605-3)
テストケースは、境界値分析、バリデーションチェックに関連する事項から優先的に洗い出す
テスト工数は、テストケースの増加に基本比例します。
そのため、ケース増加に関連する境界値分析やバリデーションチェックに関わるテストケースを優先し洗い出すことで、テスト工数の把握が容易になります。
テスト工数から実施完了日、人数をスプリント完了までに一人で完了が厳しい場合は、即座にSMと連携し、テスト実施人員の調整をすることも可能です。
常に意識すること
プロジェクトメンバー全員へのRespectを忘れない
QAは仕様把握やテストデータ作成、環境構築など開発やPOに依存する部分が多く、他のプロジェクトメンバーの作業を止めてでも協力を仰ぐ場面が多々あります。自分の役割の作業が多くある中、手を止めて話を聞いてくれます。
その姿勢や考え方に、感謝、尊敬する気持ちや行動を常に意識することが重要だと思います。
モチベーションクラウドの開発チームには、Respectの文化があり、メンバー個人がメンバーを尊重する文化が根付いています。チーム全体で意識しあえる、この関係性が最高のプロダクトを生む環境であると確信してます。
最後に
このAdvent Calenderの投稿機会を頂いて、自分を見つめなおしアウトプットする良い時間になりました。
今後も、チームメンバーで良いプロダクトになるようQAとして携わっていきます。