2024.4.23

【第5回】：テスト実行の課題と解決への指針

ソフトウェア品質問題の流出を防ぐためには、”最後の砦”である品質保証の業務品質向上が欠かせません。しかしながら、昨今のQA現場には人的・時間的な多くの制約が存在し、その実現は難しくなっています。

QA現場の業務品質や生産性を向上させるうえで、有力な解決策となるのが「品質保証DX」です。QA現場のプロセスにDX（デジタルトランスフォーメーション）の概念を適用するアプローチであり、品質の早期安定化による飛躍的なQCD向上が期待されます。

品質保証DXには3点ありますが、これまでの連載では「品質計画」「開発・テスト環境」の2点に焦点を当ててきました。第5回となる本記事では、3点目の「テスト実行」における課題や、解決への指針についてお伝えします。

テスト実行における主な課題

第1回でも述べた通り、人材や工数といったリソースの不足は、多くのQA現場において避けることが難しくなっています。これらは当然ながら根本解決することが望ましい問題ではありますが、本連載第2回で述べたような計画フェーズで対処すべきものであり、テスト実行に係る施策からは外れる議論といえます。

そのため、ここではリソース不足に置かれた前提で、QA現場が解決すべき課題について論じます。テスト実行における主な課題は、「効率性」「信頼性」「実現性」の3つの観点に分けることが可能です。これらの課題について、それぞれ解説します。

1. 効率性に関する課題

QA人材の不足やテスト工数の圧迫に陥るQA現場において、特に重要となるのがテスト実行の効率性に関する課題です。すなわち、テストに関するプロセスが最適化されず、工数や端末といったリソースが効率的に活用されない課題を指します。

具体例として、次のようなケースが挙げられます。

手動のテストケース作成や結果判定に甘んじ、多くの工数を費やす。
開発/テストに用いる環境の競合が発生し、テスト実行に遅延が発生する。
過去のテストケースやテスト結果を活用できておらず、冗長な作業が発生する。

テスト実行には、多くのステップをともなうUI操作、正確性が求められる結果判定など、手動では効率性が著しく低下するタスクが少なくありません。要件の複雑化・多様化などによりテストケース数が増加しつつある昨今では、テスト自動化が最優先事項といえます。テスト自動化は、過去のデータ資産を活用するための施策としても有効です。

また、第3回でも論じた環境の競合も、テスト実行の効率性を低下させる大きな要素といえます。端末やサーバーといったハードウェアの拡充が難しい場合、既存の物的リソースをいかにして有効活用するかが重要となります。

2.信頼性に関する課題

ソフトウェア品質問題の流出を招く大きなリスクをともなうのが、テスト実行の信頼性に関する課題です。すなわち、テスト実行の結果やそれまでのプロセスに対する信頼性が乏しく、最終的なテスト品質が低下してしまう課題を指します。

具体例として、次のようなケースが挙げられます。

操作ミスや目視での誤認により、正しいテスト結果が得られない。
環境構築やテスト条件設定に不備があり、意味のあるテストが行えない。
回帰テストすべき範囲を見誤り、変更により混入したバグを見逃す。

テストケース数の増加や回帰テストの高頻度化などにより、テスト実行の業務負担は増大しているのが現状です。手動プロセスを多く含めば含むほど、操作や判断における人的ミスが生じやすくなることから、やはりテスト自動化を軸にした施策が求められます。

3.実現性に関する課題

テストの網羅性・信頼性にも密接に関わっているのが、実現性に関する課題です。すなわち、技術的なハードルやリソース不足などにより、本来実施すべきテストが完全な条件で実施できない、あるいは先送りせざるを得ないといった課題を指します。

具体例として、次のようなケースが挙げられます。

熟練したテスターを確保できず、網羅性の高いテストが行えない。
負荷テストの実施をリリース直前に行い、性能上の致命的な問題が発覚する。
セキュリティテストの実施を見送った結果、市場で脆弱性が発覚する。

特に、機能要件以外の性能などを検証する「非機能テスト」は、テスト実行のハードルが高い要素です。手順の再現や環境のセットアップはもとより判定基準の設定も難しく、機能テスト実施後の”努力目標”のように扱われる側面が否めません。また、環境への懸念がある負荷テストなどは、技術的に実施できたとしても後回しにされることが通例です。

テスト実行のソリューションを選定する際の要件

品質保証DXによりテスト実行の課題を解決するにあたっては、適切なソリューションの選定が非常に肝要です。ここでは、テスト実行のソリューションを選定する際の主な4つの要件について解説します。

1. テスト実行以外のプロセスを含めた包括的な自動化

テスト実行だけの自動化では、実行前の設計や環境構築、実行後の結果判定や分析などは手作業となり、飛躍的な効率性の向上は期待できません。したがって、テスト実行の前後で生じるプロセスを含めた、包括的な自動化が可能なソリューションが理想です。

テスト設計を自動化できれば、膨大なテストケースを自動生成できるばかりでなく、CI/CDツールとの連携によるテストプロセス全体の機械化が可能となり、テスターの大幅な負担軽減やテストのアジリティ向上につながります。また、結果判定を自動化することで、テスターの知見に委ねられ曖昧になりがちなソフトウェアの評価基準が明確化されます。これにより、目視では見逃しやすい微細な結果の差異も検出でき、テスト結果の信頼性を向上させることが可能です。

2.経験・スキルに依存しない自動化

別業務との兼ね合いにより熟練したテスターが確保できない、といったケースが往々にしてあります。品質保証チームの状況によらず信頼性の高いテストを行うためには、経験・スキルに依存しない自動化が求められます。

たとえば、過去のテスト結果をもとに実行するテストケースを自動選定できれば、回帰テストの影響範囲などを含めた実行判断の自動化が可能です。これにより、経験の少ないテスターでも、限られた期間の中で精度の高いテスト実行が可能となります。

3. 機能テスト・非機能テストの並行実施

機能テストが優先されやすい風潮とは裏腹に、非機能テストの不足・見送りに起因する品質問題が少なくありません。とはいえ、非機能テストをリリース直前に実施しても、問題判明時のリカバリーは難しくなります。よって、非機能テストは可及的早期に実施することが望ましく、機能テストと並行実施し、可能な限り非機能面でのテスト要件を検証できるソリューションが理想です。

ただし、負荷テストやセキュリティテストなどは種類ごとに評価観点が大きく異なり、単一ソリューションでの自動化は困難です。そのため、機能テスト向けのソリューションに、各非機能テストに対応したソリューションを併用することが現実的です。また第3回でも述べたように、各々をCI/CDパイプラインに組み込み、連携できるかも重要となります。