不具合撲滅運動（続々）

イントロ

前回記事「不具合撲滅運動（続）」、前々回記事「不具合撲滅運動」に続き、続々です。とうとう不具合撲滅がシリーズ化しつつありますｗ
カッコ書きのところ、次は何にしようか思案中ですが、今回は続々ってことで進めます。

この一連の記事の基本コンセプトは「不具合を撲滅したい」これにつきます。
（ソフトウェア開発における・・・です）

では本題

今回はちょっと、また仕事で熱くなってきてる事もあり、品質保証（QA）について、自身の知識の強化・備忘の意味も込めて記録として残そうと思います。
まずは品質保証（QA）という言葉の定義から再度学びなおしをし、システム開発においてどういった点にこだわりを持つことで品質を保証していくべきなのかについて、まとめたいと思います（最後は用語の列挙になってしまいました）。

品質保証（QA）って何？

まずはQ&A（Question and Answer）とごっちゃになるので、略称を書いておきます。
「Quality Assurance」の頭文字を取って「QA」です。

英単語が解ったところで納得感はありません。では、品質保証ってなんなんだって話ですが、よく聞く（ググればぶち当たる）団体に、ISTQB（International Software Testing Qualifications Board、国際ソフトウェアテスト資格認定委員会）ってのがあって、そこでPRODUCTに関して倫理規定（Code of Ethics）というものが定義されていて、これが程よい感じのテキストなんで、ちょっと紹介しますと

PRODUCT - Certified software testers shall ensure that the deliverables they provide (on the products and systems they test) meet the highest professional standards possible.

これまた英語。。。なので、DeepL翻訳くんにちょいと出張ってもらって

製品 - 認定ソフトウェアテスターは、提供する成果物（テストする製品およびシステムに関するもの）が、可能な限り最高の専門的基準を満たすことを保証するものとします。

ここに書かれている言葉がなんとなくしっくりきませんか？
ちょっと表現が小難しめな抽象表現なので、ひょっとすると「可能な限り～」とか「最高の～基準を満たす」なんてところに引っかかったりする方もいるかもですね。

なので、あと、もう一つ紹介しておくと
「納得感の共有」
って言葉で示されている方もいます。

これらから、作り手と使い手の間で、可能な限りの専門的な基準を満たしていく活動を通して、そこから生まれる納得感の共有を醸成することが、品質保証（QA）のゴールだと理解すると、なんとなく腑に落ちるような気がしているのは私だけでしょうか。

品質保証を行うにあたり、どういった活動をすべき？

ここ（この連載記事）では、テストが全てです。なのでテスト品質を上げていく点に尽きます。

（品質の作り込みは上流から、という考えもありますが、あまり広く語っても切りが無いのでここでは毎度テスト工程に限定しています。また出荷後のトレース部分などへのアプローチも当然付き纏いますが、そこも割愛）

さきほど紹介した言葉をちりばめつつ、品質保証に関する活動内容を表現すると

• 可能な限り最高の専門的基準を満たされていることの証明
  • 品質基準を設定し、定量的な目標を定め、測定や評価ができる状態が良いです
  • テスト計画を作り、そのとおり実施していくサイクルを作りだすことで、一定の品質を担保できる状態が良いです
• 納得感を得るためのテストケースの作成と実施
  • テストカバレッジは適切かどうか
  • テストの実行環境や前提条件が明確かどうか
  • レビューの実施や指摘事項の傾向分析、見直しが適切に行われているかどうか
  • 実施記録を保持できるかどうか
  • エラー検出率は算出可能かどうか
  • テスト実行時間（コスト）が算出可能かどうか
  • 作成のプロセスが妥当かどうかなども大事
• 納得感を共有できるようなテスト結果
  • 品質基準を満たしたか（合致したか）どうかを分析する
  • エラー発生パターン（傾向）の分析を行っているかどうか
  • テストケースの再作成や再実施の要否について検討を行っているかどうか

といった感じでしょうか。

品質保証のツール

ツール（よくある７つ道具的なあれ）は割愛、まずはミクロなところ、概念的なところから思いつくものを列挙

• 定量的な指標（メトリクス）を用いる
  • 何かと数値化したがる
  • 件数、内訳
    • 基本的な数値項目
  • 総数
    • 何かしらの項目に対する合算値
    • カテゴリ別に区分けされた数値の合算値
    • 経過時間（日、週、月単位など）あたりの合算値
  • 割合
    • 合算値に占める、とある数値のパーセンテージ
  • 閾値（以上／未満）
    • 基準
    • 過去の実績
    • 不具合発見数
      • テストフェーズによっては以上／未満を切り分けて管理したりする
      • 単体テストではｘ件以上
      • 結合テストではｘ件未満（超えたら分析＆単体テストやり直しなど）
      • システムテストではさらに厳しいｘ件未満としたりといった形
  • etc
    • RASIS（評価指標の一つで、「信頼性」「可用性」「保守性」「保全性」「安全性」の5項目）
    • SLA（提供側と利用者間のサービスレベル（定義、範囲、内容、達成目標等）に関する合意）
    • SLO（サービスレベル（サービス品質）に関する目標・評価基準の定め）
    • 言い出したら切りがないから、割愛する
• PDCAを回す
  • ベタですが、テスト品質を作り上げる上でもやっぱり大事
  • Plan（計画）
    • 品質の基準を策定する（見直す）
    • 既に存在する基準を用いる
  • Do（実行）
    • 各種テストを実施する
  • Check（評価）
    • 基準に対して、テスト結果がどうだったか分析する
    • テストの実施に至るプロセスにカイゼンの余地が無いか確認する
    • カイゼンについては、テスト作業は膨れる一方なので必ず自動化の余地を検討するべき
  • Action（カイゼン）
    • 品質低下リスクを捉え、原因を突き詰め、次に活かす
    • カイゼン策の適用を画策、実行する
• QCDのQを第一に考える
  • C、Dは後回し...（にしてよい、わけもないがまぁここでは品質にこだわる意思表示）
  • 納得感が得られるのかどうか
  • コスパを感じてもらえるかどうか
  • そういった感性的なものもなるべく定性的でなく、定量的に示す

次により良いテストの実施に向け、あると良いものを列挙

前工程から流れた来た資料、それをベースにテストの計画を行う際に押さえておきたいポイントを列挙しました。

計画に基づき準備されているべきものが揃っているか確認する

• インプット資料
  • 要件定義
    • 機能要件
    • 性能（非機能）要件
      • メリット・デメリット
      • 松＞竹＞梅
      • ここも深ぼらない。。。割愛。
  • 基本（外部）設計
    • 機能一覧
    • 画面一覧、画面遷移図
    • 画面・帳票仕様（デザイン）
    • バッチ処理仕様
    • 外部IF仕様
    • DB仕様
    • 業務フロー図
    • システム構成図
    • アーキテクチャ
    • レビュー記録
  • 詳細（内部）設計
    • クラス図、シーケンス図
    • モジュール構成図
    • ビジネスロジック仕様
    • 共通仕様
    • API仕様
    • レビュー記録

テストフェーズにおいて品質を高める上で、計画を練るときのファクター

• テスト計画
  • 目的・対象範囲、実施方法（テストの種類）、環境設定、スケジュールの作成と監視
  • リソース品質の確認
    • ハードウェア、ソフトウェア、データなど
    • 調達や作成コスト
  • テストの種類
    • テスト技法
      • これは「続」を見て欲しいです。今回はフェーズごとの切り分け（テスト段階）を列挙していく
    • 単体テスト
      • 機能・画面・モジュールといった単位の動作検証
      • 詳細設計の品質保証
      • 開発者が実施する手段であることが多い
      • 開発初期から実施していくもの
      • 後続フェーズでの不具合発生の抑止となるため、目標不具合発見件数・率は「ｘ以上」で定めたりする
    • 結合テスト
      • 機能どうしやモジュール間、その他システムとの連動による動作検証
      • 基本設計の品質保証
    • システムテスト
      • 運用を想定したシナリオに基づく、システム全体の動作検証、その他システムとの連動テスト
      • システム開発において最終的なテスト作業にあたる
      • 要件定義の品質保証、可用性など（RASIS）の確認
      • ユーザビリティ、アクセシビリティ
      • 全体的な機能テスト、性能テスト、負荷テスト、ロングラン、セキュリティ、リグレッション
    • 受け入れテスト
      • 要件や仕様どおりのものかどうかの確認を目的とした動作検証
      • ユーザーが行うことが多い。UATとも呼ぶ
      • ユーザーが作成したシナリオに基づき、開発側でテストを実施することもある
• テスト環境準備
  • 開発用、検証用、本番用
  • 他システム、外部サービス
  • サンドボックス
• テスト設計
  • テスト仕様書（テンプレートを用いて成果物の品質を一定ラインに揃えるのも大事）
  • テスト観点
  • テストデータ、テストケース
  • 合否判断基準、結果分析記入欄
• テスト実施
  • 実施記録、不具合記録の方法
  • なるべく短い期間（サイクル）で、実施状況をモニタリングできる仕組み
  • バーンダウンチャートの作成、ベロシティの算出
• テスト分析
  • 抜け、漏れ
  • 合否状況、合否判定
  • 不具合傾向
  • 観点カバレッジ
  • テスト密度、バグ密度
  • 欠陥摘出率（DDP）モニタリング
    • とあるテストを開始したときに前工程の不具合が残っていた数（A）
    • そのテスト中に発見した不具合の数（B)

ちょっと、広げ過ぎたので、ここまで。。。単語の意味はググれば概ね出てくるので、やっぱり割愛。

まとめ

品質保証（QA）は「納得感の共有」であることを冒頭で説明しましたが、それを実現するために資料を揃え、テストを計画し、そのとおり実行し、結果分析を行い、目に見えている不具合の改修や、サービスのウィークポイントを特定し、さらなる品質向上施策を実行するといったことを、継続的に繰り返し行っていく活動になります。
ここに書いたようなファクターを拾って作業に組み込むことで品質向上に繋げていきたいなと思っています。

今回は表面的な部分のおさらいになってしまいましたが、個人の活動的に記事に起こしておきたいなぁと思ったところとして、テスト品質を一定ラインに保つためのテンプレート化について触れたいと思ったので、次回はそれで書けたらいいなと今は思っています。

おまけ

ChatGPTに不具合撲滅運動についてちょっと聞いてみたｗ（2023-03-28、ChatGPTとの問答）

なんと、、、第一優先は「不具合撲滅運動」１つ目の記事（不具合分析）と被ってるじゃないかｗｗｗ

※ChatGPTを使った感想ですが、渡せる情報に限界がある（セキュリティリスクの懸念）ので、踏み込んだ回答を得るのは難しい気がします。
品質を作り込むためにもメトリクスの収集を継続し、そこからの分析指標を出した後の数値群（ここまでくるとフィルターかかってるから情報漏洩リスクも低い）から、品質に関する分析コメントを出させるといったことに使えるかもしれませんね。
そういった指標を組織の中で醸成していくのも良いと思います。例えばファンクションポイントとテストケース数（他にも色々ありますが）の因果関係を必ずトレースするとか。

前回に引き続き、今回は続編なので、過去分を貼っておきます。

参考文献