こんにちは、はじめまして。SmartHRのQAグループ所属の平澤（以下、higesawa）と申します。
本記事は、「SmartHRのQA（品質保証）」連載企画の第2弾です。 SmartHRのQAグループはソフトウェアテストを中心に、メンバーのスキルセットやプロダクトの状況によって、柔軟かつ多岐にわたるアプローチで品質保証活動を行っている組織です。今回は私higesawaが入社後、配属されたチームでどんなことをしてきたのかをチームの歩みとともに紹介していきます。
自己紹介
2020年12月入社。これまでSNS・ブラウザゲーム・スマホアプリ・IoT製品などの業界でQAとして従事。SmartHRにて初めてのアジャイル開発を経験し、かつて経験したメテオフォール型開発との違いに驚愕。現在はプロダクト開発の1チームに入り、品質保証活動を行っている。
チームの立ち上げ期
まず私の担当するチームについて簡単に紹介します。私の担当しているプロダクトでは開発手法としてLeSS(大規模スクラム)を採用しています。現在は5つのスクラムチームで構成され、各チームにはQAメンバーが1人ずつ配置されています。私は今年1月に結成されたチームへ立ち上げ期から参画しました。
当初、私は1つの壁にぶつかっていました。
「アジャイル開発でのQAはどんな動きをすればええんじゃろ？」
今までの私の経験では、数ヶ月かけて企画・開発された大きな1つの機能に対して大量のテストケースを準備し、テストを実施し、それらを経て初めてリリースするというものでした。
一方、SmartHRのアジャイル開発では毎日リリースが行われており、1つの機能を複数のタスクに分けて1週間(1スプリント)で3,4件のタスクをこなしていきます。それらをタスク毎にテストし、結果がOKとなり、リリースできる状態となって初めて「期間内に計画したタスクを全て完了できた（以下、バーンダウン）」と言えます。
この経験したことのないスピードで進む開発は私にとっては衝撃的でした。
さらに、担当となったチームは立ち上げ期であるがゆえにワークフローなども定まっていないうえ、アジャイル開発未経験の私は自身が行うテストにどのくらいコストをかけるのが最適かも分からない状態です。「これは、とにかく手を動かすしかないな」と思ったことをよく覚えています。
暗中模索ではありましたがチーム立ち上げ期だったからこそできることが多く、改善へのアプローチのしやすさもありました。
最初にやったこと
QAグループの諸先輩方に、まずは「スプリント内でどうやってテストを回しているか」を聞きつつ、自分なりに以下を実践してみました。
- テストケースは作りこまない
- 1タスク毎にスプレッドシートやエクセルでテストケース化をしているとコストも膨らみ、スプリント内でタスクを消化できない
- テスト方針となるテスト観点をリスト化し、それに沿った探索的テスト(参考：探索的テスト)を実施する方針
※ 以下、本記事ではこの「テスト観点のリスト化」作業を便宜的に「テスト設計」と呼称します
- 自身の経験の踏襲
- 各タスクで小さなウォーターフォールを繰り返す
スプリント内のフローは大まかに以下のような流れでした。 黄色部分が私の主な対応部分です。
この当時はバーンダウンしないことが多かったです。
チームの立ち上げ期のため多くの要因があったのですが、テストもその1つでした。
実装〜コードレビューの終わるタイミングがスプリント最終日 or その前日となり、複数のタスクのテスト依頼が一気にくるため手が回らず、最終日の夕方や夜にバグ報告することもしばしばありました。
私にとっても、プロダクトエンジニア（以下PdE）にとっても、「最終日の夕方・夜にバグの報告があるかもしれない」というストレスはかなりのもの。精神的にも健全ではなかったと思います。
また、もう1つ顕著な影響をもたらす要因として、チームメンバー全員のMTGの量も多かったことがあげられます。MTGが主にスプリントの前半に固まっていたため実装が遅れてしまい、テスト依頼の遅れにつながっていました。
これらを解決すべく、チームメンバーやQAグループの諸先輩方と相談し、2つのシンプルな実験が始まりました。
- MTGを分散する/無くす
- コードレビュー完了前にテスト実施着手をする
結果、2つの実験は成功し1タスクあたりのリードタイムを縮められました。
実験のうち、前者については読んで字の如しなので詳細は語りません。
後者については上手くいくか不安がありました。コードレビュー完了前にマニュアルテストを実施するということは、実装コードはその時点でfixされていないということなので、テスト実施中あるいは実施後にコードに修正が入り、テストのやり直しが発生する可能性も大いにあります。
そういった不安がある中でこの実験が上手くいったのはチームの開発フローに起因します。
改善前後の開発フローは上図のとおりです。
実験成功の要因としては以下が挙げられます。
- 作業ブランチで各実装コードに対し一度レビューが行われている
- そのため、 まとめブランチ の信頼性がすでに高い
- まとめブランチ作成後のレビューで修正が入ることは滅多にない
- まとめブランチ作成後のレビュー完了の待ち時間がなくなった
以上から、それまでより1ステップ早く環境構築・テスト実施ができるようになりました。
これにより前述したバグ報告のタイミングについても、スプリント終了間際で報告するというリスクの軽減に繋がります。
万一、まとめブランチでのレビューで何かしらの修正が入っても、テストはやりなおせばいいという判断でした。元々はまとめブランチのレビューが終わってからテストを実施していたので、やり直しが発生しても元々の流れ以上に遅くなることはないからです。
上記実験以外にも、いくつもの細かな改善の結果、スプリント内のタスクへの各種対応が次第に安定していきました。
この時点のスプリント内の全体フローは下図のとおりです。
クロスファンクショナル化への取り組み
開発フローが安定していくに従い少しずつバーンダウンするようになってきたとき、チームとして次のステップに進みました。
チーム目標設定です。チームとして活動していく中で、メンバーの個性が分かり、ある程度土台が整ってきていました。そこで、「チームとして目指すべき姿を改めて考えよう」となったのです。
その中で「チームのクロスファンクショナル化」というものが一つのキーワードになりました。
クロスファンクショナル化については弊社テックブログの他記事でもいくつか言及されていますが、我々のチームでは「我々にとってのクロスファンクショナル化ってなんじゃろ？」から考え、その結果、クロスファンクショナル化のための方針は以下のように噛み砕かれました。
- 全員がすべての職種をこなせるスーパーマンにならない
- 属人化を解消するべく個々人が専門領域以外も幅広く対応できるT型人材を目指そう
この文脈から、テストという領域でのクロスファンクショナル化が始まり、テスト設計・実施をPdEに教え、実践していくことに。
そうすることで当時チームに4人のPdE、1人のQAという構図で、ボトルネックだったテスト設計・実施が少しずつ解消されていきました。
そして多少の余裕が生まれてきた私higesawaは自身の目指すべきクロスファンクショナル化としてテストコードの実装にチャレンジしました。
SmartHRはRuby on Railsで開発されているためRSpecを学び、単体テスト(request spec / model spec)のレビューをしてみたり、E2Eテスト(system spec)をペアプロなどでPdEの方々に教えてもらいながら実装をしてみたり。
これまでもフローの一部として組み込まれていたSpec実装に関して、同じテストの領域にもかかわらず、恥ずかしながら自身で対応し始めるまでは完全なブラックボックスになってました。レビューし実装し、初めて「マニュアルテスト削減できるところ結構ある...？」と気づいたのです。
同じ頃、TechBlogQA連載第1弾でインタビューを受けたmugaマネージャーがATDD開発を小さくスタートした話が上がってきました。
このことがキッカケとなり、私の所属するチームでテストの領域に興味を持ってくれたPdEたちと「うちのチームで実現するには」を一緒に考え、新たな実験がスタートしていくことになります。
テスト戦略の検討・実験
SmartHRでは「最短距離で価値を届ける」を1つの方針として開発を進めています。
その「最短距離」と照らし合わせたとき、前述の「ATDDをうちのチームで実現するには」は現状はできなさそうという結論に至りました。
ただし、そこで終わらずその代わりとなる「テストにおいて自分たちにとってのベストな最短距離はなにか」を模索できたのは、間違いなくチームのメンバーに恵まれたからだと思います。
このATDDとは違った「自分たちにとってのベストな最短距離」を目指すべく、新たな実験として以下をスタートしました。
- リファインメントが終わったタスクのテスト設計をスプリント開始前に完成する
- 必ずしもマニュアルテストでやらなくていい(Specで担保できる)と判断した部分は思い切ってSpecに任せる
- 判断するためにスプリント開始後すぐ、実装開始前にPdEと一緒にテスト観点リストを以下に振り分ける
- 各種Specで実施するもの(例：model spec, request spec, system specなど)
- マニュアルテストで実施するもの
- 各種Specに振り分ける際は、describe,context,itの粒度まで具体化する
- フロントエンドのテストコードの実装
各種Specに振り分けられるテスト観点について、PdEとテストピラミッドについて共通認識を持ち、各種Specのボリュームを意識しながらコードへの具体化が進められました。
この実験の結果、1タスクあたりのリードタイムはかなり短縮されたように感じています(残念ながら定量的な計測はまだできていませんが)。それだけにとどまらず、
- 各種SpecにQAの目が届くようになったことでテストコードの信頼性が向上
- 各種Spec実装時に考えるコストが下がった
- マニュアルテストにかかる工数が減った
- higesawa自身がRSpecにふれる時間が増え、学習が進んだ
など、多くの効果が生まれました。
ただし、不確実性の高いタスクに対しては適用が難しいという問題も抱えています。
我々のチームでは普段、リファインメント時にタスクの「仕様」と「実装方針」を定めています。ただ、タスク中には実装を開始してからでないと明確な実装方針が定まらないものが存在します。
実装方針が定まっていれば、実装開始前に各種Specで担保するテストについても定義できるのですが、定まっていない場合だとテスト設計はできるものの、各種Specについては定義がしづらいのです。
これについては、今後の課題として考え、実験していかないとなと思っています。
まとめ
ここまでがチーム立ち上げから約8ヶ月間、テストへ焦点を当てた取り組みの話でした。QAメンバーとしてはもちろん、皆一丸となって課題解決に向かって動けるとても素敵なチーム文化であるため、毎日楽しく仕事できています。
今回は私higesawaが所属するチームでの取り組みの話でしたが、他の開発チームにはまた違った色や形があり、各チームに所属するQAメンバーも自律駆動で活躍しています。チームへの関わり方は自身の裁量に任されているため、組織文化を大切にしながらやりたいことにチャレンジできます。自身の取り組みをQAグループ内などで共有すると意見をくれたり褒め称えてくれたり「自チームに持ち帰ってやってみよう」と言ってくれたり。良きシナジーが生まれやすい環境でとても働きやすいです。
We are Hiring !
最後まで記事を読んでいただき、ありがとうございました。
SmartHRのQAに興味を持っていただけましたら、下記の採用サイトからエントリーいただけますと幸いです。カジュアル面談も実施しておりますので、選考に進む前に気になることがありましたらぜひ、気軽に聞きにきていただけたら嬉しいです。みなさまのご応募お待ちしております！
