ソフトウェア開発において生産性と信頼性を両立するには！？
生産性を犠牲にせず、信頼性の高いソフトウェア開発を行う方法を解説

全ての機能においてテスト項目を完全に網羅しようとすると、膨大なテスト項目になる場合があります。ソフトウェアには重要度の高い機能が存在します。例えば金額や法律に関連する処理は重要度が高くなります。また「この機能が使えなくなるとサービス全体が停止する」といったものも重要度が高くなります。こうした重要な機能と同等のテストを全ての機能について適用すると、テスト工数が膨らんでしまいます。

仕様書をもとにテスト項目を漏れなく抽出するのは、かなりの時間がかかります。ソフトウェアの内容によって観点も異なるため、観点を網羅するのに担当者の経験に頼ってしまうことになります。また性能やユーザビリティについては、ユーザーや開発者から観点を出しにくい領域で、項目抽出のハードルが高くなります。

例えばA機能とB機能・C機能の関連性が高いと、A機能を拡張した際に、手を加えていない既存のB機能とC機能をテストする必要があります。このようなリグレッションテストの場合、修正する工数と比較してテスト項目が膨大になり工数がかかってしまうという問題があります。企業によっては、拡張する開発は新規開発の約1.5倍のテスト工数がかかるというデータもあります。

網羅的なテストからいかにテスト範囲を絞り込んでいくかを考えた時に、ユーザーが不具合に遭遇した場合の影響度を考えて上流工程の段階でボトルネックを特定しておくと、テストの工数を予測しやすくなり、早めにテストすることでリスクを抑えることが可能です。ボトルネックの特定には、優先度と重要度を評価して重みづけします。中核となる機能、複雑なロジックを持つ機能、他の機能への影響が大きな機能については優先度が高くなります。また例えば数千人が同時にアクセスする機能については、ツールによる性能テストをする必要があるため、上流工程の時点で特定しておくと、テストの準備もスムーズに進められます。

テストケースはExcelで作るという企業も多いのではないでしょうか。その場合ファイルの中身を確認しないと、どのようなテストをしているのかがわからず再利用しにくいという問題があります。再利用しやすくする方法として、過去のテスト項目を全てデータベース化するという方法も考えられます。観点を網羅できるだけでなく、リグレッションテストでの再利用もできます。ヴェスでは過去の実績を全てデータベース化し、テスト観点を標準化しています。

リグレッションテストで同じテストを何度も行う場合、テストの自動化をするとコストを削減できるだけでなく、影響範囲の特定で範囲から漏れてしまい運用開始してから不具合が発見される危険性が低くなります。テストを自動化するまでには、それなりの負荷がかかりますが、改修が頻繁に入る機能を中心に自動化していくと作業負荷を抑えられます。