SmartHR Tech Blog

SmartHR 開発者ブログ

【SmartHRのQA連載:第3弾】ATDD導入と選択

はじめに

みなさん、はじめまして! SmartHRのQAグループ所属のmachiです。

本記事は、「SmartHRのQA(品質保証)」連載企画の第3弾です。 SmartHRのQAグループはソフトウェアテストを中心に、メンバーのスキルセットやプロダクトの状況によって、柔軟かつ多岐にわたるアプローチで品質保証活動を担っている組織です。

今回はSmartHRにおけるATDD(受け入れテスト駆動開発)の取り組みについて、実際にATDDを行なっているYさんに話を聞きました。

インタビューされる人 : Y

QAグループ所属
昨年から年末調整機能の開発プロジェクトに従事
今年からATDDを導入し、テストの拡充やスピードアップをはかっている

インタビューする人 : machi

Yと同じくQAグループ所属
従業員名簿機能、組織図機能、従業員サーベイ機能の開発プロジェクトに従事
ATDDに興味があるものの、なかなか手を出せずにいる

QAメンバーの動き方

SmartHRにおけるQAグループの特徴の1つに “開発チームの一員として開発に携わる” という点があります。 今回インタビューするYさんも例にもれず、年末調整機能の開発チームに参画しています。

ATDDってなに?

受け入れテスト駆動開発(Acceptance Test Driven Development 以下ATDD)の略ですが、今回お話するATDDは一般的な考え方とは異なる部分が多少あるかもしれません。 本記事では、「E2E自動テストをプロダクト開発と並行して実装することで、プロダクトの品質に寄与していく活動」と位置づけています。

本記事で実施しているATDDの具体的な実施方法は以下の手順です。

  • チケットの受入条件を確認する
  • 受入条件に応じたシナリオをE2E自動テストに起こす
    • この時要素を指定するxpath(画面の要素を指し示す構文)は仮置の状態
  • プロダクトの実装に応じて要素指定を実装する
  • プロダクトのデプロイ後、E2E自動テストをアクティブにする

ATDDを導入した背景

machi: これまでの開発スタイルは、開発者の実装が終わってからマニュアルテストをするというのが主な流れでしたよね。 そこに今年からATDDを導入していると思うんですけど、取り組みの背景を教えて下さい。

Y: 年末調整機能の開発に関しては、昨年痛みがありまして……

  • リリース直前までテストのボリュームが落ち着かなかった
  • QAメンバーだけでなく、チーム全体で負荷が高い状態が続いた

みたいな感じですね。他にもいろいろあるんですけど、目立ったのはこれらです。

machi: そうなんですね。今年はこの痛みを解消したいという背景でATDDに取り組んだということですね。 QA内でもATDDという言葉がちょっと話題になったのを覚えているんですけど、いつ頃取り組みを始めたんでしたっけ?

Y: 昨年の12月から話を進めてました。 QAとしては、再発防止や効率化などの観点から、前向きに検討をしていました。 ただ、E2E自動テストを書き始めるとしても、どこから書いていくかなど、悩ましい点もありました。

machi: どこからE2E自動テストを書いていくかは、プロジェクトの状況などによって変わりそうで難しそうだなあという個人的な思いがあるのですが、12月に話して、翌年から開始できるスピード感で進められたんですか? また、ATDDを採用する決め手は何かあったんですか?

Y: チームとしてATDDを本格稼働し始めたのは、翌年にいきなりというわけではなくて、3月からです。なので、これまで半年くらいはATDDを実施したことになりますね。

プロジェクトの状況によって変わる部分はありましたが、最終的にはスプリント毎に実装される機能に対して、並行してE2E自動テストを書いていくことになりました。 ATDD採用の決め手としては、情報の鮮度という観点があります。 実装と並行してE2E自動テストを書いていくことで、情報が新鮮な状態で開発者とのコミュニケーションができると感じています。

machi: 情報の鮮度というのは、実装中にコミュニケーションが取れ、かつ、そのタスクに対してアプローチができるということですよね。 情報が不確定な仕様や実装方針などに対してリアルタイムでコミュニケーションを取ることで時間のロスがなくなる、というのがATDDを導入する決め手になったんですね。

導入直後に気にしていたこと

machi: 新しいことを始める時って慎重になってしまうとは思うんですけど、何か気にしていたことがあれば教えて欲しいです。

Y: ATDDの活動をスプリントに組み込むことになるので、この活動自体が全体の遅延を引き起こさないか気にしていました。

技術面とプロセス面で考えたんです。 技術面でいうと、テストを書いているといろいろなテストを書きたくなってボリュームが増えがちですが、コンパクトなテストにするため、受け入れ条件に対してのみE2E自動テストを書くことに決めました。 プロセス面では、スプリント内の1チケットからE2E自動テストを書いて、徐々に対象にするチケットを増やしていくことで、スプリントのスピードに乗せられるかを見定めました。

あとは、開発を進めるうちにSystem Specとの重複はしないか?みたいなところも気になりはじめました。

というように、スタート時の懸念はありつつも、活動をしているうちに、棲み分けもできて、E2E自動テストだけではなく、単体テストも充足させることができました。

machi: テストのスコープを分ける、責務を分けるといった感じかなーと想像したのですが、そんな感じですか?

Y: 年末調整機能の成果物はCSVファイルで、インプットに対してアウトプットがあるんです。 ユーザーが操作した一連の流れはE2E自動テストで実装できるけど、CSVファイルの1項目を確認するようなことは単体テストで確認できるよね?みたいな感じですね。 カッチリ明確に決めているわけじゃなくて、実装状況にもよりますし、場合によってはE2E自動テストで巻き取るみたいなこともあります。

技術面での検討はどう考えたの?

machi: そもそもの質問になってしまうんですけど、ATDD以外にも施策の候補はあったと思うんです。 その中でATDDを選択するにあたり、技術面での検討はどう行なわれたのか?を聞いてみたいです。

Y: 「導入することによって開発のいままでのスタイルを大幅に変更させない」というのが考慮のポイントでした。 新しいことをやるにはストレスがかかるし、一気に始めたというわけではなくて、少しずつ提案の形が変わっていきましたね。 技術レイヤーとしてはプロダクトと同じRubyを選択することで、新しいことを覚える必要がなく、開発とQAの技術領域をまたげるため、会話がスムーズになりますね。

今、現在どうなの?

machi: なるほど、いろいろ聞けてよかったです。 今かなりいいイメージを持って活動に取り組めているんだなという印象を受けました。

Y: 半年実施してみて、開発速度への影響はあったものの、品質担保の責務という点ではQAだけがやるのではなく、開発者も一緒にやっていこう!という認識が醸成されたと思います。

テストの実装が間に合わなかったこともあったけど、 「それはQAのタスクでしょ」という話から「いや、QAだけのタスクじゃなくない?」という感じにチームの考えが変化していきました。

今回の活動によってリグレッションテストはほぼ全機能存在している状態になりました。 手動でのテストを全くしていないわけではなくて、自動テストではできないことを確認しています。「ボタン押しにくいよね」や「表示変だよね」などは実際に手で動かして確認しています。また、PDFの確認は手動テストに振り切っていたりしますし、E2E自動テストを実装するのが難しい部分は割り切っていますね。 柔軟にテストのアプローチを変更できたり、開発者も巻き込んでテストについて考えていける状態を作れたのが、ATDDを導入して得た思わぬ収穫だったと思います。

今後はどうなるの?

machi: 最後に、今後を考えると、年末調整機能の開発は続いていくし、このATDDの活動も続いていくと思うのですが、新たに加えていくことなどはありますか?

Y: 引き続き来年も継続してやっていく予定です。 これからリリース後もテストを増強していく予定ですが、今のところスコープを変えるとか、そういった話はないかなあ。

自動テストってよく増えすぎて削減できないとかあるじゃないですか、 もしそうなったら、チーム内のコミュニケーションで「これここにあります」みたいなやり取りをしつつ削減していくのかなと思います。

まとめ

ATDDの導入は外から見ても割とスムーズに見えていたのを記憶しています。 それなりの議論はあったのだろうとは思いますが、導入検討から立ち上がりまで早かったし、別のGitHubリポジトリにあったE2E自動テストを参考に環境の基盤が整えられていたこともスムーズな立ち上がりの要因と言えそうでした。 明確な分水嶺を設定して、スコープ分けをするのではなく、チーム全体で適宜判断をしながらプロダクト自体の開発と並行してE2E自動テストの実装がされていることは理想的な状態だなと思いました。 これは、大々的に導入を宣言して一斉に取り掛かった活動ではなく、徐々に活動が浸透した結果だと思います。

別のプロダクトを担当している身としては、ATDDだけに関わらず徐々に活動を浸透させていくということが重要だし、見習いたいと思いました。

We are Hiring !

最後まで記事を読んでいただき、ありがとうございました。 SmartHRのQAに興味を持っていただけましたら、下記の採用サイトからエントリーいただけますと幸いです。 カジュアル面談も実施しておりますので、選考に進む前に気になることがありましたらぜひ、気軽に聞きにきていただけたら嬉しいです。 みなさまのご応募お待ちしております!

hello-world.smarthr.co.jp

www.wantedly.com