スクラムチームで探索的テストをやったお話。 - チームスピリットデベロッパーブログ

この記事はチームスピリットアドベントカレンダー2019の15日目の記事です。

Frohe Weihnachten!! …まであと9日。
こんにちは、チームスピリットのQAエンジニアのSumiです。

去年はドイツのクリスマスマーケットを紹介するという1ミリも仕事に関係ない話だったので、今年は仕事に関する話を書いてみようと思います（ドキドキ）。内容は、私がスクラムチームやほかのQAメンバーとともに行った品質保証の取り組みについてです。なお、弊社の品質保証の方法についてはQAリーダーの生井がJaSST’19北海道で登壇した資料がありますので、そちらをご覧ください。

speakerdeck.com

弊社の開発スタイルについて

弊社のプロダクトはSalesforceのPlatform上で動くサービスで、開発手法は2週間スプリントのスクラムを採用しています。これ自体はわりと一般的かと思いますが、他社と大きく違うのはリリースのタイミングです。通常スクラムの原則としては各スプリント終了時にリリースできるように開発などを進めていくとなっていますが、弊社はSalesforceの4か月に1度実施されるバージョンアップに合わせる形でスクラムを回しパッケージをリリースしています。*1
開発（テスト）体制については、勤怠・工数・経費などのモジュールごとにスクラムチームがあり、QAエンジニアが各スクラムチームの一員として日々ユーザーストーリーの機能テスト（手動）などを実施しています。1バージョンなので、開発、テスト、プロダクトマネージャーのレビュー工程が終わった後にコードをmaster branchにマージするという流れです。

課題

まだチームが勤怠・工数しかなく、日本にしかオフィスがない時代は特に問題はなかったのですが、去年夏にシンガポールの開発拠点ができ、また経費など新たなモジュールのチームが立ち上がったことで、徐々にmasterの品質を保証することが困難になってきました。
具体的には新機能開発や不具合修正の影響範囲の調査が不十分で、他機能や他モジュールに影響がでてしまうというような問題が起き始めていました。masterにマージする前のテストフェーズでできる限りの確認はしていましたし、レビューでも影響範囲の確認はしていますが、それでも…*2
そして、masterにマージしてからリリース作業まで時間がある場合はどこかで偶然的に発見されることがあったものの、リリース間隔が短くなったことでそのチャンスも減っていました。その結果、製品をリリースした後に不具合が見つかりパッチを出してしまうということが発生し始めていたため、いかにこのような不具合をリリース前に見つけつぶすかという対策が求められていました。

対策

この時求められていた"パッケージリリース前にmasterの品質をあげる"ということを実現するために、
①時間をかけず
②効率的に
③不具合（主にリグレッション課題）を見つける
という条件をクリアするアプローチが必要でした。それでかつ、リリースを遅らせないという…
そこで私たちQAが提案した方法は、リリース予定の開発物がすべてmasterブランチにマージされた後に開発チーム全員で探索的テストを実施するというものです。
具体的には、エンジニア1人当たり最低半日分の工数を探索的テストに使ってもらい、それぞれチャータに従いテストをするという感じです。ただのモンキーテストにならず効率的に不具合を発見できるようテスト分担、環境、テスト観点などのチャータを事前にQAが準備しました。またQAだけでなくエンジニアにもテストをしてもらった理由は、時間（期間）はかけられないという制約の中で工数を集中投下することで最大限の手厚いテストができるようにするためです。なお、探索的テストを通じてエンジニアにより品質への意識を高めてもらいつつ、他モジュールの製品についても理解してもらう狙いなども実はありました。

結果

エンジニアが発見した不具合をJIRAに起票してもらいQAが集計・分析を行ったあと、テスト計画に記載したリリース判定条件に照らし合わせながら、リリース可能な品質に達しているかどうかプロダクトマネージャーと議論しました。このときは残念ながら一度のテストでは十分な品質でないという判断になり、発見された不具合を修正しつつ手が空いたメンバーで追加テストを実施することになりましたが、当初の目的であった"パッケージリリース前にmasterの品質をあげる"ということは達成できたといえると思います。もし探索的テストをせずにそのままリリースしていれば、パッチにつながりかねない不具合も発見されていたからです。
ただ、もしかしたら一番の収穫は、テストを実施したことに対するプラスの意見がエンジニアから出てきたことかもしれません。このテストがエンジニアにとって、プロダクトの品質をどう高めていくかを考えるひとつのきっかけになったのであればQAとしてはとても嬉しいことです。

今後について

しかしながらこのリリース前の探索的テストはあくまで一時的な対策でしかないと考えています。
本来品質はもっと前から作りこむべきで、今この対策でギリギリのラインで品質を保証せざるを得ないということはどこかで打つべきアクションができていないということだと思われるためです。それはコードレビューの質の向上かもしれませんし、自動テストの拡充かもしれませんし、さらに適切な技法を用いた各ストーリーチケットベースのテストかもしれません。
QAとして引き続きプロダクトの品質向上と安定的な品質の保証ができるよう、そしてお客様に私達の製品を使うメリットをより享受していただけるよう、さらにいろいろ取り組んでいきたいと思っています。*3