こんにちは。権限管理基盤マイクロサービスを開発するチームでQAエンジニアをしているyukkyです。
freee QA Advent Calendar2023 21日目です。
今日は権限管理基盤マイクロサービスを開発するチームで行っているQA活動について記載します。
権限管理基盤マイクロサービスとは
freeeプロダクトの開発チームが権限管理基盤マイクロサービスを導入することで、きめ細やかで多様なアクセス制御を可能にし、以下の実現を目指しています。
freeeプロダクトのユーザーにとって、簡単かつ安全に安心して権限運用ができる
freeeの開発者にとって、権限制御機能を手軽に安全に導入・運用できる
freeeプロダクトの開発チームにとって、ユーザーにfreeeプロダクト統合体験を素早く提供を可能にし、他の開発にフォーカスできる
チームのエンジニアリングマネージャーである、sentokunさんの記事で詳細の記載があるので、ぜひ御覧ください。 freee の権限管理基盤マイクロサービスの今を語ろう! - freee Developers Hub
権限管理基盤マイクロサービスの特性
権限管理基盤マイクロサービスは、テストを行う上で以下の特性があります。
画面を持たないマイクロサービスであり、APIテストが必要であること
品質を保証すべき相手が「freeeプロダクトのユーザー」以外に「freeeの開発者」も存在すること
導入プロダクト、導入予定プロダクトが増加していること
バグ(freeeではハッピーとも言う)が起きるとクリティカルな問題になりやすいこと
開発エンジニアがテストまで担ってしまうことで開発スピードが落ちないように、 また上記のような特徴もあってQAエンジニアが入ることになりました。
テストの仕方
runnというツールを使用してAPIのテストを行っており、作成されたテストは自動テストとして日々実行されています。 web画面を使用したE2Eテストはfreee全体で盛んに行われていますが、 APIの自動テストはfreeeの中でも珍しいのではないかと思います。
このツールの特徴は「stepAを実行してから、stepAの結果を使用してstepBを実行する」というAPIをチェーンして呼び出すことが可能な点です。 HTTP リクエスト、gRPC リクエストだけでなくDB クエリも叩くこともでき、シナリオをYAMLで書いて、それをもとに操作を自動化してくれます。 また、様々な単位でまとめて実行することや、デバッグ出力も可能です。
desc: メールアドレスとパスワード元にログインすることを確認する runners: req: https://example.com/api/v1 db: mysql://root:mypass@localhost:3306/testdb vars: # 変数を定義できる username: ${TEST_USER} password: ${TEST_PASS} steps: find_user: # DBクエリも叩ける db: query: SELECT * FROM users WHERE name = '{{ vars.username }}' login: req: /login: post: body: application/json: # 「find_user」というstepの結果を利用できる email: "{{ steps.find_user.rows[0].email }}" password: "{{ vars.password }}" # 期待結果確認 test: steps.login.res.status == 200
所属しているチームでも、シナリオの組立自体をYAMLでかけること、gRPC実装におけるサポートが充実している、という理由からrunnを採用しています。
権限管理基盤マイクロサービスにおいてテスト実施とは、テストシナリオの実装を行った上で、適切な環境で実行することです。 テストシナリオの実装ができると同時に自動テストとして実行が可能になります。 他プロダクトのテスト環境で、権限管理基盤マイクロサービスに問題ないことを確認するために、毎日実行することで、いち早くデグレに気づける仕組みを用意できます。
QAチームに求められていること
- 当たり前品質
重篤度の高いバグを防ぐための効果的なテスト設計や観点の整理、プロセス改善を行います。
- 高速フィードバック
上流工程でのフィードバックやテスト実施によって結果的に開発エンジニアへの早いフィードバックを行います。 特に権限管理基盤マイクロサービスでは、スピード感を持ってAPIの自動テストシナリオを書いていく実装スキルや、テストシナリオのメンテナンス、安定したテスト実行が行えるようなプロセス構築スキルが必要です。
上記のようにQAエンジニアとしてだけではなく、テストシナリオ作成のため、ソフトウェアエンジニアとしての側面が必要です。
現在の課題
チームにQAエンジニアがアサインされたものの、 テスト実装のスピードが、開発エンジニアの保守/新規機能のスピードに追いついておらず、 テストフェーズがボトルネックになっている点はまだ変わっていません。
目下の課題と取り組みや予定はこんな感じです。
実装にも、実装内容の正しさを確認する作業にも時間がかかっている
- テストケース記載方法の工夫、効率的な実装や、可読性高くメンテナンスし易いものにすることで、実装する側も確認する側も迷わず取り組めるようにしていきます。
作成したケースをすべてリグレッションテストとしているので、日々テストケースの追加によってテストシナリオが肥大化し、実行にも時間がかかっている
- リグレッションテストとして必要なケースの精査、優先順位付けをしていくことが必要です。 最近ではSEQチーム(自動テストの基盤開発、開発フィードバックサイクルの高速化を目指した組織)にも入ってもらい、 テストシナリオの実装だけではなく、CIの検討なども含めた、E2Eの仕組み部分をより良くすべく協力して推進しています。
テストがうまく動かない場合における「実装不備」なのか「使用ツール(runn)が要因」なのか「バグ」なのか切り分けに時間がかかっている
- ナレッジを蓄積していくことで、早い判断を行えるようにしていきたいです。
今後はテストの網羅性を上げて、導入プロダクト側のテスト自体もより担当範囲を明確かつ、実施しやすいものにしていくことや、 権限管理基盤マイクロサービスのQAエンジニアだけでメンテナンスを含めたテスト管理ができるよう、ナレッジの蓄積をして、 SEQチームと連携してAPIテストの基盤をfreeeQA全体に展開していきたいです。
「いまSEQとしてやっていること」についてharashinさんの記事もあるのでぜひ御覧ください。 https://developers.freee.co.jp/entry/freee-qa-advent-calendar-day1
さいごに
課題いっぱい、やることいっぱい、兎にも角にもやってくぞ!のフェーズですが、 当たり前の品質を確実に安全に届けるべく活動していきます。
明日は、いよいよymty-san が「リグレッションテストの設計にGIHOZ使ってみた」について記事を書いてくれます。お楽しみに〜!