DevOpsとマイクロサービス時代のQA: 高品質なソフトウェアを目指して

品質向上への第一歩：良い状態の定義から始めよう

https://youtu.be/3iVkm-pT_Ik

学び直しを目的に、「全社的品質管理推進のための管理者スタッフの新QC七つ道具」を読んでいます。その中に、「良い状態を明らかにして、その方向へ改善しよう」という記述がありました。

DevOpsを前提に、マイクロサービス化された環境でのQAに関して多くの課題を抱えています。どうすれば品質を向上させることができるのか、深く考えています。

この段階で「良い状態」とは何かを定義したいと考えていますが、知見や経験がまだ十分でないため、皆さんの意見を伺いながらこの定義を更新していきたいと思います。遠慮なくご意見をお寄せください。

品質の解釈：マイクロサービスとDevOpsの文脈で

「品質が良い」とは、どういう状態を指すのでしょうか？この質問に対して、即答するのは難しいですよね。なぜなら、「品質」という言葉の範囲が広く、企業や組織、個人によってその定義は大きく異なるからです。

DevOpsを前提に、マイクロサービス化された環境での「良い品質」の状態をどのように定義すれば良いのか、そしてその理想的な状態にどう向かっていけばいいのかを考えます。

このテーマを軸に、今後しばらくインターネット上でコンテンツを発信していく予定です。

免責

• 現職でそこまでインフラに関しては関わっていないので、インフラの定義は割愛します。
• 同様にSRE領域（信頼性）も
• アプリケーション側のQAという前提です

技術的観点

これらの基準や目標は定期的に見直し、プロジェクトの進行や技術の進化に合わせて更新するべきです。

要件（ディスカバリー）

• 要件定義が記述されており、エンジニア、デザイナー、ビジネス関係者、QAがレビューを行い、共通の合意が得られている。
• 要件定義を基に、ユーザーストーリーを作成することができる。
• ユーザーストーリーがビジネス価値とユーザーの視点を反映していること。

設計

• UMLを使用して最低限のドキュメントを作成している。
• クラス図があれば望ましい。
• 可能であればアクティビティ図もあると良い。
• APIが複雑に絡む場合は、シーケンス図が有効である。
• SwaggerやBackstageなどを用いてAPI設計が行われている。
• APIの設計がRESTful原則に従っているか、またはGraphQLの設計ガイドラインに準拠しているかを確認する
  • パラメータの定義がなされている。
  • 出力の定義がなされている。
  • エラーが定義されている（4xxごとに明確にされている）。
  • ※GraphQLを使用する場合はGraphQLの設計ガイドラインに準拠する

ユニットテスト

• C1カバレッジ（ブランチカバレッジ）が80%以上である。
  • プロジェクトで適切に目標を立てること
  • 80%は目安
• プロダクトの規模によっては、少し低い値でも許容される場合がある。
• ユニットテストのカバレッジが80%を超えると、デグレードが少なくなり、保守性が向上する。

静的解析

前提

• 製品固有の紹介を避けたかったが、Sonar Qubeの利用を前提とする。
• マイクロサービスを前提とすると、プロダクトごとに言語が異なるため。
• 品質特性の中で、セキュリティと保守性に関連する項目に着目する。
  ※他の静的解析ツールも利用可能であり、プロジェクトのニーズや技術スタックに応じて選択するべき

基準

• BugsはA評価。
• VulnerabilitiesはA評価。各言語やフレームワーク固有のセキュリティ系静的解析ツールに従う。
• Security HotspotはA評価。
• Code SmellsはA評価。
• 重複率は10%以下。
  • この基準はまだ最終決定していない。
• サイクロマティック複雑度は15以下。

アーキテクチャ

• クリーンアーキテクチャなど、現代的なアーキテクチャを採用する。
  • これに深く関わっていないため、定義が困難。

※アーキテクチャの選定はプロジェクトの要件や目的に応じて行われるべきであり、適切なトレードオフを理解することが重要

API

• パラメータ単位での同値分割・境界値分析を用いたテストケースの作成。
• 必要に応じて、他のテスト技法も適用する。
• すべてのエラーステータスに対するテストケースを作成する。
• アウトプットも項目単位で、型と値の整合性についてテストする。

CI/CD

• CI/CDが正常に機能している。
• デプロイ時間は10分以内である。
  • プロジェクトのニーズに応じてデプロイ時間の目標を設定する

テスト

概要

• テスト活動はテストピラミッドを参考に構築されていることを確認する。

API統合テスト

• 実際のサービスとの統合環境でモックを使用せずにテストを実行する。
• API関連のセクションで挙げたテスト要件を、統合テストにて確認する。
• テスト実行時間が長い場合は、プルリクエストごとのテストではなく、テスト環境での定期実行を検討する。

コンポーネントテスト

• 同値分割や境界値分析を用いて、項目単位でテストケースを作成する。
• 必要に応じて他のテスト技法を併用する。

システムテスト（ユーザーシナリオテスト）

• 受け入れ基準を満たすためのユーザーシナリオテストが行われていること。
• ユーザーシナリオを基にしたエンドツーエンド（E2E）テストが適切に実施されていること。
• エンドツーエンド（E2E）テストの過剰な実施には注意し、必要最小限に留める。
• フィーチャーフラグを利用する機能については、フィーチャーフラグのON/OFF状態を考慮したテストパターンでカバーする。

品質特性・非機能要件

機能適合性

• 上述した基準に沿っている。

使用性

• 使用性の評価は現在模索中であり、デザイナー、要件定義を行った人、QAが協力して品質を確認中。

保守性

• ユニットテストのカバレッジはC1カバレッジで80%以上を目標とする。
• 静的解析の結果はAランクであること。

性能効率性

• 以下のテストを実施する
  • ストレステスト
  • スケーラビリティテスト
  • エンデュランステスト
  • キャパシティテスト
  • レスポンシブネステスト
  • スパイクテスト
  • ボリュームテスト
• 性能に関わるメトリクスを監視できるようにする

信頼性

• 信頼性はSRE(Site Reliability Engineering)の範囲内であり、ここでは詳細な説明は省略。
• サービスレベル契約(SLA)を明確に定義し、これを守ること。
• Datadogなどの監視ツールを使用してSLAの継続的な遵守を保証する。

セキュリティ

• 静的解析（Sonar Qubeを使用）でセキュリティ関連の判定がAであること。
  • Vulnerabilities：A
  • Securituy Hotspot：A
• ペネトレーションテストにて「緊急」または「重要」と評価される不具合が存在しないこと。警告レベルの問題にも対応することが望ましい。

移行性

• 移行が必要な場合、移行計画を事前に策定する。
• データ移行はAPIを通じて行い、データの整合性を保証する。

互換性

• マイクロサービスアーキテクチャを採用しているため、互換性は基本的に保証されている。

開発手法

• スクラムを採用しており、DevOpsの原則に従っています。毎日のリリースを実現している点は特に評価される。

テストマネジメント

大規模プロジェクトの場合

• IEEE29119:2021に基づくテスト計画が整備されている。
• テストに関連する情報はすべてのステークホルダーと共有されている。
• テスト関連の見積もりは適切なタイミングで行われる。
• テスト環境とテストデータの定義が明確に行われている。
• 受け入れ基準とリスクが明確化され、テスト条件に落とし込まれている。
• リスクベースドテストが採用されている。
• プロジェクトの規模に応じて、テストの進捗を追跡するためのバーンダウンチャートとバグ収束曲線が作成される。

リリース

• ビッグバンリリースは避けられ、フィーチャーフラグを用いて本番環境へのリリースとビジネスリリースのタイミングを分離している。

Four Keys Metrics

• 品質が高い状態を保ちつつ生産性も考慮されており、ビジネスニーズに迅速に対応できる体制が整っている。
• デプロイ頻度：1日あたり数回。
• リードタイム：1時間以内。
• MTTR（平均復旧時間）：1時間以内。
• 変更時の不具合率：0%〜15%。

メトリクス

• メトリクスを収集し、テストプロセスの継続的な改善に活用している。

チームとコラボレーション

• 心理的安全性が高まる環境を維持する。
• 部門や役職を超えたオープンなコミュニケーションを促進する。

文化とマインドセット

• 学習を中心とした文化を育む（例: カオスエンジニアリングの実践）。
• バグや問題から学習する環境を整える（ポストモーテムの定期的な実施）。

教育とトレーニング

• JSTQBのファウンデーションレベルおよびアドバンスレベルの資格取得を推奨する。
• ペアテスト、ペアプログラミングなど、共同作業を通じて知識の共有とスキル向上を図る。

測定とフィードバック

以下の指標を収集し、スプリントレトロスペクティブで評価し、次のスプリントの目標設定に活用する。

• ユニットテストのカバレッジ
• 静的解析の結果
• ペネトレーションテストの結果
• 性能テストの結果
• 信頼性テストの結果
• 各テスト活動の成果