DevOpsにおけるQAプロセス
はじめに
DevOpsにおけるQA(品質保証)の役割とは?で、QAの役割を書きました。
今回は自身が携わるチームに導入しているQAプロセスについて書きます。
※私がみているチームにおいて、一部ツールは導入準備中なのであるべき姿を記載しています。
前提
- スクラムを導入している
- 定量指標がある
- Sonar Qubeなどの静的解析ツール
- OWASP ZAPなどの脆弱性診断ツール
- Datadogなどのモニタリング(サーバ監視&分析)ツール
- カバレッジ
- Findy TeamsなどのFour Keys計測ツール
※Four Keys計測ツールは未導入であり、導入後に記事化します。
なぜスクラムを導入するのか
スクラムは1週間とか2週間の間隔でスプリント(イテレーション)を行います。
スプリント開始時にスプリント計画を練り、スプリント終了時にレトロスペクティブ(振り返り)を実施します。
レトロスペクティブでは、スプリントを振り返り「どうしたらもっと良くできるか」を検討します。その時に定量指標を基に議論し、プロダクトバックログを作成します。
参考 定時で帰らせるためのスクラムマネジメント 〜スクラム定義〜
なぜ定量指標を使うのか
振り返りをするときに、「何が良くて」「何が悪いか」がわからないと議論が集約しなかったり、空中戦になります。
例えば
- 「カバレッジが前回80%以上あったのに75%になったから、改善しよう」という提案があれば
- 「テストコードの見直し」というプロダクトバックログを作成することができます。
- 他に「OWASP ZAPで緊急(最上級の指摘)が5件あるから対応しないと」というのが別にあれば
- 「OWASP ZAPの緊急は最優先とする」という定義があれば
- 「テストカバレッジよりもOWASP ZAPの緊急対応を優先しよう」
- と優先順位づけができます。
DevOpsにおけるQAプロセス
概要
プロセス
スクラムをベースとすると下記のようにシンプルになります。
Sonar Qubeなどの静的解説ツールやOWASP ZAPなどの脆弱性診断ツール、DatadogやNewRericなどで計測したメトリクスなどで基準を超えたものがあれば、スプリント終了時に行われるレトロスペクティブのインプットにして振り返りを行い、次のスプリント計画に折り込みます。
基準
このときに、何をもって異常とし対応するかの基準を事前に決めておくと良いです。
基準はスクラムチーム毎に状況が異なるので、チームメンバーと議論して決めましょう。
保守性・セキュリティ・信頼性の3つに分けて基準を決めています。あれこれたくさん書いていますが、書いている内容は似通っています。似ている=プロセスがシンプルになっているということなので、浸透しやすいのではないでしょうか?
注意
もちろん数字が全てではありません。数値が低くなった時に「なぜ、数値が低くなったのだろう?」という疑問をチームで持ち、継続的に改善アクションを行うことが重要です。
仮に数字が悪くても合理的な理由があれば許容しますし、そもそもその数字になる基準を見直すべきなのかもしれません。
保守性
レトロスペクティブで(できれば日常的に)確認することは下記の通りです。
- C1(条件網羅)カバレッジ
- Reliability(ソースコードバグ)
- Codesmells(バグの兆候)
- Cyclomatic Complexity(サイクロマティック複雑度)
C1(条件網羅)カバレッジ基準例
バックエンドカバレッジ基準 | アクション | 備考 |
---|---|---|
80%以上 | 問題なし | |
下降トレンド、80%以下 | プロダクトバックログ化 | 修正する優先度はプロダクトオーナーを中心にチームで決める |
70%以下 | スプリントバックログ化 | 次のスプリントで修正する |
※具体的に数値はチーム内で決めてください。チームごとに異なります。 |
フロントエンドカバレッジ基準 | アクション | 備考 |
---|---|---|
60%以上 | 問題なし | |
下降トレンド、60%以下 | プロダクトバックログ化 | 修正する優先度はプロダクトオーナーを中心にチームで決める |
50%以下 | スプリントバックログ化 | 次のスプリントで修正する |
※具体的に数値はチーム内で決めてください。チームごとに異なります。 | ||
※フロントエンドの基準に関してはカバレッジを追うのが正しいか試行錯誤中です |
ソースコード品質(Sonar Qube / Reliability)基準例
SonarQubeスコア | アクション | 備考 |
---|---|---|
A | 問題なし | |
B | プロダクトバックログ化 | 修正する優先度はプロダクトオーナーを中心にチームで決める |
C, D, E | スプリントバックログ化 | 次のスプリントで修正する |
※具体的に数値はチーム内で決めてください。チームごとに異なります。 |
ソースコード品質(Sonar Qube / Codesmells)基準例
SonarQubeスコア | アクション | 備考 |
---|---|---|
A | 問題なし | |
B | プロダクトバックログ化 | 修正する優先度はプロダクトオーナーを中心にチームで決める |
C, D, E | スプリントバックログ化 | 次のスプリントで修正する |
※具体的に数値はチーム内で決めてください。チームごとに異なります。 |
ソースコード品質(Sonar Qube / Cyclomatic Complexity)基準例
SonarQubeスコア | アクション | 備考 |
---|---|---|
15未満 | 問題なし | |
15以上 | プロダクトバックログ化 | 修正する優先度はプロダクトオーナーを中心にチームで決める |
※具体的に数値はチーム内で決めてください。チームごとに異なります。 |
セキュリティ
レトロスペクティブで(できれば日常的に)確認することは下記の通りです。
- OWASP ZAPを確認
- Sonar QubeのVulnerabilities, Security Hotspotsを確認
脆弱性診断(OWASP ZAP)基準
OWASP ZAPスコア | アクション | 備考 |
---|---|---|
A | 問題なし | |
B | プロダクトバックログ化 | 修正する優先度はプロダクトオーナーを中心にチームで決める |
C, D, E | スプリントバックログ化 | 次のスプリントで修正する |
※具体的に数値はチーム内で決めてください。チームごとに異なります。 |
セキュアコード(Sonar Qube / Vulnerabilities, Security)基準
SonarQubeスコア | アクション | 備考 |
---|---|---|
A | 問題なし | |
B | プロダクトバックログ化 | 修正する優先度はプロダクトオーナーを中心にチームで決める |
C, D, E | スプリントバックログ化 | 次のスプリントで修正する |
※具体的に数値はチーム内で決めてください。チームごとに異なります。 |
信頼性と性能効率性
レトロスペクティブで(できれば日常的に)確認することは下記の通りです。
SLAに準拠する
SLA | アクション | 備考 |
---|---|---|
APIの実行速度が1秒以下 | 問題なし | |
APIの実行速度が1秒以上、2秒以下 | プロダクトバックログ化 | 修正する優先度はプロダクトオーナーを中心にチームで決める |
APIの実行速度が2秒以上(SLAに抵触) | スプリントバックログ化 | 次のSprintで修正する |
※具体的に数値はチーム内で決めてください。チームごとに異なります。 |
Discussion