SRE出身の人間が考える品質保証

はじめに

こんにちは。SEQ(Software Engineering in Quality)チームでQAエンジニアをしているtatsukomです。 freee QA Advent Calendar2023 10日目です。私たちのチームは、現在自動テストの基盤開発、さらには開発フィードバックサイクルの高速化を目指した開発を進めています。 SEQチームの詳細については、以下のスライドをご覧ください。

・10分でわかる Sofware Engineer in Quality(SEQ)チーム - Speaker Deck

私は2023年2月にこのSEQチームに参加しました。それ以前はヤフー株式会社にてSRE (Site Reliability Engineer) として勤めていました。今回は、そんなSRE出身の私が考える品質保証についてお話ししたいと思います。まだ実現はしておらず理想ドリブンの状態ですが、この考え方が皆さまの品質保証の参考になれば幸いです。

そもそもSREとは

SREは、IT 運用におけるソフトウェア・エンジニアリング・アプローチです。SRE チームはソフトウェアツールを使用してシステムの管理、問題解決、および運用タスクの自動化を行います。

引用: SRE とは| Red Hat

簡単に要約すると、SREは以下のような業務を行います。

運用業務のtoil（苦労）を軽減
サービスの可観測性（現在の状態が把握できる能力）を向上
障害やインシデント後のポストモーテム（事後分析）の実施

弊社のSREの取り組みについては下記カテゴリの記事を参照ください。

developers.freee.co.jp

自動テストで担保していること

私たちの会社では、以下の手順でプロダクション環境へのデプロイを行っています。

新規イメージビルドをする
ステージング環境にデプロイする
自動テスト(API・E2E)を実行する
すべてのテストが通ることを確認する
デプロイ後、BugSnagで報告されたエラーを開発者が確認して問題ないか判断する
プロダクション環境へデプロイする

※ BugSnagはアプリケーションのエラー監視のSaaSです

手順3におけるE2Eテストでは、機能が期待通りに動作するかどうかを確認しています（これにより、機能面の品質を保証しています）

以下に、その機能確認の一例を示します。

サインアップ/ログインできる
ファイルボックスにレシートの登録ができる
帳票が作成できる
作成した帳票の閲覧ができる

将来的には、既存の機能面に対する品質保証に加え、非機能面の品質も保証することを私は目指しています。

非機能面の品質が保証できると何が嬉しいのか

非機能面の品質も保証できるようになるとステージング段階でパフォーマンスの劣化を検知し、問題を事前に特定することが可能となります。例えば100人がログインを試みた場合に60人が失敗するといった状態は、良い品質とは言えません。機能的には問題が無いように見えても、N+1問題のようなパフォーマンス面で影響の出る問題を未然に防ぐことができます。さらに、システムの負荷試験を実施した際にユーザ影響について問題ないがあるかどうかの判断材料として利用することもできます。

どうやって評価するか

非機能面の品質を保証していることを確認するための指標として、SLI（Service Level Indicator）やSLO（Service Level Objective）を用います。 SLI/SLOとは以下の通りです。

SLI (Service Level Indicator): サービスの信頼性を測るための指標です。一般的には、機能単位に対して可用性やレイテンシーの面から数値として計測可能なものを割合で設定します。
- 例: 利用者がfreee会計へログインし、HTTPステータスコードが200だったリクエストの割合
SLO (Service Level Objective): SLI に対してどの程度の目標値（％）と期間が良いのかを定義した達成目標です。
- 例: 利用者がfreee会計へログインし、HTTPステータスコードが200として返される割合が99.90%

以下の図は、SLIおよびSLOの具体的な例を表しています。200系（成功）のリクエストと全体のリクエスト（200系と500系（失敗）のリクエストの合計）との比率を算出し、それによりSLOを計算します。この場合、SLOを99.90%に設定していますが、実際の値が99.95%となっているため、SLOを満たしていると言えます（つまり、非機能面の品質が保証されていますと言えます）。