こんにちは！uenonです。
秋も深まり、すっかり日足も短くなりましたが、11月に入り急激に気温が下がり体調が崩れやすいため、皆さまご自愛ください。

気が付けば前回の品質分析の記事からもう1年が経ってしまいました…
各所から「早く続きを書いてくれ！」、「続きが気になるよ～」という声を一回も聞くことはありませんでしたが、今回は前回の続き、「定量分析のデータ収集の方法や、開発者がテスト作成時に注意して欲しいこと」を書いて行きます。

前回の記事が気になる方はここで記載していますのでよかったら見てみてください。
https://codebase.next.inc/2023/qualityanalysis.html

品質分析における定量分析とは？

定量分析といえば、プロジェクトや管理者、または新規開発／改修や、開発言語、業務により指標値は異なりますが、例えば、開発規模(ステップ数)に想定される、指摘件数やテストケース数、欠陥件数が指標値となり基準値より乖離があるかを確認し、システムもしくはプロジェクトとしての妥当性を確認することを指します。

基準値は上記で述べさせていただいた通り、プロジェクト、管理者単位で異なりますが、指標値はどうやって求めるべきかを説明します。

おもな指標値

主に指標値となるのは項目は以下に4つになると思います。
(この項目があればある程度のデータを取得できます。)

• 開発規模(ステップ数)
• テストケース数
• 各工程の指摘件数
• 不具合(欠陥)数

開発規模(ステップ数)

開発基準ついては単純に開発したステップ数をカウントしてもらえばいいです。
※プロジェクト単位でカウントルールが異なります(コメント行、空行を含める含めないなど)

テストケース数

テストケース数は「開発規模」から基準値で算出した件数でテスト仕様書を作成していただければいいです。

各工程の指摘件数

基本的には各工程のレビュー記録からの取得になりますが、プロジェクト毎にフォーマットや記載粒度が異なるため、私の場合はレビュー記録に指摘解析(原因、理由、影響範囲、類似見直し)がなければ、設けるようにしています。各担当者に入力してもらうようにすれば、指摘件数、指摘傾向が見れます。

不具合(欠陥)数

指摘件数と同様にテスト時にNGが出た場合に不具合一覧(欠陥管理表)を設けて、各担当者に入力してもらい、不具合数、不具合傾向が見れるようになります。

以上のデータから算出し指標値と基準値を比較し乖離があるかを確認し、システムもしくはプロジェクトとしての妥当性を確認します。乖離があった場合は原因調査、類似調査を行い、追加打鍵や再打鍵を行い、潜在的な不具合を対策できます。

開発者はレビュー記録表、の指摘に対しての指摘通りに単純に修正しコメントは「指摘通りに対応しました。」だけではなく、こんな原因でここを修正し、影響範囲はここからここまであり、類似があるかないかを意識しながら自分自身で振り返りながら対応していただければと思います。不具合一覧も同様で振り返りながら修正していただければ同じミスが減るかと思います。

最後に

今回は簡単にですが、定量分析のデータ収集の方法や開発者がテスト作成時に注意して欲しいことなどついて説明させていただきましたが、次回は定性分析の実施方法や観点などを書かせていただければと思います。

それでは次回のuenonの活躍にもご期待してください！
See you next time👉