スクラムチームにおけるQAの軌跡と苦悩
みなさん、こんにちは！Showcase GigのQAエンジニア横田です。
私が所属しているチームは、スクラム開発をしています。
チームにはQAも所属しているため、設計から実装、テストまでを1チームで完結できます。
今回は、スクラムチームでQAが取り組んで来たことや、苦悩を書いていきます。
現在までの軌跡
スクラムイベントへの参加
スクラムチームに参加しているので、スクラムイベントはすべて参加しています。
・スプリントプランニング
このスプリントで何を行うかを決める場です。
当初は、各タスクの受け入れ条件（Acceptance Criteria）を把握する場となっていました。この情報からテスト項目作成/実施をしていました。
ただ、この情報だけでは、「誰がその機能をどのように使用すること」が明確ではありませんでした。そのため、実際のユースケースに沿ったテストが不十分でした。
これらから、ユーザーストーリーを各タスクに明記することを提案しました。これに伴い、ユースケースに沿ったテストケースが作成できることと、担当外のメンバーでもより具体的にタスク内容を把握できる様になりました。
・デイリースクラム
毎日、デイリースクラムを実施しています。
本来は、「スプリントゴールができるかを検証する」のが目的になるのですが、実態としてはタスクの進捗状況確認がメインになっていました。 早めにテスト項目を作成し「レビューをお願いします」や「いつまでにQA環境に反映できるか」などを、頻繁に発言していきました。
スケジュール観点でオンスケなのか、遅れているのかをQA側で意識し伝え続けることが大事だと思っています。実装メンバーには、設計や実装に専念してほしい想いもあります。
・レトロスペクティブ
スプリント終了後に、チームでの課題を出し合い、どう改善すべきかを議論する場です。
QAエンジニアはチームに所属していても、一歩引いた位置から俯瞰的な視点で物事を伝えることが大事だと私は思っています。
例えば、デイリースクラムの時間を15分と設定していても30,40分となってしまっていた時に、進捗報告が多い立場だと時間を意識するのはやや難しいのかなと感じています。
そういう時は、タイムキーパーを行い、その時間が適切か否かを判断することも必要だと思っています。 そのような課題・改善案を、この場で共有します。
QAの仕事とは異なりますが、チームの一員として担当か否かは関係なく行います。何でも当事者として取組むことが大事です。また、スプリント開始後に各担当者とQA環境反映タイミングやタスク内容のすり合わせ会を実施し、スプリント内の作業精度を上げるための提案を行い実践しています。
・スプリントレビュー
スプリントで行った内容を、検査する事を目的とした場です。
こちらは、最近開始したイベントです。スプリントレビュー実施前は、チームとして課題を行う事に専念しており、対応内容の共有ができていませんでした。
実施提案を行い、チーム内で合意を得られたので開始しました。実施が必要だと感じた要因としては、QAは最後に一通りのテストを行うので、ある程度このスプリントで何を成果として上げたのかが把握できます。
しかし、ほかのメンバーは個々のタスクが完了したことは見えても、それらが何を生み出したのかが把握できていないのではないのかといった疑問からでした。実際に行うと、多数の目で見ることにより品質が高まるように感じました。
このように、スクラムイベントに参加することで、チームの改善につながる活動ができます。
テスト工程以外でも、できることが多数あると実感できますし、チームメンバーとの距離も近付けると考えます。
テスト工程の改善
ここまではスクラムイベントに参加する際の、心構えや実績を書いていきました。ここからは、テスト工程をどのように改善していったのかを書いていきます。
・自動テストの導入
自動テストツール『MagicPod』を導入しています。導入時、いくつかのツール検討した結果、モバイルアプリケーション/ブラウザ共に自動テスト実行が可能なツールであったため、MagicPodを導入しました。
リリース前のリグレッションテストの一部や本番リリース後の動作確認を、自動テストで行えるようになりました。機能単位でのテストや探索的テストも行っているため、手動でのテストがなくなった訳ではないですが、MagicPodを導入したことでリリースまでに安定性のある作業が行えるようになりました。
現在では、毎日9時に定期実行が行われます。そのため、前日にQA環境へリリース内容が反映されていた場合は、"意図して"失敗させます。失敗させている理由は、変更した事が正常に反映されていることが、確認できるためです。その後、メンテナンスし再実行して成功できるようします。大部分の項目を修正することもありますが、毎日手動テスト実行やSeleniumなどのメンテナンスを行うことと比較しても、負荷は低減されています。 また、マニュアル作成時に使用する画像もMagicPodを使用して、取得している部分もあります。
・アドホックテストから探索的テストへ
以前は、探索的テストは行っておらず、数時間アドホックテストを実施していました。当時は、何も意識せずに実施者の思いでバグ出しをしていました。自動テスト導入でき時間が生まれたにもかかわらず、無作為にテスト実行するのはもったいなく、バグの検出数も伸び悩んでいたので探索的テストに切り替えました。
進め方は、テスターと私で実施前に観点を共有します。過去に発生した不具合からの傾向や、次リリース内容から観点をテスターに出してもらい、この観点も追加してほしい旨を伝えてテスターが実施します。
効果としては、2点あります。
①不具合の検出数が上がりました。探索的テストに切替後は、検出率が2倍に向上しました。
②観点の共有が事前にできたことで、機能の弱点を把握できました。
・早期にテスト項目作成実施
以前は、テスト実施開始までに作成すれば良いだろうという意識であったため、スピード感が遅い状態で作成に取り組んでいました。そのため、準備に時間が掛かってしまったり、レビューもなく実施する流れになっていました。
現在は、プランニング内でユーザーストーリーを見ながら、並行して簡易的にテスト項目を記載しています。プランニング後にブラッシュアップしています。遅くても、プランニングから2営業日程度で項目作成を終えることができるようになりました。ほぼすべてのタスクに対してレビュー依頼を行い、担当者と認識を合わせることが早めにできます。テスト実施までに多少のゆとりができるので、その期間でほかに改善すべきことを取り組んでいます。
・テスト項目をCSチームとレビュー
CSチームにテスト項目のレビューをお願いしています。
始めた理由としては、弊社のサービスは「店舗担当者」「一般のユーザー」が利用者として存在します。CSチームは、店舗担当者とやりとりをしているため、開発チームにはない観点を持っています。その観点を、テスト項目に追加することで、リリース後の問い合わせが減少できるのではと考えたためです。
実際にレビューFBをもとに、実装を修正してもらった部分もあるので、始めて良かったと感じています。
現在の苦悩
テスト工程においても、改善活動ができるようになってきました。
さまざまな取り組みを行っていますが、苦悩ももちろんあります。
品質測定のメトリクス化
現在の一番の苦悩は、スプリント毎の品質測定ができていないことです。
スプリントで行った内容がリリースされるので、リリース時のインシデントや不具合数で測定することを試みました。しかし、バックエンドが中心の時もあれば機能追加がメインの時もあり、「このスプリントの品質は良かった(悪かった)」の観点指標を定めることに苦戦しています。
将来的には、チームだけでなく会社として「品質」について共通言語で語れる様にはなりたいと考えます。
テスト実施工程の分散化
テスト実施は最終工程になってしまい、手動実施部分が多くなった場合にスプリント完了までのボトルネックになってしまう事があります。テスト項目が作成できていても、実施が問題なく終わらなければ完了はできません。
ですので、テスト設計/項目作成はQAで担当し実施部分については、チーム内で分散することも必要になると考えています。
将来的には、「テスト実施はQAの担当ではなくチーム全体の担当」ぐらいになれば良いなと考えます。ただ、これだけだと、QAの負荷を減らす一方、ほかのメンバーの負荷が高まります。それでは、誰も幸せになりません。QAがテスト以外でより積極的に担当領域を増やす事が必要です。 極論ですが、設計・プログラミング以外はQAの仕事ぐらいの温度感で作業をする事が、良いのかなと考えています。
まとめ
記載した内容は、QA視点でありほかのメンバーからの提案や改善でチームとしてどんどん良くなっている様に感じています。QAもテスト工程だけでなく、さまざまな取り組みを行える事が実体験として得ることができました。受け入れてくれるチームメンバーに感謝しつつ、チーム強化ができるように進んでいきます。
さまざまな視点から改善活動が行える環境で、一緒に働くQAエンジニアを募集しています。興味を持ってくださったら、一緒にプロダクト開発しましょう！
この記事が気に入ったらサポートをしてみませんか？