テストで行うおもなプロセス
今回からは4回にわたって、ソフトウェアテストを進めるにあたって考えることを取り上げていきます。ソフトウェアテスト（以下、テスト）は、ソフトウェアの欠陥を見つけ品質を評価する大事な作業です。まず、テストはどのように進めていくかおさらいしてみます。
テストの開始から終了までのおもな活動について、ソフトウェアテストライフサイクル（Software Test Life Cycle：STLC）と呼ぶテストプロセスでは表1 のように定義しています。STLCのプロセスはどれもテストを進めるために必要な活動だと思います。テストを実行することはもちろん、何をどのようにテストするか計画を立てなければテストは進められませんし、テスト結果を分析・評価しなければソフトウェアがリリース可能か判断できないからです。ですがこのプロセスどおりにテストを愚直に進めようとすると、筆者には「“ 要件定義と設計” および“ テスト対象ソフトウェア開発” が完了していること」が前提条件になると思えるのですが、いかがでしょうか？
表1 テストで行うおもなプロセス
アクティビティ 説明 1 要求分析を行う 要件定義や設計からテストの視点を特定し、実施するテストの種類を決定する 2 テスト計画を策定する 実施するテストを踏まえて、テスターの要員計画・必要なテスト環境などを計画する 3 テスト設計を行う テストケースやテストスクリプトを作成してレビューを行う 4 テスト環境を構築する テストの実行環境の準備や設定を行う 5 テストを実施する テスト計画とテストケースに基づいてテストを実行する。また、発見されたバグも管理する 6 テスト結果を分析する テストの実行結果、バグの状況を基にしてテスト完了とするか検証する
この前提条件に、テストプロセスが抱える問題点があると考えています。
テストはソフトウェア開発のボトルネックになりがち
筆者が問題だと考えている理由はテストの開始時期にあります。「 “ 確定した要件定義と設計に基づいて開発した” ソフトウェアをテストする」ということは「“ 開発プロセスの後期に” テストする」ことであると考えているからです。これは以下に挙げる、テストで起こるさまざまな要因と相まって、テストがソフトウェア開発プロセスのボトルネックになってしまうことが、筆者の経験上でもよく起こっていたからです。
不具合の発見が開発スケジュールの遅れにつながる
テストで欠陥が見つかることは当たり前だと思いますが、欠陥の修正には時間がかかりますし、欠陥の修正が新たな欠陥を生むこともあります。このような作業を開発後期に繰り返せばスケジュールに遅れが生じたり、品質を妥協したままリリースせざるを得なくなったりします。これを防ぐために余裕を持ったスケジュールで見積もるのですが、“ 諸事情” によってさまざまな作業が後ろ倒しになり、結果としてテストに使える時間や要員が削られてしまうプロジェクトを多く経験してきました。
テストしづらい
要件定義で決まったことや設計したことが、テストを行うために十分な情報であるとは限りません。欠陥を見つけるために、設計書には書かれていないことをテストしなければいけないこともあります。たとえば、デシジョンテーブルのような入力の組み合わせに対する出力をテストする場合、あるパターンに対する考慮が足りず、漏れているというパターンをテスト設計時に発見するといったことがあります。テストの視点では、要件定義や設計書に書かれていることがあいまいなためテストの目的や条件がわからず、テストしづらいソフトウェアというものもありました。
最近の開発手法にテストが追いついていけない
いわゆるアジャイル開発の採用が広がってきたことで、テストは「要求の変化」「 （ 完全に）文書化されていないソフトウェア」「 頻繁にリリースする」といったことに、品質基準を維持しながら対応していかなければなりません。
このような状況の中で開発後期に、テスト計画から始めて、テスト設計・実行を進めて、評価・分析することは非効率と感じます。
テストを効率良く進めるアジャイルなテストの考え方
表2 は、筆者が読んだテストに関するさまざまな書籍や文献に対して、筆者なりの総括を「アジャイルソフトウェア開発宣言 」風にまとめたものです。
表2 テストを効率良く進めるのに大事なこと
大事なこと 概要 要件どおりかテストをするよりも、 要件定義や設計といった開発工程の初期からテストの視点を持ち込み、テストケースを意識した要件や設計を並行して行う 作ったあとにテストするよりも、 設計作業と並行して行ったテストケースを使って、テストを実行しながら開発する 一度きりのテストよりも、 同じ条件で同じテストを何度も繰り返し実行できるように、テストを設計してテスト環境を準備する すべての欠陥をなくすよりも、 要件およびストーリーのリスクと優先度を意識して、発生した欠陥を今修正するべきかを判断する
これらを実現するテストプラクティスとして、「 テストファースト」と「継続的テスト」を取り入れるのが良いと思います。
テストファースト可能なテスト管理を考える
テストチームが顧客や開発チームと一緒に要件定義から参加し、テストの視点を含めながらさまざまな視点で要件を明らかにできるようになるとどうなるでしょうか？ これによってテストを意識した設計になり、テストケース・テストコード・テストデータなども並行して作ることが可能になります。そうなるとテストをして逐一修正しながら開発を進められるようになります。このようにテストを開発初期から進められるようにします。
テストファーストはTDDと呼ばれるテスト駆動開発のことを指すのではなくむしろ、UIテスト・APIテストのようなE2Eテスト、シナリオレベルの機能テスト、負荷テストなどの非機能テストなどを指します。また開発が進んでいく中でテストケースやスクリプトなどを修正することも含み、機能の追加や修正とともにテストケースも改善して継続的に利用できるようにします。
テストファーストでは、機能要件とテストをリンクしてトレーサビリティを維持しないと「要件に対してテスト設計は十分か？」「 要件に対する品質は十分か？」などの機能要件単位の品質管理が難しくなってきます。
そこでテストの管理が必要になるわけですが、つづきは後編での説明とさせてください。継続的にテストを実施するためのテスト管理ツールを紹介していきます。
米国Atlassianから、2年連続で「Top new business APAC」を受賞。
日本だけでなく、アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトのWebサイトでは、各アトラシアン製品の体験版を提供しているほか、アトラシアン製品専用のコミュニティも運営しています。まずはアクセスしてみては！
第1特集 MySQL アプリ開発者の必修5科目 不意なトラブルに困らないためのRDB基礎知識 第2特集 「知りたい」「使いたい」「発信したい」をかなえる OSSソースコードリーディングのススメ 特別企画 企業のシステムを支えるOSとエコシステムの全貌 ［特別企画］Red Hat Enterprise Linux 9最新ガイド 短期連載 今さら聞けないSSH ［前編］リモートログインとコマンドの実行 短期連載 MySQLで学ぶ文字コード ［最終回］文字コードのハマりどころTips集 短期連載 新生「Ansible」徹底解説 ［4］Playbookの実行環境（基礎編）
