背景

大手旅行会社において、基幹システムのレガシー化により様々な業務課題が発生。

顧客向けおよび社内向け、それぞれの基幹システムの老朽化に伴い、様々な業務上の不都合が生じていた。

■顧客向け
多様な顧客ニーズに応えられなくなった。
（例）外国人のインバウンド旅行者が増えている中、多言語に対応できていない。
（例）宿泊先や旅行先の施設や店舗の様々なオプションのカスタマイズができない。
（例）モダンなUIではなくレガシーなUIのため、顧客にとって使いにくい。

■社内向け
業務効率面で競合他社に劣るようになってしまった。
（例）旅行商品を造成する際に、パターンの組み合わせを自動生成する等の機能が無い。よって、パターンに応じて1つ1つ旅行商品を造成しなければならない。

これらの課題を解決するため、基幹システムを再構築することとなった。
案件規模としては10億円規模、期間2年間ほどに及ぶ大規模な再構築案件となる。

この案件の進行中、テスト工数の膨張が課題として発生した。

課題

大規模システムがゆえに、膨大なテスト量による開発コストと期間の膨張が懸念された。

背景でも述べた通り、本案件は開発規模が大きく、比例して機能テスト(結合テスト)の量が膨大で、開発期間/開発工数が膨張することによる遅延の発生が懸念された。

しかし、テスト量と品質はトレードオフの関係にあり、取捨選択の判断が難しい。
仮にテスト量を削減した場合、テスト不足によりシステム障害につながるリスクがある。結果、膨大なテスターを投入してテストを完了させるケースが多く見受けられる。

この課題を解消するため、テスト計画を策定することとした。

【参考】
■開発規模
　約100万SLOC (1,000KSLOC)
■機能テストケース数の見積もり
　IPAによる基準値50.5件/KSLOC(※1)×1,000KSLOC＝50,500件
　※ 参考：https://www.ipa.go.jp/files/000069381.pdf
　　　　　図表 7-5-20 ● テスト工程別 SLOC 規模あたりのテストケース数、検出バグ数の基本統計量

取り組み

正しい品質目標とテスト計画に基づき、緻密なテストケースの策定を行いテストを遂行。

納期遅延を防ぎ、かつテスト品質を落とさないための手段として、以下の4つの取り組みを実施した。

①品質目標の定義

テストによってどこまで品質を保証するのか目標を定義することが重要である。
理由は、全てのパターンを網羅してテストをすることは不可能だからである。 
言い換えると、バグ0件を実現することは不可能だからである。

具体的には、どこまでバグを許容するか？を目標として定義する。

【当案件での事例】 
損害額が大きいバグを抑止する方針で、(図1)の通り目標を定義した。

（図1）

②品質目標を機能ごとに落とし込み

品質目標に沿って、テストをどこまで網羅するかの重み付けが重要である。

理由は、品質を確保しながらテストを削減する足掛かりとなるからである。

具体的には、品質目標に直結する機能は重点的にテストを実施し、そうではない機能はテストを削減するという考え方である。
どこまでテストを削減して良いのか？という疑問には後述で答える。

【当案件での事例】
品質目標を元に、基幹システムの各機能に対し、品質目標を高/低で定めた。
機密情報のため全ては記述できないが、ざっくり抜粋すると(図2)の通りである。

（図2）

③品質目標ごとのテスト目標を設定

品質目標が低いものは、テストをそこまで網羅しなくても品質目標を達成できる。
つまり、(図3)のようなテスト方針とすれば、テスト工数を削減可能である。
テスト効率化のカギを握るのは、オールペア法である。

（図3）

【オールペア法】
ほとんどの不具合は多くとも2つの因子の相互作用によって引き起こされているという考えに基づき、2項目間の全組合せを網羅するテスト手法である。
※参考：http://www.pairwise.org/　pairwiseテストについて

約7割以上のバグは、2つの因子の組み合わせで発生している。
※参考：https://www.atmarkit.co.jp/ait/articles/1505/29/news015.html
　　　　現場で使うためのオールペア法、直交法の基本

【削減できるテストケース数の目安】
例えば、5つの因子(1つの因子のパターンが全て4パターンずつ)だとすると  、864ケース削減できる。
●全組合せの場合
4×4×4×4×4＝1,024パターン
●オールペア法の場合 
5C2×16＝160パターン

【当案件での事例】 
前述のテスト方針の通りとした。 

④具体的なテストケースの作成

品質目標に沿って、ディシジョンテーブル or オールペア法でテストケースを作成する。ディシジョンテーブルは、特筆すべきノウハウは無い。

【オールペア法のベストプラクティス】
オールペア法は、ツールを使って自動生成するのがベストプラクティスである。理由は、オールペアなテストケースを人が手で作成するのは難しく、ツールを使わないとテストケースの抜け漏れが発生しやすくなるためである。

【オールペア法のテストケースを自動生成できるツール】
2種類のツールを組み合わせて使用する(図4)。
ツールの使い方は後述にて手順を提示する(図5,6)。

（図4）

（図5）

（図6）

まとめ

正しい計画に基づいたテスト実施により、高品質を担保とテスト量削減を両立。

機能テスト(結合テスト)の量を削減し、予定していた開発期間内に全テスト工程を完了。
また、予定したバグ密度もクリアし、品質面でも目標クリアを実現した。

以下は、大規模システムにおけるテスト工数削減のポイントとなる。

●早期のテスト計画策定
スト計画の早い段階で、テスト効率化のアイデアを洗い出し計画を策定。
結果、オールペア法の概念をステークホルダに事前共有することで、スムーズな導入を可能に。

●テストケース作成ツールの導入
オールペア法のテストケース作成において作成ツール検討し導入。
結果、テストケース作成の効率化と、人的ミスなどのテストケース漏れ抑止に、一定の効果を上げた。