1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

スクラム開発でアジャイルテスティングを実施し、リリースサイクルを早めたハナシ

Posted at

こんにちは、QAエンジニアの田井です。
こちらの記事は2021年12月17日に公開済みの記事です!

QAチームでキャンプ場で日帰り合宿をしてから、キャンプに行きたくてウズウズしてます。
関東近郊でオススメのキャンプ場があれば教えてください!
後日、合宿の内容についてもブログに掲載しますので、お楽しみに!!

さて、ノハナではQAのプロセス改善を常に意識しており、様々な取り組みを行なっています。
今回は、今年の初めから取り組んでいるスクラム開発とQAチームが取り組むアジャイルテスティングについてお話したいと思います。

スクラム開発導入前(オフショアでテストをしていたとき)

コストを削減する手段としてどうするかと考えたときに、よくあるケースだと思うのですが、ノハナでもオフショアでテストをしていました。ただ、オフショアでよくある課題で、英語だけしか話せないと翻訳作業が発生したりするため、日本語が話せるテストベンダーに作業を依頼することにしました。オフショアでのテストに関する記事はこちらにありますので、お時間があればご一読ください。
オフショアでのテストの大まかな流れとしては、テスト観点はノハナ側で作成し、テストケースはオフショアで作成していました。テストケースの確認内容は細かい観点まで確認しており、テストケース数も膨大な数になったため、コストは下がったものの、レビュー時間やテスト実行時間が増えることになりました。テスト実行はオフショアに任せて、ノハナ側では結果のレビューやバグの対応などを行なっていました。
日本語が話せるとはいえ言語の障壁もあり、細かいニュアンスが伝わりにくかったり、日本のメンバーよりも若干ではありますが生産性が低いなど課題がありました。
その上、事前にテスト実行の見積もり工数を出してもらい、その工数を元にリリーススケジュールを決めていたため、リリース日も不定期になっていました。その結果、テストの完了待ちが発生し、マーケチームやCSチームへの共有が漏れてしまったことや、その他の問題も多く発生していました。
また、社内でも細かい施策をできるだけ早く、定期的にリリースしたいという方針もあり、大幅な方針転換をしました。

スクラム開発導入後(開発期間とテスト期間でスプリントをわけていたとき)

そこで、スピーディーにテストまで終わらせ、定期的にリリースするために導入したのがスクラム開発です。とはいえ、スクラム開発未経験のチームがいきなり1スプリントで開発とテストを終わらせるのは難しいということで、まずは開発スプリントとリリーススプリントと2つに分けることにしました。
開発スプリントは2週間で開発とプレテストを行い、リリーススプリントは1週間で本テストと回帰テスト、リリース作業までを行うことにしました。これによりリリースの曜日が一定の期間で固定され、以前のような問題も大幅に減りました。
プロダクトバックログ(以降PBI)で管理することで、開発が完了したPBIからプレテストを行うため、早い段階でブロッキングとなり得るバグを見つけられるようになり、開発の手戻りも減り、本テストも比較的スムーズに実施できるようになりました。
この体制を数ヶ月続けたのち、満を持して1スプリントで開発とテストを実施するフェーズへ移行しました。

スクラム開発の現状

現在、ノハナではアプリを2週間に1回リリースをしています。2週間のスプリントでテストを完了させるために、探索的テストとテスト自動化を活用したアジャイルテスティングを実施していて、スクリプトテストは実施していません。
QAチームのスプリント内での流れとして、1週目は主にテスト観点の作成やテスト準備を行い、開発が終わったPBIごとに探索的テストを順次行なっていきます。PBI単位でテストするので、QAチームからのフィードバックも以前よりも早くなり、開発の手戻りも減りました。
開発の方も、開発凍結のデッドラインを設けているので、間に合わなければ次のスプリントへ持ち越すルールとし、ズルズルと開発が続いてしまうということもありません。
通常の探索的テストと少し異なる点としては、担当者により確認内容にブレ幅が出ることがあるので、大まかなテスト観点を書いています。この段階で仕様についての細かい確認も行うので、仕様の考慮漏れなども事前に見つけることができています。テスト観点のレビューも行うので、担当者により認識が大幅に異なっているというような問題は起きていません。
スプリントレビューをパスした後は、リリース用のアプリで回帰テストを行い、問題なければリリースとなります。回帰テスト自体も一部を自動化し、工数削減に寄与しています。
このフローを導入して数ヶ月経ちますが、機能の実装漏れがあったとか、インシデントが増えたとかネガティブなことはなく、リリースサイクルが早まったことにより、多くの施策をよりスピーディーにリリースできるようになりました。

おわりに

個人的にはQAでどのやり方が正解というのはないと思っています。ただ、リリースサイクルが固定されることによるメリット、早く施策をリリースしてスピーディーにお客様に届けることができるという意味では、2週間のスプリントで開発からリリースまで完了させる進め方は大きなメリットがあると感じています。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?