Patterns for System Testing

David E. DeLano and Linda Rising

翻訳者 早稲田大学大学院 太田健一郎

COPYRIGHT 1996 AG COMMUNICATION SYSTEMS CORPORATION. ALL RIGHTS RESERVED. GTD-5 IS A REGISTERED TRADEMARK OF AG COMMUNICATION SYSTEMS.

 システムのテストは現在、たとえテストをサポートするような手法や方法論があるとしても、科学というより職人技である。この事実は長い年月を掛けて進化する大規模組み込みシステムのテストの際に更に顕著になる。出荷時の品質を最大限に高めるために、システムテスターは製品開発のライフサイクルにおいて極めて重要なものとなってきている。本パターン・ランゲージはベテランのシステムテスターから得られたものであり、これによってシステムテスターは顧客に製品を出荷する準備が整っているかを評価することが出来るようになる。これらのパターンはシステムテストのフェーズの経験から得られたものであるが、パターンの多くはすべてのテストフェーズに有効なものである。これらのパターンは設計者とプロジェクト・マネージャーにも有用かもしれない。

 これらのパターンは、システムテストのどの工程で有効なのかという基準で分類している。それぞれの分類はテスト組織、テスト効率、テスト戦術、問題解決である。これらのパターンがすべてをいい尽くしているわけではないことに注意して欲しい(28-1を見よ)

 

共通の状況

 ここで述べるパターン群はパターン・ランゲージをなしており、共通の状況の元に置かれる。この共通の状況はこれらのパターンをパターン・ランゲージとしてまとめる役割を果たす。パターンによっては共通の状況とは異なる状況に置かれる場合もあり、そのときには各パターンは追加、修正された状況を記述する。

 新しい機能を追加しているシステムを考える。システムは新規開発かもしれないし、稼働中のシステムかもしれない。システムに対する顧客の数は限られており、前述の機能はこれらの顧客の要求にしたがって開発されている。顧客はその機能を備えた製品をエンドユーザーに提供する。新しい機能はシステムにうまく統合されるが、新しい機能を導入することによって、既存の機能を破壊する危険がある。それらの機能は開発グループの設計者によってシステムに実装される。設計者は単体テストと統合テストによって、分析、設計、実装のすべてに対して責任を負う。

 システムの機能は並行して設計される。コードが利用可能となると、テストを行うためシステムを徐々に稼働させる。稼働しているシステムは完成している部分と半完成の部分の両方を含む可能性がある。これによって開発スケジュールは短縮されるが、問題解決と機能の開発を同時に行わなければならなくなる。1回の稼働によって生じた問題は、進行中のいずれかの機能の開発の際に解決する必要がある。

 この場合、システムとは大規模組み込みシステムである。システムは複数のプロセッサからなり、それぞれのプロセッサはマルチプロセス対応のオペレーティング・システムによって管理される。したがってシステムのイベントは非決定的である。システムの各機能はほかの機能と相互作用を持つかもしれない。これらのパターンの多くはどのようなマルチプロセスのシステムのテストにでも適用できる。そのようなシステムを完全にテストするために必要となるテストケースの数は膨大なものとなる。システムを無理なくテストするのに必要となる回帰テストの数はリリースのたびに増加するので、すべてのテストを実行するのには新しい機能の開発に許される開発スケジュール以上の時間が必要となるであろう。

 機能はシステムテストと呼ばれる独立したグループの努力によって並行してテストされる。システムテストのメンバーはシステムテスターと呼ばれる。このグループによって行われるテストは大部分、完全な「ブラックボックス」である。システムのテストには単体テストからシステムテストに至る信頼できるプロセスが存在する。システムテストのグループはシステムの回帰テスト、仕様と新しい機能が正しく対応しているか、システムが以前のリリースと等価性を保っているか、いつリリースすべきかの評価、などに対して責任を持つ。これらの規準は各リリースで変わることはない。システムテストはシステムの機能性に集中し、システムが首尾一貫して動作し続けることを保証するものである。このために、テストはシステムにストレスを与えたり破壊したりすることがある。

 本パターン・ランゲージは、オブジェクト指向設計におけるGOF[Gamma+95]と比肩できるほどのものではない。システムテスターはシステムテストの工程を理解している。その代わりに、本パターンは経験豊かなシステムテスターが持つ極意の一部を与える。これらのパターンに従うことによってシステムテストのストレスを最少にし、喜びを最大にすることが可能になる。

 

共通のフォース

 これらのパターンは状況を共有するのと同様にフォースも共有する。個々のパターンは特定のフォースを強調したり、いくつかのフォースを無視したり、パターン・ランゲージ全体としては重要ではないフォースを追加したりするかもしれない。状況と同様に、個々のパターンに対するフォースはそれらを強調、修正、追加する必要がある場合にのみ記述される。

 これらのパターンに対するフォースの多くはリスク管理の面を持つ。パターンはコストと時間、内容、品質間の合理的な均衡を見出すために、これらのリスクを評価する。共通のフォースは以下のとおりである。

 

テスト組織

 以下のパターンではシステムテスターと組織のほかの人々との関係に注目している。これらのパターンは技術的なものではなく、むしろJames Coplien[Coplien95]Neil Narrison[Harrison96]Alistair Cockburn[Cockburn96]Don Olson[Olson95]らのパターンと関連が深い。

 

テスターはテストケースよりも重要

問題

 テスト効率を最大化するにはテスターにどのように仕事を割り当てたらよいのか。

フォース

解決策

 仕事はシステムテスターの経験と能力と基づいて割り当てなさい。どんなに効率的なテストケースを作ろうと、テストが成功するかしないかはテスターの能力に強く依存している。Davisは「人は成功のカギである」と述べている[Davis95]

結果

 テスターはその能力がうまくいかされれば更に有能になる。その結果テストはより効率的に、テスターは更に創造的になる。

 このパターンの結果は、テスターが燃え尽きるか、深い専門知識を得るかのどちらかである。テスターは1つの分野に精通しすぎると、根拠のない仮定をして背後にある問題を見過ごすことがある。新しい専門能力は今まで通りの能力で十分が仕事が出来、新しい能力を必要としないときには育たない。時々、能力の半歩先の仕事を与えてみるのもよいことである。

論理的根拠

 テスターはテストの平均化において最も重要である。テスターが違えば、同じテストケースだからといって同じ結果を得られるとは限らない。テスターによって欠陥表の見方は異なる。あるテスターは正常ケースの設計に詳しく、別のテスターはシステムをどのように破壊したらよいかを知っている。あるテスターは問題を発見するのにたけている。あるテスターは設計者と仕事をするのが得意である。テスターの能力に応じた仕事を割り当てることによって、更に効率的なテストが可能になる。

 DemarcoListerは与えられた仕事に対し最悪のものと最良のものでは実行能力に関し大きな相違があることを立証した[DeMarco+87]。テストで成功するためには、すべてのテスターにその能力に最も適した仕事を与えるべきである。

 

設計者は友人

問題

 設計者と共にシステムテストを行うにはどうしたらよいか。

解決策

 設計者とよい関係を築きなさい。設計者と接するときには、システムには両者が協力して取り組まなければ解決出来ない問題があることを頭の隅において接しなさい。これによって設計者とシステムテスターの目標が同じになる。常に問題を文書化しなさい

結果

 問題解決の際には協力が必要であるが、このパターンによってシステムテスターと設計者の関係はその協力の1つとなる。システムテスターに対し、設計者は防衛的ではなくなり、逃げたり、隠れたりもしなくなるであろう。

論理的根拠

 システムテスターも設計者も同じ会社の従業員であり、問題を解決するために互いに協力すべきである。設計者とシステムテスターはパートナーである。設計者とよい関係を築くことによって、仕事が速くなる。問題を個人的なものにすることは設計者を防衛的にする。システムテスターと設計者は互いに学び合い、共に利益を得ることが出来る。

関連するパターン

 チーム内のすべてのメンバーはほかのメンバーの発言に対し狭量であってはならない。過去に何があろうと、間抜けな人間をはじき出し、関係を止めるようなことをしてはいけない[McCarth95Rising96]

 チームによる設計で重要なのはシステムを開発し、設計する際の一致協力した取り組みである[Harrison96]。これは設計者とシステムテスターの関係にもいえることである。

 

早めの参加

問題

 システムテストにおいて設計者から出来る限り援助が欲しい。

フォース

解決策

 プロジェクトの初期に設計者と信頼関係を築きなさい。設計者と実際に交流が必要になるまで待ってはならない。そうなったときは既に遅すぎる。信頼は長い時間を掛けて少しずつ築かなくてはならない。

 よい関係を築く1つの方法は、設計者がシステムとその機能を学んでいるときにそれらを学ぶことである。要求と設計文書のレビューに参加すること。テスト計画のレビューに設計者を招くこと。

結果

 信頼関係を築くことによって、問題が発見されたときそれを解決するのが容易になる。設計者との関係は有能なシステムテスターとしての自分の判断には影響を与えないと信じなさい。友人がかかわっているとけんかになりそうな領域を避けるという傾向、また、設計者が近い友人であった場合、ある領域で問題が見つかったときその友人の責任ではないと思う傾向があるかもしれない。ある領域に関し情報を持ちすぎるのも危険である。それは客観的なブラックボックスの視点の代わりに領域に関する知識に依存したテストを生む可能性がある。

論理的根拠

 我々はみな出来れば自分の知っている人間と一緒に働きたいと考えている。互いになじりあってから初めて、もっと早く話し合っていればと思うのでは遅すぎる。信頼関係が既に確立されていれば、問題解決のプロセスはより円滑になる。

関連するパターン

 設計者は友人を確立するのにも早めの参加は重要である。

 

テストすべきとき

別名

テストすべきものがあるときテストしなさい

問題

 いつテストを始めるべきか。

状況

 システムは特性や機能といった最小限に依存し合うものに分割される。一度ある領域がシステムテストのために利用可能となれば、その領域は今後のシステムの稼働に影響されることはないであろう。設計者は友人であることを忘れないように。

フォース

解決策

 機能の1つがテスト可能となったらテストを始めなさい。それ以前であってはならない。その領域がテスト可能であると設計者と同意する必要がある(設計者は友人を見よ)。まだテストの準備が出来ていない領域は避けなさい。そうすることによってその領域で無駄な時間を使うこともなくなる。

結果

 テストがソフトウェアが稼働する初期の状態で始められれば、テストの時間は更に多くなる。これによってそのソフトウェアに対し、より多くのテストが行われることになる。このテストによって更に多くの問題が発見される。より多くの問題が早い段階で発見されれば、それらを訂正する時間が生まれることになる。

 初期の段階でのテストはその機能の回帰テストが必要となるというリスクを抱えている。このテストにはエンドユーザーの視点を用いなさい。更に、テストを余りに早く始めすぎると、修正はしたがテストは行っていない機能が本番製品に組み込まれる可能性がある。

論理的根拠

 システムテストはソフトウェアがすべて完成するまで始めるべきではない。しかし、すべてが完成するまで待っているとシステムテストを行う時間がなくなる。システムテスターには出来る限りテストを早く始めるよう圧力が掛かる場合が多い。しかし、システムのテストを早く始めすぎることは時間の浪費でしかない。とはいえ、システムの一部がほかの部分より早くテスト可能な状態であれれば、それをテストすることは可能である。

 

時間は掛かる

問題

 スケジュールの遅れている仕事を終わらせるためには設計者にどれだけ時間を与えるべきか。

状況

 ある領域のテストを開始する予定であるが、設計が完成していない。設計者は友人であることを思い出しなさい。

フォース

解決策

 設計者にはそれが正当なものである限り彼らの要求する時間を与えなさい。その間に別の領域をテストすればよい。

結果

 システムテストは設計がよければよいほど時間が掛からない。

論理的根拠

 品質の高いシステムは品質の低いシステムよりテストの時間が掛からない。設計者に彼らが本当に必要としている時間を与えることによって、最終的には、品質の低いシステムで発生する問題をすべてテストし修正するという無駄な努力をしなくてもよくなる。計画していた開発時間を15%増加させることによって欠陥の数を半減させた例もある[Remer96]時間は掛かるテストすべきときにおけるすべてのフォースはどちらのパターンに従うべきかを決定する前に注意深く検討する必要がある。

 

テスト効率

 この章で述べるように、システムを完全にテストしつくすということは出来ない。以下のパターンによってテスターはより欠陥の発生しやすい領域を見つけることが出来る。この領域にテストを集中させることにより、プロジェクトの初期の段階でより多くの問題を発見できる。

 

「未変更の」モジュール

問題

 社外で開発されたモジュールはどのようにテストすべきか。

状況

 社外で開発されたモジュールが全部若しくは一部、インタフェースの変更を行うことなくシステム内で使用されている。モジュールはGUI、ライブラリ、ハードウェアコンポーネント、その他、サードパーティーによる製品のいずれであってもよい。サードパーティーのモジュールを新しいシステムで使用する場合、同様のモジュールがほかのシステムで使われており、それに変更がないならば、テストは必要ないか、必要だとしても極めて限定されたテストで十分であると考えられている。

フォース

解決策

 システムテスターはモジュールに変更がないならば新しいシステムでも正しく動作するだろうという落とし穴にはまってはならない。システムテスターは社外から納入されたあらゆるモジュールに対し細心の注意を払わなくてはならない。この変更によってシステムテスター以外のだれかが直接影響を受けるというわけではないので、システムテスターはこのテストを率先して計画しなければならない。

 新しいシステムにおいてモジュールが正しく動作しているかを検証するテストは、そのモジュールがシステムに組み込まれたらすぐに開始すべきである。このテストはモジュールの機能を検証する。モジュールが新しいシステムで使えるようになったら、モジュールが提供する機能が今まで通りで、システムのほかの部分に影響を与えていないことを保証するために、すぐさまテストを始めるべきである。このテストは設計者が新しい機能を作っている間に行うことが可能である。

結果

 このテストによってプロジェクトの初期の段階で納入されたモジュールで発生する問題を発見し、システムのリリース時に発生する問題の影響を最小限にすることが出来る。これによって、システムがどう機能すべきか、システムに何を組み込むべきか、いつシステムをリリース可能とすべきかなどについて変更する時間が残されている間に、問題の修正に努力を集中させることが可能となる。システム開発全体に費やされる努力とストレスは軽減され、時間は節約され、システムは計画通りにリリースされるようになる。

論理的根拠

 どれほど製品の完成度が高くても、またどれほどよいコードであっても、もしそれが社内の製品でなければ、新しいシステムにそれを組み込む際に必ず問題が生じる。その機能のテストをすぐに始めなければ、問題は例外なく最悪のとき―システムのリリースの直前に見つかることになる。

 社外のいかなる製品も組織の求める品質、機能、顧客の期待を完全に満たすことはない。したがって、何らかの修正を行う必要が出てくる。

 

あいまいな文書

問題

 最少の時間で最も多くの問題を発見するには、問題が発生しそうな場所をピンポイントで見つけることが重要だが、それはどのようにしたら可能なのか。

状況

 特性の設計文書と(若しくは)ユーザーの文書が入手可能である。これは要求文書、設計文書、顧客文書のいずれであってもよい。

フォース

解決策

 システムについて入手可能な文書をよく読みなさい。あいまい若しくは明確でないように見える領域を探しなさい。それらの領域を出来る限りカバーするテスト計画を書き、それらの領域にテストを集中させなさい(エンドユーザーの視点を見よ)。設計者がある機能についてすべて説明できるなら、それは恐らく正しく動作するであろう。設計者が説明できないことについてはテストの際に注意が必要である。

 これらの領域で発生する問題はシステムテストの前に解決するほうが望ましいので、設計者の注意をこれらの領域に向けなさい。そのうえで、これらの領域は正しく文書化され理解されている領域よりも更に徹底してテストすべきである。

結果

 問題がより初期に発見され修正されやすくなる。

論理的根拠

 文書に1つ以上の解釈が存在するならば、設計者は1つ以上の解釈の出来るコードを書くであろう。この欠陥は初期に検出されなければ、システムテストの最後で見つかるであろう。早めの参加を行えば、文書は初期に修正され、正しく実装が行われる可能性が高くなる。問題が依然として存在するとしても、問題を早めに見つけることによって問題が修正される可能性は高くなる。よい仕様はすべての助けとなる!

関連するパターン

 文書のレビューは設計者は友人をより効果的なものとする。

 

過去の問題報告書の利用

問題

 最も多くの問題を最少の時間で発見するためには、システムのどの領域をテスト対象とすべきか。

状況

 既存の機能のテストが検討されている。以前のリリースの問題報告書が利用可能である。

解決策

 以前のリリースの問題報告書を調べなさい。それらはテストケースを選ぶのに役立つ。過去のすべての問題に対し再テストを行うのは非効率的なので、最新版のシステムの出荷後に報告された問題について調査しなさい。どの傾向が追加のテストのために選択されるのかを追跡できるように、問題報告書を分類しなさい。

結果

 以前から存在していた問題が発見され修正されるようになる。

論理的根拠

 問題報告書は以前のリリース時に検出できなかった何かがあることを示しているので、問題報告書は現在のバージョンで発生している問題を指摘するのに最適である。問題報告書は問題が常に発生する領域に集中する傾向がある。問題報告書が表す徴候は潜在的な問題と関連付けるのが難しい場合がある。

 更に、以前のリリースに対する修正は現在のリリースの新しい開発と並行して行われる場合が多い。これらの修正は現在のシステムに組み込まれるとは限らない。

 

問題領域

問題

 実装する機能にかかわらず、集中してテストを行うべきなのはシステムのどの領域か。

状況

 システムの過去のデータが利用可能である。

解決策

 永続的な問題領域とそれらを検証するテストケースの表を保存しなさい。それは単に現在の問題の解決のためだけではなく、今後のテストのためにも使われるものである。新しい機能を追加しなくても、それらの領域は徹底的にテストしなさい。これらのテストケースを使って定期的に再テストを行いなさい。リリースの直前でも再テストを行いなさい。これらの永続的な問題領域はシステムテスターの経験を考慮することによって識別可能である。過去の問題報告書あいまいな文書、設計者がリリースのたびに避けたがる領域などを利用しなさい。

結果

 問題領域をスケジュールの早い段階でテストすることによって、発見された問題に対しより多くの時間を修正に割り当てることが可能となる。

論理的根拠

 長い間問題を抱えてきたシステムの一部分が魔法のように一夜にして欠陥ゼロになることはない。ある問題はシステムのリリースのたびに発生する。ある領域はすべてのリリースで問題を抱えている。これらの問題と問題領域は常に追跡し、システムのリリースのたびに系統だった再テストの対象とすべきである。

 

テスト戦略

 テスト戦略を決定し、テストが始まっている状況を考える。テストの最中に生じる問題によっては発見が遅くて修正できなくなるものも存在する。以下のパターンによってそのような問題を早期に発見することが出来る。また、これらのパターンは、出荷時の製品が顧客の要求を満たすことを保証する。

 

ビジー状態のシステム

問題

 最も多くの問題を発見するためには、どのような状況のときにシステムテストを行うべきか。

状況

 トランザクションを妥当な数生成するシミュレーターが存在する。

解決策

 ビジー状態のシステムをシミュレートする環境でテストを行いなさい。トランザクションの数はシステムに負荷を与えるまではいかないが、システムが通常処理するようなレベルに近づけることが望ましい。

結果

 通常の状況で正しく動作するテストでもシステムがビジーな場合、おかしな振る舞いをしたり、失敗することがある。

論理的根拠

 ある機能に対して、システムテストのフェーズで既に通過したテストケースを実行するのは冗長である。しかし、これらのテストケースはシステムがビジー状態にあると失敗する場合がある。電話通信システムではシステムへの通話をシミュレートするトラフィック負荷シミュレーターを使ってシステムをビジー状態にすることが可能である。適度な量の負荷を与えてテストを行うことによって、システムが稼働していないときには現れない問題が発見される。

関連するパターン

シミュレーションを信用しない

 

シミュレーションを信用しない

問題

 テストシミュレーションを利用する際に、テスト環境はどのように設定すべきか。

状況

 システムの実稼働をシミュレートするシミュレーターを含めたシステムのシミュレーションが利用可能である。

フォース

解決策

 出来る限り実世界に近い環境でテストを行いなさい。

結果

 シミュレーションは予測可能な入力をシステムに与えることが多いため、システムが実世界を考慮に入れずシミュレーションのみを対象としていると、予想不可能な振る舞いのある実世界ではうまくいかない場合がある。実世界のテストでシミュレーションを補うことによって、そのような事態は最少化できる。

論理的根拠

 シミュレーションの適切な利用方法というものは存在するが、シミュレーションは実世界のテストそのものではない。テストの大部分がシミュレーションを使って行えるとしても、テスト計画に実世界のシナリオが存在しないならば、システムのテストは完全とはいえない。シミュレーターが100回テストケースを正しく実行できたとしても、予想外の行動をする一人の人間によってそのテストケースは失敗するかもしれない。

関連するパターン

  実世界のテストを達成するためにはエンドユーザーの視点に従いなさい。

 

エンドユーザーの視点

問題

 システムの新しい機能をテストしようと考えている。既に完了したテストを繰り返すことなくテストするにはどうしたらよいか。

フォース

解決策

 仕様が規定している範囲を超えたテストを行いなさい。エンドユーザーの視点を持ちなさい。機能テストのテストケースでシステムテストを行ってはならない。顧客の文書を用いなさい。機能の相互作用をテストしなさい。

結果

 エンドユーザーの視点でテストすることによって、システムの欠陥をシステムが出荷される前に発見し、修正することが可能となる。これらのテストは前工程のテストの範囲を拡大したものであり、冗長ではない。

論理的根拠

 エンドユーザーは設計されたとおりにシステムを使用するわけではない。設計者はシステムの各機能を開発するが、システムはエンドユーザーへのサービスを提供するために販売されているのである。これらのサービスこそがエンドユーザーの目に触れるものであり、エンドユーザーは設計者によって開発された機能を見ているわけではない。

 

異常なタイミング

問題

 ある機能に対して通常のテストは十分行っている。更にテストを追加したいが、その追加のテストはどのように行ったらよいか。

解決策

 異常なタイミングでテストを行いなさい。テストをシステムが期待しているよりも速い速度若しくは遅い速度で実行しなさい。実行途中でテストを中止しなさい。真のエンドユーザーは常にエンドユーザーの視点を持つ。

結果

 異常なタイミングによって引き起こされる欠陥が検出され、修正される。

論理的根拠

 通常のタイミングで正常に動作するものでも異常なタイミングでは失敗する可能性がある。異常なタイミングのテストは準備し実行するのが困難である場合が多い。しかし、実行するのが困難なテストケースこそが実行しなければならないものである可能性が高い。

 

マルチプロセッサ

問題

 マルチプロセッサシステムに対してシステムテストを行う場合、どのような戦略に従うべきか。

解決策

 複数のプロセッサにわたってテストを行いなさい。

結果

 1つのプロセッサで発生する問題は恐らくほかのプロセッサにおいても発生するであろう。あるプロセッサで通過したテストはほかのプロセッサでは失敗するかもしれない。

論理的根拠

 あるプロセッサで問題が発見されたとき、その問題が発生した機能は通常、ほかのプロセッサ上でも問題を抱えることが多い。駄目な機能はやはり駄目なのである。ある機能は1つのプロセッサで動作すれば、すべてのプロセッサ上で動作すると仮定して、1つのプロセッサ用に設計されるかもしれない。

 

引っかいて、においをかぐ

別名

問題群

問題

 テストが始まった場合、どのような戦略を用いれば、次にどのテストを行えばよいのかを決めることが出来るのか。

状況

 ある問題が既に発見されている。

解決策

 問題が既に発見されている領域をテストしなさい。

結果

 問題のある領域がすぐにテスト対象となり、問題はより早い段階で解決される。

論理的根拠

 問題は固まって見つかる傾向がある。ある領域で見つかった問題は、同じ領域に残っているほかの問題を発見するのに役立つ。引っかいて、においをかぎなさい―嫌なにおいがすれば、恐らくそのとおりなのだろう。

 ソフトウェアのバグはゴキブリのようなものである。1つ見つかったら、ほかにいくつも見つかるであろう。それらは同じように素早く進化する。

 初めのパスがシステムの広範囲をテストするようにテストを計画することは可能である。見つかる問題の半分はモジュールの15%に集中しているであろう[Davis95]。問題が起こっている領域に対して更に深くテストをすることによって、更に多くの問題が見つかるであろう。

関連するパターン

 更にテストが必要な領域に対して過去の問題報告書を利用しなさい。

 

奇妙な振る舞い

問題

 ある機能が動作はしているのだがそれが期待したものではない場合、何をすべきか。

状況

 システムテスターは製品の前回リリース時のシステムテストに参加しており、機能がどのような動作するのかよく知っている。

解決策

 異常な動作はどんなものであっても問題が存在する徴候として追及しなさい。これはその問題が現在行っているテストと関係していなくても行うべきである。異なった動作をする機能を探しなさい。何度も使用しているテストが異常終了ではないが予想外の結果を出力したときは気をつけなさい。

結果

 テスト結果の出力が期待した結果とそれほど大きな違いがない場合、問題が見過ごされることがあるが、そのようなことがなくなる。

論理的根拠

 機能を何らかの方法で変更した場合、それが正しく動作しているようであっても、機能の一部が破壊されている可能性がある。変更が計画的なものであれば、すべてのシステムテスターにそれを知らせる必要がある。

 

キラーテスト

問題

 開発中のシステムの品質はどのようにしたら決定できるのか。

状況

 開発は終わりに近づきつつある。システムは安定している。各機能は安定しており、すべての関係者、とりわけ経営陣はシステムがいつシステムがリリースできるかに興味を抱いている。

解決策

 いかなるときでも走らせることの出来るキラーテスト(通常テストケースの集合である)、すなわち問題を常に発見するテストを開発しなさい。このテストはシステムを幅広くカバーし、多くの場合、何らかの方法で失敗することが望ましい。キラーテストはほかから借りてくることも出来るが、テストの効率性はシステムに対する個々の技能と知識に依存するので、自分自身の経験に基づいたテストのほうが望ましい。

 キラーテストは最終リリースのみ用いられ、通常の回帰テストの上位に位置するものである。このテストは多方面にわたるものであり、一般に文書化が困難である。テスターはテストケースよりも重要であるため、この形式のテストが成功するかしないかはテストを実行する個々のテスターの能力に依存する。このテストを行うのにリリースの直前まで待ってはならない。そのようなことをしていると問題を修正する時間がなくなる。

結果

 テストの結果をシステムの安定性に対する評価基準とすることが出来る。キラーテストによって明らかになった問題を見つけ修正することによって、徐々に安定したシステムとなる。

論理的根拠

 キラーテストのように通常は失敗し、実行にはそれほど長い時間が掛からないテストによって、システムがどれほど安定しているかを調べることが出来る。くわえて、この形式のテストは問題が発見されやすいので、効率も高い。

 

問題解決

 以下のパターンはコミュニケーションと問題解決に役立つ。

 

問題の文書化

問題

 テストにおいて発見された問題をどのようにして伝達すべきか。

状況

 問題文書のために問題追跡システムが利用可能である。

フォース

解決策

 問題報告書を書きなさい。設計者と言い争ってはならない。結果が出るか出ないか分からないような善意の約束は受け入れてはならない。非公式に問題を文書化してはならない。各人は個人的な問題リストを持つべきではない。

 問題を文書化することによってテスターが不利になるようなことがあってはならない。問題が文書化されたことによって設計者が罰せられるということも避けなくてはならない。

 問題を設計者に報告する前によく考えなさい。何が起こったのかを説明できると信じなさい。設計者は常にシステムのデバッグ出力を見たがるので注意しなさい。

結果

 問題追跡システムにおいて文書化された問題は、適切なタイミングで解決される確率が高くなる。

論理的根拠

 たとえ面倒で扱いにくくとも、入手可能なツールはすべて利用しなさい。問題を完全かつ公式に文書化することによって、情報は失われることなく、適切なタイミングで解決されることが高くなる。

 問題の文書化は常に後回しにされがちである。文書化を後回しにすることはそれによって解決できることより多くの問題を生み出す。それによって、結局は問題の解決より何が問題なのかを決定するのに長い時間を取られることになる。

関係するパターン

 設計者は友人であることと早めの参加を忘れないように。

 

問題は養子

問題

 何度も起こる問題を効率的に解決し、テストを生産的なものにするにはどうしたらよいか。

状況

 問題が明らかになったが、はっきりとした解決策がない。問題を解決するにはかなり苦労しそうである。下手をすると解決できないかもしれない。このパターンがうまくいくためには設計者は友人のパターンが必要である。

フォース

解決策

 問題は養子のようなものである。問題を自分の子供だと思いなさい。難しい問題を見つけたら、解決するまで離れないようにしなさい。問題を文書化しなさい。問題についてもっと多くのデータを集められるように、問題を定期的に再テストしなさい。問題に対して責任を持てるような設計者になりなさい。

結果

 問題の解決が進むにしたがって、設計者はシステムテスターが問題の解決に関心を持っていたことが分かってくる。システムテスターが中心となって問題を解決することによって、設計者が問題をああだこうだということがなくなる。定期的に問題を再テストすることによって、問題を更に理解し、より問題の本質に近づいたデータを得ることが可能となる。その結果、設計者が問題を解決し、しかるべきタイミングで解決策を提示してくれる可能性が高くなる。

 問題を解決したら、その修正を保証するために再テストを定期的に行いなさい。もし同じ問題が再発したら、そこは問題領域の可能性がある。

論理的根拠

 設計者にはしなくてならないことが沢山ある。設計者は自分がよく分かっていることや簡単なことを優先にしがちなので、難しい問題の解決は後回しにされやすい。問題を養子として考えることによって、2つの種類の人間が問題を解決することになる。システムテスターとしては、問題について更に情報を得るために問題をテストし、デバッグすることになる。その情報は設計者が求めるものである場合もあるし、以前集めたデータとは異なったものである場合もある。また問題に注目することによって、問題を解決することは重要であると考えていること、問題解決のためには助力を惜しまないことなどを設計者に伝えることが出来る。この2番目の点が重要である。なぜなら、システムテスターがうるさくてどこかに行って欲しいような存在として設計者の頭に浮かぶようになってはならないからである。設計者はシステムテスターを問題解決の協力者として考えて欲しいのである。問題がいらいらにならないように気をつけなさい。

 

いらいら

問題

 問題の妥当性について、開発の進行が止まるほどの論争が行われている。どのようにしたら論争を終わらせることが出来るか。

状況

 この問題は問題は養子問題の文書化と同じ状況で発生する。

解決策

 問題を養子にすれば、問題は設計者側を悩ますものではなくなると信じなさい。未解決の問題に極度に関心を持たないようにしなさい。証拠となるような文書がない場合は特にそうである。プロのレベルで議論しなさい。

 問題の状況が開発の進行を阻害するようなレベルに達した場合、システムテスターは分析者のような第3者に頼んで、この窮地を救ってもらう必要がある。この場合、問題の状況を追うのを止めて別の領域のテストを始めたほうがよい。余りに早く第3者を巻き込むのは避けること。

結果

 問題は解決され、忘れられることがなくなる。しかし、ある問題に対し、システムのほかの部分をそっちのけにするほど関心を持つということはなくなる。

論理的根拠

 問題を養子にすることによって、システムテスターは特定の問題に関心を持ちすぎてそれがいらいらとなってしまう場合がある。極端に走りすぎると、せっかく築いたシステムテスターと設計者のよい関係を破壊してしまうことになりかねない。システムの問題はシステムテスターだけが考えるべきではない[Davis95]

 

使用例

 本パターン・ランゲージを生み出したのはAG Communication SystemsGTD-5若しくはほかのプロジェクトで数年システムテストを行ってきた人々である。GTD-5は過去16年にわたり何度もメジャーバージョンアップを繰り返してきた局用電話交換機である。GTD-5での経験はほかのプロジェクトでもいかされ、本パターン・ランゲージの意義を立証できた。GTD-5やほかのプロジェクトの中には本パターン・ランゲージのうち1つでも欠ければどのような結果になるのかを身をもって味わったものもある。これらのパターンの多くはほかの企業においてもリアルタイム組み込みシステムを開発する際に使用されていた。AG Communication Systemsとその製品について更に情報が欲しいかたは(URL)http://www.agcs.comにアクセスして頂きたい。

 

謝辞

 ここで述べたシステムテストのパターンは1996510日に開かれたパターンマイニングワークショップで生み出されたものである。パターンランゲージとして完成させたのはDavid DeLanoLinda Risingであり、Greg Stymfalがまとめ役として2人を助けた。ワークショップに参加したAGCSのシステムテスターは以下のとおりである。Dave BassettArvind BhuskuteBob BiancaRay FuHubert FulkersonEric JohnstoneRich LamarcoKrishna NaiduEd Nuerenbergand Lori Ryan。彼らの多くはパターンのレビューアーとして参加した。また、以下の人々もパターンのレビューを行ってくれた。John BalzarTerry BartlettErnie EnglehartCarl GilmoreNeil KhemlaniJim KurthBob NationsJohn NgJim PetersonMike SapcoeBill StapletonFrank Villarsand Weldon WongDave Strandには引っかいて、においをかぐの名前を提案してくれたことに感謝している。

 「未変更」のモジュールDavid DeLanoLinda Risingが開いた初期のパターンライティングコースでMike Sapcoeが書いたパターンを改良したものである。

 本パターン・ランゲージのシェファーディングに時間と労力を割いてくれたRalph Johnson Neil HarrisonBrian Marickに感謝する。また、本パターン・ランゲージに対し、たくさんの貴重なコメントをくれたPLoP'96ライターズ・ワークショップの参加者にも感謝する。

 

参考文献

[Cockburn96] A. Cockburn. "A Medical Catalog of Project Management Patterns." Submitted for PLoP96 (URL: http://members.aol.com/acockburn/papers/plop96.htm), 1996.

[Coplien95] J. O. Coplien. "A Generative Development—Process Pattern Language." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 183-237.

[Davis95] A. M. Davis. 201 Principles of Software Development. New York, NY: McGraw-Hill, 1995.

[DeMarco+87] T. DeMarco and T. Lister. Peopleware: Productive Projects and Teams. New York, NY: Dorset House, 1987, pp. 45-47.

[Gamma+95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.

[Harrison96] N. B. Harrison. "Organizational Patterns for Teams." In J. M. Vlissides, J. O. Coplien and N. L. Kerth (eds.), Pattern Languages of Program Design 2. Reading, MA: Addison-Wesley, 1996, pp. 345-352.

[McCarthy96] J. McCarthy. "#4: Don't flip the bozo bit." In McCarthy, Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995, pp.23, 30, 32.

[Olson95] D. Olson. "Don Olson's Patterns on the Wiki Wiki Web." Portland, OR: Portland Patterns Repository (URL: http://c2.com/cgi/wiki?search=DonOlson), 1995.

[Remer96] D. Remer. "Cost and Schedule Estimation for Software Development Projects." UCLA, 1996, pp. SW 11-8, Guideline #35.

[Rising96] L. Rising. "Don't Flip the Bozo Bit." Phoenix, AZ: AG Communication Systems Patterns web page (URL: http//www.agcs.com/patterns/BozoBit.html), 1996.

David DeLano and Linda Rising can be reached at delanod@agcs.com and risingl@agcs.com, respectively.

訳者注Linda Risingは既にAG Communication Systemsを退社しており、上記メールアドレスは無効です。