ソフトウェアテストの効率化が必要となる背景
ソフトウェアテストの件数を増やして、少しでも多くの欠陥を見つける方がよいという考え方は間違ってはいません。しかし、テストに費やせるリソースや時間は有限なので、限られたなかでテストの効率化を進めていく必要があります。
ここでは、なぜソフトウェアテストの効率化が必要なのかをご説明します。
株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流~下流(テスト計画・テスト設計・テスト実行・テスト品質管理)まで一気通貫でご依頼いただけます。
ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ
>>ソフトウェアテスト・第三者検証のページへ
>>導入事例ページへ
>>料金についてページへ
>>お問い合わせページへ
テスト工数の削減
ソフトウェアを開発する際には、当然のことながら、納期までに開発、テストを終えなければなりません。納期に間にあわせるためには、テスト工数の削減が必要な場合もあります。
開発期間が無限にあるプロジェクトなどあり得ないので、テストの効率をあげながら、工数を削減する取り組みが必要です。
中長期的なコストの削減
システムは一度開発して終わりではなく、いろいろな変更を反映して修正していくものです。
修正があると既存部分に影響がないかを確認するためにリグレッションテストを行いますが、何も考えずに進めると、リグレッションテストの数がどんどん増えてしまって、テスト工数が増えつづけることになります。そのため、リグレッションテスト工数の削減は重要な検討課題となります。
テストの自動化は、初期工数はかかりますが、リグレッションテストの工数削減に大きく効果の出る方法です。
リグレッションテストに関してはこちらもご覧ください。
>>リグレッションテスト(回帰テスト)とは?目的や自動化のメリットを解説のページへ
テスト品質の向上
テストにおいても関連する技術は進歩しており、数々の新しいツールが提案されています。これらのツールを活用して、より効率的なテスト設計、よりきめ細かなテスト管理ができれば、同じ工数であったとしてもテストの品質を向上させることができます。
関連サービスについて
ソフトウェアテストの【設計】を効率化する方法
ソフトウェアテストの精度を下げることなく効率化していくためには、いくつかの方法があります。ここでは、ソフトウェアテストを設計する段階で効率化する方法について、ご説明します。
テストケースの再利用
過去に作成したテストケースを再利用することで、テストケースを一から作成する手間を省くことが可能です。ただし、過去のテストケースが今回の開発の内容に適しており、十分に足りているかを検証する必要があります。
たとえば、Webページの画面テストを行う際には、過去に行った同じような構成の画面テストの再利用が可能です。画面の入力項目の個数、入力値の型などについて、今回のテストケースにあっているかを確認して再利用します。
組み合わせテスト
テストを行う際に避けて通れないのが、組み合わせテストです。データや入力値の組み合わせを網羅してテストすることで、特定の組み合わせで起きるバグや欠陥が見つかることもあります。
たとえば、飲食店で食事を注文するシステムの「メイン」「サイド」「飲み物」を選択する機能をテストするケースを考えてみましょう。
・メイン:ハンバーグ、パスタ
・サイド:サラダ、スープ
・飲み物:コーヒー、コーラ
上記のようなメニューをそれぞれ選べるとします。この場合、3つの欄で選択できる組み合わせは、以下の表のように2×2×2=8とおりです。
テストケース |
メイン |
サイド |
飲み物 |
1 |
ハンバーグ
|
サラダ
|
コーヒー
|
2 |
ハンバーグ
|
サラダ
|
コーラ
|
3 |
ハンバーグ
|
スープ
|
コーヒー
|
4 |
ハンバーグ
|
スープ
|
コーラ
|
5 |
パスタ
|
サラダ
|
コーヒー
|
6 |
パスタ
|
サラダ
|
コーラ
|
7 |
パスタ
|
スープ
|
コーヒー
|
8 |
パスタ
|
スープ
|
コーラ
|
8とおりくらいなら簡単にテストできますが、選択できるメニューが増えると件数は増えていきます。それぞれ4種類ずつメニューを選択できれば、4×4×4=64とおり、ほかのサイドとデザートを選択できれば、4×4×4×4×4=1,024とおりに膨れ上がってしまいます。
このように、組み合わせテストは、テストケースが急激に増えていくのが特徴です。そのため、テスト件数を減らす、ツールで自動的にテストするなどの対策が必要です。
効率的な組み合わせを示す「二因子間網羅(ペアワイズ)法直交表」について
テスト件数を減らす場合には、テスト内容を網羅しつつ、効率的に減らす必要があります。その際に役立つのが「二因子間網羅(ペアワイズ)法直交表」です。
上記の例では、入力欄の「メイン」「サイド」「飲み物」を因子と呼びます。不具合が起こるのは、2つの因子の組み合わせによることがほとんどです。3つ以上の因子の組み合わせによって起こることは、めったにないといわれています。
この考え方を利用して作成するのが二因子間網羅(ペアワイズ)法で、テストの組み合わせを自動生成するツールが提供されています。上記のテストケースは以下のように4通りに減らせました。
テストケース |
メイン |
サイド |
飲み物 |
1 |
ハンバーグ
|
サラダ
|
コーヒー
|
4 |
ハンバーグ
|
スープ
|
コーラ
|
6 |
パスタ
|
サラダ
|
コーラ
|
7 |
パスタ
|
スープ
|
コーヒー
|
たとえば「メイン」と「サイド」の因子に注目すると、それぞれすべての入力値の組み合わせが網羅されていることがわかります。ほかの「メイン」と「飲み物」、「サイド」と「飲み物」の組み合わせについても同様です。
ただし、すべてのテストで、直交表を使えば十分というわけではありません。未入力のケース、文字数がもっとも多くなるケースなども考慮して、テストが十分かを検証する必要があります。
リスクベースドテスト
リスク分析とリスクコントロールに基づいてテスト活動を選択し、優先順位を付け、マネジメントしていくテストアプローチをリスクベースドテストという
リスクベースドテストでは、システムの品質に関するリスクをとりあげます。
例として、あるシステムにサービスを予約する機能と、その予約をキャンセルする機能があったとします。ここで、システムの品質にリスクがあって、そのリスクが顕在化することによって、機能が使えなくなったとします。
リスクの評価では、そのインパクトがどのくらいのものか、それがどのくらい起こりやすいかを分析します。
予約機能から分析しましょう。予約機能が使えなくなったことにより、サービスの予約ができなくなります。これは要するに、利用者がサービスを予約してくれないということです。予約してくれないのでサービスの提供もできず、サービスの対価も得られなくなります。
利用者はうまくいったらサービスを継続利用してくれたかもしれないのに、その機会も失うことになりそうです。サービスを提供するビジネスとしては非常に痛いインパクトがあることがわかります。
キャンセル機能が使えないとどうでしょうか。利用者はキャンセルするはずだったので、料金が請求されなければ問題ありません。気のきいた利用者なら、電話でキャンセル通知をしてくれるかもしれません。
サービス側ももしかしたらキャンセルの出た枠にほかの利用者を入れられたかもしれませんが、インパクトは限定的でしょう。起こりやすさで考えると、キャンセルする人は予約ができた人のなかのごく一部であると考えられます。そう考えると、リスクの高低は先に考えたインパクトの差よりもさらに広がることになります。
このような分析によって、予約機能はキャンセル機能に比べて、はるかにリスクが高いという評価となります。そのため、予約機能のテストはより工数をかけて手厚く、キャンセル機能は薄くという工数配分を考えたり、またテスト順序も予約から先にやったりといった調整をします。
テスト設計についてはこちらもご覧ください。
>>テスト設計とは?プロセスと作成方法について解説のページへ
ソフトウェアテストの【実行】を効率化する方法
ソフトウェアテストの設計が終わり、テストを実行する段階でも効率化できることは多いです。ここでは、テスト実行時の効率化の方法についてご説明します。
テストの自動化
テストを正確に効率よく実行するためには、テストの自動化が有効です。支援ツールを使ってテストを自動化することで、テスト作業の大幅な負担軽減につながります。また、自動化によって人為的なミスを防げるため、テスト品質が向上することもメリットです。
ただし、テストの自動化を実現するためには、テストコードの作成やツール導入のコストがかかるというデメリットもあります。一回目のテストでこれらのコストが追加で負担できるように計画しなければなりません。つくったテストを2回、3回と繰り返し実行していくことで、少しずつコストをとり戻していきます。
導入後の運用体制の構築も考慮する必要があり、長期的に運用できないのであれば、コストと手間をかける価値は得られないでしょう。
自動化に向いているテストと、向いていないテストもあります。繰り返し作業が多いテストなどには向いていますが、ユーザビリティテストなどには向きません。
テスト自動化についてはこちらの記事をご覧ください。
>>テスト自動化とは?メリットや導入の流れ・向いているテストを解説のページへ
関連サービスについて
要員配置の見直し
テストを行う要員の配置見直しを行うことで、テスト作業の効率化をはかれることもあります。
画面仕様書に沿って入力と出力を確認するようなテストであれば、仕様書を読む力があればテスト設計はできますし、基本的なITリテラシーがあればテスト実行も可能でしょう。しかし、業務の進行とシステム操作が整合しているかを確認するようなテストは、業務のことをよく知っていないと、テスト設計もテスト実行もうまく作業できません。
このようにテストの内容に応じて、作業分担を見直す、配置を変更するなどの対策が必要になる場合もあるでしょう。また、開発担当者がそのままテストを担当する場合も、テストの内容とスキルの整合を考慮しましょう。
テスト作業の内容や要員、プロジェクトの状況を正しく把握して、効率アップに向けた配置の見直しを行うことが重要です。
テスト実行についてはこちらもご覧ください。
>>テスト実施(実行)ですべきこと~必要な準備と実施手順について紹介~のページへ
ソフトウェアテストの効率化を実現するためのポイント
ソフトウェアテストを効率化するためには、いくつかの重要なポイントをおさえておく必要があります。やみくもに効率化を求めると、テスト品質が下がってしまう可能性が高いです。ここでは、テスト品質を下げずに、テスト効率をあげるためのポイントについてご説明します。
タスクの棚卸しを行い、課題を検証する
まずは、現状のタスクを洗い出して棚卸しを行い、課題がどこにあるのかを検証する必要があります。
どのようなタスクがあるのか、どのタスクでどれくらい時間を使っているのかを把握しましょう。その後で、どこに時間をかけすぎているのか、どこに問題が発生しているのかを検証します。
状況を正しく把握せず、思い込みで「ここが問題だ」などと決めつけるべきではありません。どこに問題が潜んでいるのか、本当にそれが問題なのかを正しく理解する必要があります。
たとえば、テスト項目の抽出に時間がかかっていたとしても、その工程を短縮するのが正しいのかはまだわかりません。新たな機能に対するテストの場合には、じっくりと時間をかけてテスト項目を検討する必要があります。担当者が再利用可能な過去のテスト項目の存在を知らずに、一からテストを作成しようとしていたなら、そこに問題があるといえるかもしれません。
現状の工数から優先順位を決める
問題点がわかったら、どの問題に対処すべきかを決める必要があります。すべての問題に対処できない可能性もあり、解決しても効果が低い場合もあるでしょう。
そのため、現状の工数を見て、どの問題を解決すべきか優先順位を決めます。解決すると効率化の効果が高い問題を、優先的に対応しましょう。
効率化ができる作業内容なのかを確認する
優先度の高い問題であっても、効率化が困難な場合や、解決に時間や手間がかかりすぎる場合もあります。限られた工数のなかで、効率化できる作業なのかを確認しなければなりません。要員の配置やテスト方法の見直し、ツール化などで解決可能な見込みがあるなら、対応します。
また、ここまでで検討した内容を次のプロジェクトに申し送りして、次に活かすのもよいでしょう。
必要に応じてツールを活用する
効果が高い解決方法として、支援ツールを活用したテストの自動化があります。支援ツールの導入が可能なら、活用することをおすすめします。
ただし、プロジェクトの途中で、テスト作業の大幅な見直しが必要なツールの導入をするのは、リスクが大きいでしょう。リスクと効果の兼ねあいを検討する必要があります。
関連サービスについて
SHIFTのソフトウェアテスト・品質保証サービスについて
関連サービスについて
まとめ
この記事では、ソフトウェアテストの効率化について、設計、実行段階での具体的な方法についてご説明しました。
ソフトウェアテストの効率化は、品質担保との兼ねあいが非常にむずかしいという問題があります。また、テスト支援ツールを導入して効果を得るためには、ツール導入やテストに関する専門知識が必要とされます。
ソフトウェアテストの効率化や支援ツールの導入をお考えの場合には、SHIFTにご相談ください。ソフトウェアテスト支援の豊富な実績をもつスタッフが、強力にサポートいたします。
ご相談はこちらから
>>お問い合わせページへ
>>料金についてページへ
ソフトウェアテストの悩みはSHIFTが解決できます!
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
監修
株式会社SHIFT
「ヒンシツ大学」クオリティ エヴァンジェリスト 永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座