こんにちは！hacomono QAのモーリーこと森島です。
本記事ではプロダクトの内部品質の計測と活用をテーマにお届けします。
はじめに
hacomonoでは、QAエンジニアが取り組む品質保証の活動として製品プロセス・外部品質・利用時の品質の評価・改善を実施してきました。
hacomonoも年月を重ねさまざまな機能を有するようになり、全体を把握していくことも難しいボリュームになってきました。時には想定しない影響により欠陥を市場に流出させてしまうこともありお客様へも、社内に対しても申し訳ない気持ちになる場面もあります。
「想定しない影響」という点につき、プロダクト内部(ここではプログラムコード)の複雑性が高くなっているという肌感はあるものの、実際はどのくらいなのか？という現在地を知るために、今回は内部品質と保守性にフォーカスすることになりました。
内部品質と保守性
内部品質の考え方・定義は、国際規格であるISO/IEC 25000(SQuaRE)シリーズ、日本産業規格であるJIS X 25000 システム及びソフトウェア製品の品質要求及び評価シリーズを参考にしております。
ソフトウェア製品の品質である品質特性は、「利用時の品質」と「製品品質」に分類でき、さらに「製品品質」は、外部品質と内部品質に分類できます。
外部品質はシステムの振る舞いをソフトウェア製品が可能にする度合い、内部品質はソフトウェア製品の静的属性の集まり(仕様書、設計書、ソースコードなど)がニーズを満たす度合いに影響します。
JIS X 250010の品質モデル部門では、製品品質を下記のように8つの製品品質特性と各特性を構成する副特性の集合から構成されていると規定しています。
引用：JIS X 25010：2013, システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル
今回は「プロダクトの複雑性」から端を発していますが、目的は利用時の品質を高めながら安心・安全なプロダクトを提供していくことが目的であるため、品質特性のうち保守性を測定することにしました。
保守性の評価
保守性を評価する計測対象はたくさんありますが、今回の計測には「継続できること」と「計測することが有効に働くか確かめること」を重視しています。頑張ってたくさんの種類を計測した結果、以下のような課題が発生することを避けたいと考えているからです。
- 計測対象の理解が進まず何を示しているのかわからない
- 一度きりの活動になり点の情報しか集まらない
このような状態では得られる情報が少なくなってしまいます。少なくともひとつの計測内容を理解した上で、継続的に見ていくことでメトリクスと事象の間に関連性があることの気づきが得られ、それに対して何かしらアクションを検討できることを目指すためです。
また計測するためにコストがかかるのも始める段階で挫折してしまうので、すでに計測されているが活用が進んでいないメトリクスを利用していくことにしました。
今回はすでに定期的に測定されているUnit Testなどのテストカバレッジを計測対象としました。
計測対象を決めるために他にもいくつかのメトリクスの候補を集めてみましたが、前述の通り扱いきれない可能性があるため採用しませんでした。
- 循環的複雑度：条件構造からソースコードの複雑さを表す
- 凝集度：クラス・モジュールが単一の目的のみを有しているかどうかを表す尺度
- クラス間の結合度：クラスやパッケージ間の依存度・結びつきの強さ
- ABCサイズ：代入(A)、メソッド呼び出し等(B)、条件式(C)の数を数え、それぞれの2乗の和の平方根で求めた指標
- コードの行数：コード行数、行数が多いと可読性・解析性・試験性が低下する
- ネスト数：条件文などにより多重構造化されている数
- 一致度：コピーされたモジュール・ファイルがあるか(単なるコピペ=設計されていない箇所を検出)
計測対象としたメトリクスでは思うような成果が得られなかった場合は、別のメトリクスも計測対象に含めるなどを検討します。
カバレッジの計測と活用
hacomonoのバックエンドはRuby on Railsを利用しており、SimpleCovによりカバレッジレポートを出力しています。以前その取り組みを紹介したブログ記事はこちらです：コードカバレッジを測定してみた
この記事から少し変わっている点としては、Unit TestやRequest Testが完了するとPull Requestにカバレッジレポートのサマリがコメントされるようになりました。CIのArtifactをDLして確認する手間が減ったので、以前よりはカバレッジが確認しやすい状況です。
フロントエンドはVue.jsを利用しており、Vitestによりカバレッジレポートを出力しています(一部)。出力したカバレッジレポートは、Pull Requestでテストが実行されるとCIのArtifactとしてアップロードされます。こちらはまだコメントされるようになっていないので、改善の余地があります。
他にもまだ足りない部分は補強していき、より確認がしやすく推移でも見やすい環境を整えていくことも並行して進めていきますが、いまある情報を活用することをまずやっていきます。
これらカバレッジレポートから得られた情報を継続的に確認することで何かしらの発見につながることを期待していますが、カバレッジを改善させることは目的とはしていません。
QAチームからは品質メトリクス(今回はテストカバレッジ)を継続的に見る習慣を身につけること、品質メトリクスをもとにプロダクトチームと新たな視点での対話が生まれることを期待しています。
後者は抽象的でわかりづらいですが、一例として、開発着手前に修正対象箇所のカバレッジが低いということがわかったとき開発者とQAで一緒に既存機能の仕様理解を進めることを提案したり、カバレッジが高い場合は重点的に確認すべき箇所はどこなのか一緒に考えてみたり、など場合によってアプローチは様々あり得るので、まずはプロダクトチームで一緒に見るというところからどんな発見や行動が発生するのかをQAチームで事例を集めていきたいと思います。
カバレッジの基準は、Google Testing Blogの「Code Coverage Best Practices」を参考に、以下の暫定的な値を設定しています。
- 60%：許容範囲
- 75%：推奨範囲
- 90%：模範的
ただし、これらは一般的なガイドラインであり、絶対値としては利用しないことを前提としています。
最後に
内部品質の計測とこれからの活動について書きましたがいかがでしたでしょうか。
まだ具体的な成果として現れてはいませんので、半年後くらいにどんな結果になったかまたレポートを書きたいと思います。
hacomono QAでは内部品質の計測にとどまらず様々な取り組みをおこない、あらゆる側面から品質への貢献を試みています。
積極的に採用していますのでhacomono QAチームが気になった方はお気軽にお問い合わせください、まずはカジュアル面談でお会いしましょう。
hacomonoは先日資金調達について発表を行い、採用イベントを多数実施しています！
株式会社hacomonoでは一緒に働く仲間を募集しています。
エンジニア採用サイトや採用ウィッシュリストもぜひご覧ください！
