2024年1月22日事例を知る

システムの特徴に応じた品質保証～開発技術を組み合わせたテスト事例と効果～

「品質保証」「バグ密度」といった検索キーワード経由でのINSIGHT TECHへのアクセスは多く、アジャイル開発、DevSecOps、ローコード／ノーコード開発など様々なソフトウェア開発手法が用いられている現在において、「品質」は変わらず関心の高いテーマであることが伺える。
これまでINSIGHT TECHでは、システム品質を考える上で有効な様々な開発技術を紹介してきた。当該記事では、システム開発における品質に関する課題解決の参考となるよう、新しい開発技術を組み合わせた事例を紹介する。

目次

1．品質保証に関連する開発技術について
2．応用事例：基盤更改での品質保証
3．最後に

1．品質保証に関連する開発技術について

開発技術を組み合わせることによる相乗効果

これまでINSIGHT TECHでは、様々な開発技術について取り扱ってきました。各技術はそれ単体でも効果を生みますが、プロジェクトの特徴に合わせ、複数組み合わせることで、相乗効果が生まれます。
今回は、過去にINSIGHT TECHで紹介した品質保証に有効な開発技術を複数組み合わせた応用事例をご紹介します。

紹介する開発技術に関する過去記事について

応用事例で紹介する過去記事内の開発技術について簡単にご紹介します。詳しい内容については、過去記事をご参照ください。

記事1．バグ密度・テスト密度に依存しない品質保証への挑戦
- 観点カバレッジ
  - テスト観点とテスト対象を軸としたマトリクスを作成することで、テスト実施の網羅状況やバグの分布状況を可視化・分析する手法
- DDP（欠陥検出率）モニタリング
  - 検出したバグに占めるすり抜けバグの割合をグラフ化し、グラフの推移をモニタリングすることで早めに強化試験などの対策を行う手法
記事2．リスクベースドテストの活用でビジネススピードを上げる
- RBT（リスクベースドテスト）
  - テスト対象のリスクの大小を「バグが潜在している可能性」「バグがあった場合の影響」から評価し、リスクに応じてテスト対象のテスト方針を決定することで、効率的にバグを抽出する手法
記事3．「探索的テスト」を活用して品質を高める
- 探索的テスト
  - テストを実施しながらその結果に応じて、次に行うテスト内容を臨機応変に変えることで、システムの不具合が潜んでいそうな箇所を集中的にテストする手法

2．応用事例：基盤更改での品質保証

基盤更改の特徴

システムの保守作業の一つに、要件・機能は変更せず、基盤ソフトウェア（OSやミドルウェアなど）やハードウェアを更改する基盤更改があります。基盤更改には、多種多様な開発が含まれています。メインフレームからオープン系への移行のような大規模な更改から、ミドルウェアのマイナーバージョンアップのような小規模な更改まで存在し、その更改内容やシステム特性によって求められる品質も様々です。
本記事内では、今回紹介する事例のような更改範囲が小さくシステムの既存機能への影響が少ない基盤更改を「小規模基盤更改」と呼ぶことにします。

小規模基盤更改での品質保証

小規模基盤更改では、ソースコードの追加・修正を行わないことがあり、システム開発で品質保証をする際の指標であるテスト密度、バグ密度に利用することが多い規模（SLOC）が利用できないことがあります。そのため、過去に新規開発・機能追加開発で利用した指標値が使えず、小規模基盤更改のタイミングで品質保証について、改めて検討が必要なことがあります。

対象システム／開発の特徴

事例として紹介するシステムは、これまでウォーターフォール開発を行ってきたWebシステムです。過去の機能追加開発では、「記述式テスト（スクリプトテスト）」と呼ばれる、設計書や仕様書をベースにあらかじめテスト内容を考え、テストケースと呼ばれるドキュメントに記述して実施する手法でテストを行ってきました。
今回の開発は、Java、DB等のバージョンアップを行う小規模基盤更改であり、設計書、仕様書、ソースコードの追加・変更はなく、過去の全テストを再実施しデグレードが無いことが確認できれば品質が保証される開発でした。ただ、自動テストの仕組みを確立していなかった本システムでは、過去の全テストを再度実施することは現実的ではありませんでした。

表1：事例における「新規」「機能追加」「小規模基盤更改」の開発の違い

	新規	機能追加	小規模基盤更改
規模（SLOC）	有	有	無
既存機能への影響	―	中～大	小～中
主なテスト	新規機能の確認	追加機能の確認既存機能のデグレ確認	既存機能のデグレ確認
テスト密度・バグ密度の活用	可	可	不可

そのため、特に高コストだった結合テストとして、

画面レイアウト／帳票の出力内容などの表示確認＋各機能の疎通確認（以降、結合テスト（1））
各機能が仕様通りの動きであることの確認（以降、結合テスト（2））

を、高効率・高品質に行えるように、前述の開発技術（表2の赤字部分）を適用しました。

表2：過去開発（機能追加）と今回の開発（小規模基盤更改）の比較

以降は、冒頭で紹介した開発技術を結合テスト（1）結合テスト（2）にどのように適用したかを紹介します。

結合テスト全体（「リスクベースドテスト」）

結合テスト（1）結合テスト（2）の共通方針として、機能のリスク評価を行い、そのリスクの高さによってテストの濃淡付けを行う方針としました（表3）。

表3：リスク表

結合テスト（1）（「探索的テスト」×「リスクベースドテスト」）

「探索的テスト」の活用

今回の開発では、新規作成・変更した画面や帳票はないものの、小規模基盤更改の影響により表示位置、レイアウトといった見た目が変わっている箇所が無いかを確認する必要がありました。この確認に過去の結合テスト（1）で作成した大量の「記述式テスト（スクリプトテスト）」を網羅的に実施するのは現実的ではありませんでした。
結合テスト（1）では、画面内の項目や値一つ一つをテストケースと突合して確認していましたが、システムに習熟したメンバが「探索的テスト」を活用し、表示位置やレイアウトの変わる可能性が高そうな場所に絞って重点的に確認することで代替が可能な内容と判断しました。

「探索的テスト」の探索方針・実施時間をリスクの高さに応じて変更

「探索的テスト」中の探索方針については、前述の表3：リスク表のリスク評価結果に応じて、機能別に探索時に見るべきテスト観点と探索時間を変更しました（表4）。

表4：各機能のリスク評価に応じて探索方針を変更

結合テスト（2）（「リスクベースドテスト」×「観点カバレッジ」）

「リスクベースドテスト」「観点カバレッジ」の活用

結合テスト（2）では、従来通りの「記述式テスト（スクリプトテスト）」を行いました。ただ、過去の全テストケースを実施するのはコストが高いため、「リスクベースドテスト」を用いたテストケースの削減と「観点カバレッジ」によるテスト観点の充足状況の確認を組み合わせて、高効率・高品質のテストを行いました。
「リスクベースドテスト」と「観点カバレッジ」を組み合わせた下記手順（図1）を、システム有識者と複数回行うことで、現実的で妥当なテストケース数、テスト観点をテスト対象の各機能に対して決定しました。

図1：結合テスト（2）のテストケース絞り込み手順

［手順1．各機能のリスクの高さに応じて各機能で実施するテストケース数を決定する］
結合テスト（1）で作成したリスク表を活用し、リスクの高さに応じて、実施するテストケース数を決定しました（表5）。

表5：リスク評価によるテストケース数

［手順2．重要なテスト観点を多く網羅しているテストケースをテスト対象にする］
既存テストケースとテスト観点のマッピング情報があったため（表6）、より多くの重要な試験観点を網羅しているテストケースを優先する方針で、実施するテストケースを選定しました（表7）。

表6：テストケースとテスト観点
（結合テスト（2））のマッピング情報（過去開発時点で作成済）

表7：実施対象のテストケースの決定手順

［手順3．手順1，2で検討したテストケースでテスト観点がカバーできているかを確認］
「リスクベースドテスト」を用いて絞り込んだテストケースでも網羅的にテストしていることを保証するため、テスト観点の網羅状況を「観点カバレッジ」で確認しました。通常、「観点カバレッジ」では、件数のばらつきに関しても分析しますが、今回は、リスクベースドテストを併用しているため、件数のばらつきは許容した上で、観点の確認有無のみを分析（≒1件も確認してないテスト観点があった場合、テストケースを追加）する方針としました（表8）。

表8：観点カバレッジの分析

なお、今回の開発では、バグ自体が非常に少ないことが事前に予想されていたため、バグのばらつきに関しては「観点カバレッジ」で確認していません。また、「観点カバレッジ」とセットで利用されることが多いDDPモニタリングについても、バグが少ないと1件のバグによりDDPが大きく動きすぎるため参考程度の活用にとどめました。