SmartHR Tech Blog

SmartHR 開発者ブログ

チームのテストフローを見直して、実装時間を2倍に増やした話

こんにちは!SmartHRで基本機能の開発を担当している、エンジニアのwakasaです。2023年の1月から半年かけて、自チームのテストフロー見直しを行い、実装時間を大幅に増やすことができました。今回はその取り組みをご紹介します。

見直し前のチームの状態

私の所属するEチームは、SmartHRの基本機能の中でも、従業員情報やマスターデータの履歴データ管理周りの機能開発を主に担当しています。2023年8月現在、エンジニアが6名、プロダクトマネージャーが1名、プロダクトデザイナーが1名所属しており、QAエンジニアは所属していません。以前はQAエンジニアがチームに所属していましたが、2022年10月にチームを離れました。QAエンジニアがチームを離れたあとはエンジニアがテスト業務を兼務しています。

今回の取り組みを始めるきっかけとなったのは、2022年の年末に実装にどのくらい時間を使えているのか計測したことでした。QAエンジニアがチームを離れた後、エンジニアのテスト業務(テスト計画やテスト設計、マニュアルテストの実施など)の負荷が増えた実感を持っており、テスト業務に時間をどのくらい使っているかを計測してみようと思い、作業チケットに記入された実績時間から、2022年の11,12月の実装やテストに使っている時間を計測しました。

その結果が下記です。

Eチームの2022年11,12月の時間計測

ほとんどのエンジニアがテストに多くの時間を費やしていることがわかります。グラフの一番右側は業務委託のエンジニアですが、業務委託の方はテストを担当していなかったため、実装/調査の時間が多くなっています。その方を除いた正社員だけの時間比率は下記のようになりました。

実装/調査: 21.1%
テスト: 69.0%
その他: 9.9%

つまり、スプリントの時間の中で、実装時間には2割程度しか時間を使えておらず、7割をテストに時間を使っている状態でした。

もちろんテストは非常に重要であり、我々のような従業員情報や履歴データをメインに機能開発しているチームとして、テストを行うことは非常に重要な業務だと認識しています。一方で、QAエンジニアがチームを離れ、エンジニアのみでテストを行うようになって以来、作業フローや作業内容の改善は何も行っておらず、これまでと同じことを続けている状態でした。そのため、効率化できる余地や改善できる部分があるのではないかと考え、テストフローや作業内容の見直しを行っていくことになりました。

現状の分析と課題の整理

見直しを進めるために、まず最初に現状の分析と課題の整理から行いました。現状のテストフローを書き出し、その中で課題になりそうなことを列挙しました。

また私自身はソフトウェアテストについてきちんとした学習をしたことがなかったので、並行して、 【この1冊でよくわかる】 ソフトウェアテストの教科書 を読み進めて、ソフトウェアテストの基礎知識を学習していきました。

Eチームテストフロー(Before)

そして上記のような図を作成し、QAチームに意見やアドバイスをもらいにいきました。現状のフローについて、私が誤解していた部分やちゃんと理解できていなかった部分が明らかになり、課題の理解を深めることができました。

その後、課題の内容を重要度や緊急度から整理し、チームに共有して、課題に対する意見や実感と異なる部分があるかなどを議論しました。共有した内容とチームメンバーの肌感として、そこまで大きなズレはなかったので、各課題について継続的に議論し改善していこう、という合意を得ることができました。

テストフローの改善

改善の具体的な進め方については、週に1時間、「QAについて考える会」というMTGを設けて、チームメンバー全員で議論して改善を進めていきました。

当初は、その会の中で課題を一つずつ話していき、改善していけば良いと考えていました。ただ最初の会で、そもそも「品質」ってなんだっけ?という話になったため、みんなが思う「品質」について認識合わせから始めることになりました。そこで最初にEチームが考える品質についての共通の理解を持つことができ、この後の課題改善の議論の基盤になりました。

Eチームの考える品質

その後は、下記のような議題について毎週議論をして改善案を検討していきました。

  • マニュアルテストを実施したい時ってどういう時?
  • マニュアルテストを実施するしないの基準は?
  • Herokuのreviewappsとローカル環境でのマニュアルテスト実施どう使い分ける?
  • 実装者とテスト実施者が同じなのってあり?
  • rspecのsystem specとJestの使い分けは?
  • 現状のパフォーマンステストに対する課題感は?
  • 現状の受け入れテストに対する課題感は?

議論した結果、下記のようにテスト周りの進め方が変わりました。

Before After
品質に関する共通認識がない 機能性/信頼性/利便性の三つの観点
マニュアルテストを毎回実施 マニュアルテストで実施する部分と自動テストで実施する部分を分ける
環境は毎回reviewappsを立ち上げ 基本的にローカル環境で実施
テスト設計は実装より前でも後でも良い テスト設計は実装よりなるべく前で行う
コードレビューやテスト設計レビューはランダムアサイン コードレビューの1人はマニュアルテスト実施者、テスト設計レビューの1人は実装者をアサイン
実装者がテスト設計からテスト実施まで行うことはなし 実装者がテスト設計からテスト実施まで行うことは推奨はしないがあり
Jestに関するルールなし 基本的にJestを書く、難しい場合はsystem specを書く

またテストフローの改善ではないですが、業務委託の方にもテスト業務に参加していただくようになりました。

これらの施策を実施した結果、テスト時間の比率は下記のようになりました。

Eチームの2023年5,6月の時間計測

全体的に実装/調査にかける時間が増えていることがわかります。 正社員だけの時間比率でいうと下記のような比率になりました。

実装/調査: 52.7%
テスト: 33.6%
その他: 13.7%

2022年の11,12月と比べると、下記のように実装/調査の時間が倍増し、テストの時間が半減していることがわかります

実装/調査: 21.1% => 52.7%
テスト: 69.0% => 33.6%
その他: 9.9% => 13.7%

QA業務の負荷もだいぶ軽減されたし、実装/調査の時間も増えたし、これでめでたしめでたし…となるかと思われたのですが、テストフローを改善したことでこれまでとは別の問題も出るようになりました。

今後の課題とこれから

テストフロー改善から数週間経って、チームでGKPTを行いました。その中では下記のようなProblemが出てきました。

  • 自動テストとマニュアルテストで実施する部分を分ける時にすり合わせコストが高い
  • 自動テストのどの部分が、テスト設計で書かれている箇所を担保することになるのかが実装者以外はわかりにくい
  • テスト設計がこれまでと変わっておらず、今のスタイルと合ってないので変えたい
  • テスト設計、実装、テスト実施を全て1人で行うと不安が残る
  • Jestを書ける人がまだまだ少ない

などなど様々なProblemが出てきました。このGKPTの後、一部改善されて問題ではなくなったものもありますが、まだまだ我々のテストフローの改善は道なかばというところです。

逆にGoodとしては下記のようなことが出てきました。

  • マニュアルテストのコストが明確に減った
  • テスト設計から自動テストに落とし込む意識がついた
  • 自動テストの網羅性が上がった
  • reviewappsの立ち上げの待ち時間がなくなった
  • テストフローについて意識することが増えた

この中でも特に「テストフローについて意識することが増えた」は、個人的にも想定外の良かったことでした。これまではQAエンジニアが作成されたフローに従うだけで、チームの中で、テスト周りをどうしていきたいかなどの意見はあまり出ていませんでした。今回の改善を通じて、我々が大事にしたい品質が明確になり、どういう意図を持ってこのフローにしたかを皆が共通認識を持って進められるようになりました。結果として、テストフローについて自分ごと化でき、チームの中で話し合うことが如実に増えたと実感しています。

まだまだ改善点も多い現状ではありますが、今のチームであれば、今後も継続的にテストフローを改善していけるのではないかなと思っています。

これからもテストフローの改善を通じて、より安心して使っていただけるプロダクトをより素早くお届けできるように頑張っていきたいと思います!

We Are Hiring!

SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です!

少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう!

hello-world.smarthr.co.jp