ソフトウェアテスターのための4つのレッスン−1 レッスン1 [何もせずに取り残されるな]The Rational Edge (26)(2/4 ページ)

» 2004年07月31日 12時00分 公開
[Len DiMaggio(IBMソフトウェアQEエンジニア/マネージャ),@IT]

レッスン2 [常にふたを開けて中を見ろ]

 ソフトウェアテストエンジニアに対し、ふたを開けて中を見ろ、ということは一体どういう意味なのだろうか(注5)? 海外の読者のために説明すると、これは、購入しようとしている中古車の「ボンネット」を開けてエンジンのコンディションが良好か確認する作業からきた米国の例えだ。ソフトウェア開発は、プログラムを外観(目に見える入出力)だけでなく、内部設計、データフロー、そしてバグやバグ修正の履歴の把握にも一層の努力をせよ、という意味だ。このような作業から得た知識があれば、一段と堅牢(けんろう)かつ完全なテストが用意できるようになる。もっと現実的な言葉でいうと、ふたを開けて中を見ろ、とは次のようなことになる。

【注5】L. DiMaggio著、「Looking Under the Hood: An Investigative Approach to Software Testing」、STQE Magazine、2000年1月号。

◆ 探偵であれ。正式なものではない書類の大半は、ソフトウェア製品の開発やテストの合間を縫って書かれている。この非公式マニュアルには電子メール、メモ、会議の議事録など、複数の書類があるかもしれない。前製品の正式なもの以外の書類を見直すことも、設計や機能の制約(設計に関する判断だけでなく、その判断が下された理由など)を知る良い情報源となる。しかし、書面にされた情報だけで満足してはいけない。席を離れ、部屋を出て、チームのメンバーと話をしたい。探偵のような技術を使い、実際にコードを書いた人だけでなく、チームメンバーたちの頭の中身を掘り下げたい。

◆ マーケティング担当者であれ。エンジニアリング部門は、たいていマーケティング部門をばかにするが、彼らなくしては何も売れず、誰にも給料が支払われない。マーケティング担当者は顧客のニーズと期待を定量化する。これらのニーズに合わせて工夫したプランを読み、彼らのニーズを満たし、期待に応えることが、ニーズへの対応を検証するテストの設計でテストエンジニアを助けてくれる。

◆ 顧客サポート担当者であれ。電話相談を担当する顧客サポート担当者は、製品について顧客が抱える問題を解決するのを助けながら、製品の仕組みと顧客の使い方を詳細に理解していく。顧客が報告してきたバグにも対応するため、彼らは常に製品設計の制約に直面している。彼らはさらに、製品に対する顧客の期待と製品の実際のパフォーマンスとの差にも対処している。顧客の問題を解決したときの経験について、時間を割いて担当者と話せば、テストするソフトウェアの実世界における利用状況をもっとうまくシミュレートしたテストを構築する際に貴重な実態を理解できるようになる。

◆ 考古学者であれ。ソフトウェアの開発とテストを左右するスケジュールのプレッシャーを考えると、他人のプロジェクトの履歴を書く時間のある者はいない。良くて製品のバグデータベースがせいぜいだ。古いバグレポートなど読んでプログラムの何を学べるというのだろうか? 将来的にバグが見つかる場所ならば分かるかもしれない。プログラムのある部分で障害が発生する確率は、その場所ですでに見つかっている障害の数に比例する。つまり、バグが1つあれば、別のバグがある可能性も高い。例えば、プログラムの中で頻繁にパッチを当てている部分では、当初の設計との整合性が失われる場合がある(注6)。さらに、ソースコード制御システムのチェックインメッセージを読めば、変更の加えられているコードに関してかなり分かるようになる。これらのメッセージを読めば、どの部分のコードが頻繁に変更されているのかがよく分かるようになり、製品がどのようなサブシステムに分割されているのか理解するのに役立つようになる。

【注6】ソフトウェアの設計に関する概念的整合性を分かりやすく記述したものとしては、Fredrick Brooksの名著「The Mythical Man-Month」(人月の神話)を参照いただきたい。

◆ 初心者であれ。新しいソフトウェアプロジェクトを立ち上げるときは、図書館に行き、本を取り出し、ソフトウェアの正確な設計方法やその動作を学べたら役立つと思えないか? 実はそれができるのだ! 正直なところ、製品Aの最新リリースのテスト構築法に関する参考書を見つけることはできないが、その製品の構築に利用されたものと同じようなタイプのプログラムやシステムの参考情報は見つかるかもしれない。筆者は、怪しい動きをするデーモン(ちなみに悪魔のことではない)を見つけた数年前、このような状況に遭遇したことがある。このデーモンは、インターネットのファイアウォール製品の操作をサポートしていた。ところが、デーモンの書き方が間違っていて、デーモンの基本的なルールに従っていなかったのだ。例えば、これはログファイルにステータスメッセージを書き込まず、システムコンソールの方に表示していた(これは、本来無人で運用されなければならないプログラムにとっては悪い考え方だ。誰もコンソールのそばにいない場合、ログのメッセージは誰にも分からない!)。筆者はこのデーモンのテストをちょっとした研究プログラムにし、最終的には一般的なUNIXのシステムプログラミング(注7)や特にデーモン(注8)についてかなり勉強することができた。

【注7】筆者には、故Richard StevensによるUNIXのプログラミングに関する各種書籍が非常に貴重な情報源だった。UNIXシステムでプログラミングをするのであれば、これらの書籍への投資は当然の義務である。

【注8】筆者は幸いにも、この調査やテストの結果も「Testing UNIX Daemons」、Dr. Dobbs' Journal、2000年3月号で公表することができた。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ