こんにちは！QAエンジニアのark265です。
SmartHR全体のプロダクトを横断的にQA業務を行うチームに所属してます。
QAチームで掲げているミッションの一つである「品質を技術で解決する」
を実現するために日々、より良い品質保証活動ができるよう取り組んでいます。
実施した背景
昨今、お客さまの多様性が高まっている背景と、より高いレベルの品質保証が求められるようになりました。
今回は SmartHR API を対象にした活動をお伝えしていきます。
SmartHR API は基本的に request spec により動作が担保されています。
一方でインフラなど外部要因で影響が発生したり、request spec の不足などで問題が起きることがありました。
そこで、より高いレベルでの品質を保証する手段として、外部からのリクエストによるテストを実施することにしました。
手段の選定
自前で環境から作っていくとコストが高く、導入スピードが遅くなる可能性があるため、
SaaSのプロダクトかつ下表の項目を満たしているかを比較検討しました。
結果として、以下の理由から Assertible でトライすることにしました。
- 要件をすべて満たしている
- プロダクトの操作が直感的で理解度が早かった
- テストがシンプルに実装できる
- ノーコードツールで素早い効果検証が可能
Assertibleのよかったところ
Assertibleの導入してよかった点を紹介していこうと思います。
プロダクト毎に分けてテストを実装できる
Assertibleではプロダクト毎に分けてテストを実装できます。
SmartHRで言えば、SmartHRの基本機能・年末調整機能・従業員サーベイ
ごとにテストを分けて実装できるということです。
登録できるプロダクトの数は契約プランによって異なりますが、
Startup プランでも25個までプロダクトを登録できます。
プロダクト毎に実行環境の設定が細かくできる
各プロダクト設定には複数の環境設定が行えます。
(Production, Staging, Development等)
環境設定ではURLや認証情報、ヘッダ、変数の設定も可能です。
環境ごとにヘッダや変数の設定ができるため、テスト実装時に環境ごとの
差分を意識する必要がなくて便利です。
テストの冪等性を担保しやすい
テストの冪等性を担保するため、テスト実施前に前提となるデータを
作成することがあります。
Assertible では Setups という機能でテストデータをテスト実施前に
都度用意できます。
登録する値が一意でなければエラーになってしまうようなシステムに対しては、 Random data generator という機能があります。
これは変数名を決めて、形式(text、number、UUID、timestamp)と桁数を決めると自動でランダムな値を決めてくれるものです。
事前に API を叩いて、データを作っておかなければならないシステムに対しては http request setup という機能があります。
これは事前に定義した API を実行して、レスポンスの値を変数に入れることができます。
一度作成した setup は同一プロダクト内の他のテストの Setups でも再利用できます。 ただし、Setups で一度に有効にできる setup は10個までという制約があります。
Setups とは異なりますが、テスト実施後の後処理を行うための Teardown という機能も存在しています。
テスト実施時に作成したリソースを削除したり、変更を加えたデータを元に戻したりすることができ、テストの冪等性を担保するのに利用できます。
Assertionが書きやすい
AssertibleではAssertionのタイプが用意されています。
以下のようなタイプに対応していて、記述内容をシンプルに書けます。
- JSON path data
- Json validation
- XPath data(XML/HTML)
- Response header
ドキュメントもしっかりしているので、困ることなく実装できます。
定期実行とアラート通知の設定
プロダクト内に存在するテストを指定して、定期実行(分単位から月単位まで)を行えます。 定期実行のスケジュールは複数作成できるため、頻繁に動かしたいテストと月に一回程度の実行で良いテストを分けて設定することができます。
アラート通知は定期実行してテストが失敗した場合にSlackへの通知をするように設定しました。 他にもmailやzapierでの通知も可能です。
導入してみて
すべてのSmartHR API の正常系パターンを1週間(1日3,4時間作業)という速さで早く実装が完了し、モニタリングが行える環境を作れました。
Assertibleを導入する中で感じたメリット/デメリットをまとめました。
メリット
- シンプルなので、迷うことなく手を動かせ、スピード感を持って実装できた
- レポート機能が優秀で失敗しているものが見やすい
- リクエストのタイムアウト設定がテスト毎に設定できるため、APIのパフォーマンス観点でのテストができる
- 他のケースのSetupやAssertionが流用できるので、テストデータ作成やテストの実装が楽になった
- 定期実行時にテストが失敗した際、次の実行タイミングの結果(pass/fail関わらず)を通知してくれる
デメリット
- Assertibleの制約として、setup(テスト実行の前処理)が10個までなので、複雑な手順があるテストの実装が難しい
- アカウント数が料金体系によって変動するため、メンテナンスする人が限られる
最後に
今回はより早く実装、運用ができるツールを探してAssertibleにたどり着きました。
今後はより複雑なテスト実装やレポートの視認性をあげるなどやりたいことが増えてくるので、
Allure TestOps(クラウド版)などの導入検討もしながら、自前で実装することも視野に入れています。
本活動にあたってマネージャーの muga さんに相談したところ、同じことを課題におもっていたとのことで一緒にAsssertible実装に取り組んでくれました！
We Are Hiring !
最後までお読みいただき、ありがとうございました。
QAチームでは、品質とスピードの両立を実現するために積極的に新しいことに挑戦しています。
SmartHRのQAに興味を持っていただけましたら、下記の採用サイトからエントリーいただけますと幸いです。
みなさまのご応募お待ちしております！
