Windows アプリケーションの探索的テスト プロシージャ
トピック
探索的テスト入門
機能の扱い
機能性と安定性のテスト
このプロシージャの読み方と利用方法
テスト プロシージャ
目的 : よく寄せられる質問
機能 : よく寄せられる質問
不安定性 : よく寄せられる質問
問題点と疑問 : よく寄せられる質問
問題点のテストと記録 : よく寄せられる質問
このドキュメントでは、ソフトウェアアプリケーション (以降「製品」として参照) が開発中の Windows バージョンでも期待通りの動作をするかどうかを検証する目的で、機能性と安定性をテストするためのプロシージャを記述しています。このプロシージャ (以降「プロシージャ」として参照) は製品を総合的にテストするものではないため、正式なテスト計画と置き換えないことをお勧めします。その代わり、Windows の新バージョンでも、ほとんどのユーザーが既存製品を問題なく使えることの検証を限られた時間内で試みます。このプロシージャは、Windows 2000 対応アプリ認定プログラム向けに James Bach が開発した「汎用機能と安定性のテストプロシージャ」に基づいています。 [1]
このプロシージャでは、テストに探索的アプローチを採用するため、テストケースが事前に定義されていることはなく、どちらかというと製品を学びながら定義し、実行していきます。ゼロから出発して迅速に製品をテストする場合には最良のアプローチなので、この探索的アプローチを選んでいます。
このドキュメントは次の 5 つのセクションから構成されています。
探索的テスト入門
機能の扱い
機能性と安定性のテスト
このプロシージャの読み方と利用方法
テストプロシージャ
最初の 3 セクションでは、プロシージャに関係する背景と概念を説明します。4 番目のセクションでは、プロシージャに必要な情報の取得方法をアドバイスします。5 番目のセクションでは、プロシージャ自体について説明します。
探索的テスト入門
このプロシージャでは、製品について一通りの知識を得て、どんな製品であるかを理解してから、テストを行います。テストに対するこのアプローチは、探索しながらテストをするため、探索的と呼ばれます。探索的テストは対話的なテストプロセスです。これはある意味で自由形式プロセスであり、アドホックテストまたは直感的テストと呼ばれている非公式なテスト形態と多くの共通点があります。しかし、従来の非公式なテストとは違い、このプロシージャには、決まったタスク、目的、提供物があるので、システマチックなプロセスになっています。
運用上の用語では、探索的テストは平行して製品探索、テスト設計、およびテスト実行を行なう対話的プロセスになっています。探索的テストセッションの結果としては、製品に関するメモと見つけたエラー、およびテストケース概要 (TCO と呼ばれ、製品の主要機能のテスト方法を簡潔なステップで記述) が得られます。訓練を受けたテスト担当者がテストすると、一貫し、貴重で、しかも監査に耐える結果が得られます。
探索テストの要素を示します。
製品探索
製品の目的と機能、処理するデータタイプ、および潜在的な不安定箇所を見つけだして記録します。製品探索をうまく実行できるかどうかは、技術の一般的な理解度、製品と想定ユーザーに関する情報量、および仕事に割く時間量に依存します。
テスト設計
製品の操作、観察、および評価方法を決定します。
テスト実行
製品を操作し、動作を観察し、その情報を元にして製品の動作原理に関する仮説をたてます。
ヒューリスティックス
ヒューリスティックスは何をすべきかを決めなければならない場合のガイドラインまたは経験則となるものです。このプロシージャでは、いくつかのヒューリスティックスを採用して、何をテストし、どのようにテストするのかを決めるのに役立てます。
レビュー可能な結果
探索的テストは結果指向のプロセスです。指定要件を満たす成果物を作成したら完了です。テスト結果はレビューできて、正しさを説明できることが特に重要となります。テスト担当者として、作業のあらゆる面をテストマネージャに説明できるように準備する必要があります。また、プロシージャに記述されている要件を満たしていることを示せる必要があります。 [2]
機能の扱い
このプロシージャは機能を中心にまとめてあります。機能と呼んでいるものは、ソフトウェアの動作と関係するものです。機能に入れるものは、表示を作り出すもの、内外のデータを変更するもの、または環境に影響を与えるものです。機能には多くの場合、サブ機能があります。たとえば、Microsoft WordPad の印刷機能には、部数指定とページ範囲指定機能があります。
製品のすべての機能はテストできないので、どの機能をどの程度テストしていくかというリスクを設定してテスト問題を単純化していきます。これにはまず、製品内の機能を洗い出して、プライマリタイプと貢献タイプのカテゴリに分類します。プライマリ機能のドキュメント作りとテストが作業の大半を占めます。概要レベルの作業における機能の分割とグルーピングは、状況に応じた意志決定作業となります。(最終的にはテストマネージャの決断になりますが) 独自の裁量で、貢献タイプの機能グループを 1 つのプライマリ機能として扱っても、1 つのプライマリ機能をプライマリタイプのサブ機能と貢献タイプのサブ機能に分割してもかまいません。
可能ならプライマリ機能をすべてテストしても良いのですが、それだけの時間はないでしょう。この場合には、どのプライマリ機能をテストして、どれをテストしなかったのかをメモに残しておきます。
機能によっては、ユーザーインターフェイスを見ただけでは機能の判定が難しいこともあり得ます。オペレーティングシステムまたはそれ以外のプログラムと直接に対話する機能、またはファイルを修正する機能の中に、画面上では見た目に変化がないものがあります。製品内に半分隠れている重要な機能を見逃さないように気を付けるようにします。
機能カテゴリは以下のように定義されています。
定義 |
注 |
|---|---|
プライマリ機能 普通のユーザーの立場から見て、動作不能や欠陥があると、製品としての用をなさない重要な機能。 |
製品の目的と関連付けることができ、しかもその目的には無くてはならない場合に、その機能はプライマリであるといいます。 プライマリ機能は製品を定義します。たとえば、Microsoft WordPad でドキュメントにテキストを付加する機能は、その機能がないと製品としては使い物にならないので、間違いなく重要な機能です。機能群をグループとして、まとめて扱うと、プライマリ機能になることもあります。たとえば、WordPad のダイアログボックス内の個々の機能には、プライマリ機能とみなせるものはなくても、「オプション変更」機能全体としてはプライマリ機能となります。もしそうならば、製品としてテストに合格するには、このダイアログ ボックスの機能のほとんどが正常動作しなければなりません。 |
貢献機能 製品の有用性には貢献するが、プライマリ機能ではない機能。 |
貢献機能はプライマリではないものの、問題を発見した場合には報告しなければなりません。普通は貢献機能をすべてテストする時間がないので、問題をすべて見つけ出すことはできません。このプロシージャでは、これで問題はありません。定められたテスト時間内にできるだけ多数のプライマリ機能をテストするのが主な目標だからです。 |
機能がプライマリであるかどうかを判定するには、製品の目的を知ることが最初のキーとなります。そして目的を知るには、目的を推定、推測できるだけの信頼できる情報源を持っている必要があります。次のキーは機能が重要であると知っていることです。これは通常のユーザーのレベル、問題の機能の動作、および製品内の他の機能の動作をどれ位知っているかに依存します。
機能性と安定性のテスト
製品を Windows の新バージョンでたいていのユーザーの期待通りに動作させるのが、使命－言い換えれば、このようなことをする理由－です。これはとりもなおさず、製品が基本的に機能し安定している必要があることを意味します。この評価には、特定の機能性評価基準を適用する必要があります。
この評価基準を以下に定義します。
定義 |
合格基準 |
不合格基準 |
|---|---|---|
機能性 製品が機能する能力。 |
1. テストする個々のプライマリ機能について、出力結果の正確さとは無関係に、明らかに目的との一貫性を持って動作すると認められます。 |
少なくとも 1 つ以上のプライマリ機能が、目的と一貫した動作をしていません。 |
- |
2. 製品には不正確な動作が見られますが、どれも通常の使用を著しく損なうものではありません。 |
製品に見られる不正確な動作は、通常の使用を著しく損なうものです。 |
安定性 製品の全機能範囲にわたって、長期に使い続けても、障害になることも、障害を引き起すこともなく、動作し続ける能力。 |
3. 製品は Windows に悪影響を与えないと判断できます。 |
製品は Windows に悪影響を与えると判断できます。 |
- |
4. 製品は、ハング、クラッシュ、およびデータ破壊を起こしません。 |
製品は、ハング、クラッシュ、およびデータ破壊を起こします。 |
- |
5. どのプライマリ機能も、テスト中に動作不能や不具合を引き起こしません。 |
少なくとも 1 つのプライマリ機能が、テスト中に動作不能や不具合を引き起こします。 |
機能性標準は最も要求の厳しい標準で、製品には全くなじみがなく、短い時間で作業をこなすテスト専任者がまともに確認作業を行えるように、念入りに作られます。「明らかに」という言葉は、「通常のコンピュータスキルを有するテスト担当者に明らか」という意味になります。テスト担当者としては、プログラムが「正しく」動作しているとまで言える必要はありません。しかし、製品を著しく損ねるほどに、製品が正しく動作していないと言えるなら、製品はテストに不合格となります。
製品が通常の使用方法を著しく損ねるかどうかを知るには、通常のユーザーがどのような人で、通常の使用方法がどのようなものかの見識を備えている必要があります。多くの場合、通常のユーザーとは基本的なコンピュータスキルを有している人、言い換えると通常のテスト担当者と良く似た人と考えてかまいません。ただし、通常のユーザーは、ある意味で特殊な属性、スキルを持った人、または期待できる人という場合もあります。
安定性のテストを実施するには、製品が処理できる基本的なデータ種別も明確にして概要をつかんでおく必要があります。潜在的に不安定と思われる箇所のテストを行う際には、このデータの知識を利用して、難しい入力を処理するテストを設計する必要があります。
テストのカバレージ
テストカバレージとは「テスト対象」を意味しています。このプロシージャでは、以下のテストカバレージが必要です。
与えられた 時間内に問題なくテストできるプライマリ機能をすべてテスト。
テストする時間も能力も持ち合わせていないプライマリ機能が残っていることを、テストマネージャが承知していることを確認しておきます。
興味深い貢献機能のサンプルをテスト。
プライマリ機能の探索とテスト中に、多数の貢献機能に触れていると思われます。
潜在的に不安定な箇所を選んでテスト。
テストマネージャから、製品の中で最も不安定になりそうなテスト箇所を尋ねられることがあります (この場所には 1 つの機能または複数機能が対応)。
情報源とオラクル
製品の機能についてはどのようにして知りますか。製品がうまく動作していないことを、どのようにして認識しますか。このような疑問は難しくて、すぐには答えられません。しかし、テストマネージャが納得する答えを見出すのに、情報源とオラクルの概念が有効です。
情報源。 情報源とは、情報の出所のことです。情報源は、製品に対する考えを正当化するものでもあります。情報源が自分の直感や経験であることもあります。幸いなことに、少なくとも製品マニュアルを利用できるか、または適切な経験を得られる状態であると思われます。
オラクル。 オラクルとは、製品の見かけ上の動作が正しいのか正しくないのかを決定する方法の 1 つです。オラクルとは、「正しい答え」を知るための工夫です。オラクルは「うまく動作していることをどうやって知ったのか」という問いに対する答えです。オラクルをうまく見つけて推論するのには慣れが必要です。オラクルが重要なのは、オラクルを使えばどのような種類の問題を発見して報告できるのかを把握できるからです。
情報源とオラクルについて推測し、報告する能力は、テストプロシージャを遂行する資格とも大いに関係があります。テストマネージャの仕事の助けにもなります。オラクル戦略が的確でないと、製品が全くうまく動作していない場合にも、うまく動作していると思いこんでしまうおそれがあるためです。
オラクルの簡単な例は、次のような原理で示せます。「フォントサイズ12 ポイントで印刷すると、 8 ポイントよりも大きく印刷できます」、または「Microsoft Word でテキストが正しくフォーマットできているように見えるなら、WordPad でもテキストは正しくフォーマットできます」。
オラクルの一般的なパターンには、一貫性のあるヒューリスティックスと呼んでいるものがあります。これは次のようなものです。
目的との一貫性 : 機能動作が明らかに目的と一貫しています。
製品内での一貫性 : 機能動作が、製品内の比較可能な機能の動作、または機能パターンと一貫しています。
履歴との一貫性 : 現在の機能動作が過去の動作と一貫しています。
比較可能製品との一貫性 : 機能動作が比較可能製品の類似機能と一貫しています。
正しい動作の知識があまりなくても、製品としての矛盾点に基づく正しくない動作は指摘できます。
このプロシージャの読み方と利用方法
このプロシージャは、一歩一歩進めていくプロセスとは違い、「行きつ戻りつ」するプロセスのパターンに従います。つまり、すべてのタスクが完了するまで、異なるタスク間を行ったり来たりすることを意味します。各タスクは別タスクにある程度の影響を与えるため、各タスクは多少並列気味の動作になります。すべてのタスクが完了すると、プロシージャ全体が完了します。
行きつ戻りつのプロセスは、コントロールまたは検索を行う状況で役立ちます。たとえば、誰でも思いつく行きつ戻りつのプロセスとしては、車の運転があります。運転する際に、速度計をチェックするタスクは、プロセス内で順を追って行うステップではなく、操舵のような別タスクとの平行タスクになります。どこかへドライブに行く場合は、運転者は現在いる場所から進行方向に進むことを考えるだけでなく、行きたい場所から戻ってくることも考えます。探索的テストは、ある意味ではドライブのようなものです。ドライブと同じく、スキルを得るのに時間がかかり、トレーニングと練習が必要です。
タスク シート
このプロシージャは 4 つのタスクから構成され、後ろのテストプロシージャセクションに説明が書かれています。各タスクは次の要素を織り込んだタスクシートで記述します。
タスク説明。 各シートの最初にある、タスク説明はこれから行うことを簡潔に記述したものです。
ヒューリスティックス。 各シートの中央部分にはアイデアリストがいくつか用意されています。これをヒューリスティックスと呼びます。ヒューリスティックスは何をすべきかを決めなければならない場合のガイドラインまたは経験則となるものです。これは「完了」する必要があるサブタスクではありません。むしろ、思考を刺激し、集中させることを意図しています。ヒューリスティックスの使用方法は、アイデアを順に簡単に試してみて、テストしている製品への適用方法を考えることです。たとえば、目的の識別タスクの場合には、目的に使える動詞の一覧があります。一覧にあるアイデアの 1 つは「解決する、計算する」です。これを見た時に、製品は何かを解決するのが目的か、または何かを計算するのが目的かと考えてみます。製品にこのような目的があるなら、「各種数学計算の実行」を含んだ目的文を書けます。製品にこのような目的がなければ、肩をすくめて次に進みます。
結果。 各シートの左下には、タスク結果として提出すべきリストがあります。
次のようなときに完了したと言えます。 このようなプロシージャにとって、重要な問題とは、完了したことを、どのようにして認識するかということです。したがって、完了するには「真」でなければならない事柄の一覧が各タスクシートの右下にあります。言い換えると、左下の一覧に従って、結果と呼ぶものを単に作っていくだけでは十分ではありません。右側の文章一覧の正しさを主張する準備もしていく必要があります。これらの文のほとんどがある程度主観的判断を必要としますが、完全に主観的なものは 1 つもありません。
よく寄せられる質問。 各ページの反対側 (このドキュメントは両面印刷を想定した設計になっています) には、テスト担当者が初めてタスクを手がける際に持つと想定される、疑問点に対する回答一覧があります。
テスト マネージャの役割
テストマネージャはテストプロセスの品質に最終的な責任を負います。テスト方法に疑問の声があがった場合には、テストマネージャは実施済みテスト作業を保証するための準備を行う必要があります。この理由から、問題点や疑問をテストマネージャに報告することは、テスト担当者の重要な役割となります。
問題点と疑問
作業中に問題点や疑問を持つと思います。作業の流れを中断せずに、すぐに問題や疑問を解決できないようなら、メモを作成しておき、後から解決を試みます。具体的な疑問、一般的な疑問、決定しないといけない事だけでなく、テスト遂行能力に悪影響を与えた出来事や状況の発生が、これに相当します。
遭遇した問題や疑問を書き留めておくのは大事なことです。製品をテストしている他のテスト担当者がこのメモを活用できます。あるテスト担当者が遭遇した問題を見ることで、他のテスト担当者はテストの良いスタートを切ることができます。問題点を書き留めていくことで、テストの進め方に対するテストマネージャやメモをレビューする人の理解力が高まっていきます。
問題を報告するタイミング
次のような状況では、テストマネージャに進め方を尋ねます。
テストタスクのいくつかを完了させられない障害に遭遇。
製品が複雑なため、自分を見失い、混乱。
与えられた時間内では、テストの実施に十分な製品知識を得られないと感じている。
製品が複雑なため、テストには当初の割当て時間よりも多くの時間が必要なことが確実と感じている。
時間の制約のプレッシャーがあるテスト
製品のテストに割り当てる時間数は複雑度で変化しますが、日単位ではなく、時間単位です。4 つのタスクすべてを割当て時間内に完了させることが目標になります。この目標を達成するアイデアがいくつかあります。
テスト可能か どうかが最初の疑問になります。 あまりにも複雑で尋常ではない製品の場合には、成功することはないと考えられます。このテストプロシージャのきついスケジュールをこなして、良い仕事をするために、まず、仕事ができるものかどうかを判定する必要があります。
5 つのタスクすべてを、一通り調べます。 1 つ 1 つを調べて、どこに問題が集まっていて、どこが複雑なのかの感覚をつかみます。一般的に、このプロセスで最も骨が折れるところは、製品機能を識別してカテゴリ分けするところです。
20 ～ 30 分ご とに休みます。 進捗を見積もり、メモをまとめ、疑問への答えをもらいます。
1 つのタスクに行き詰まったら、別のタスクに取り組みます。 2 番目のタスクに取りかかることで、最初のタスクに関する疑問の解消の助けになることがあります。たとえば、製品のメニューを一通り眺めることで、製品の目的を解明できることがあるものです。
困難な問題への挑戦。 難しい部分を解決すると、他のすべても速く進むことがあります。また、ひやりとさせられるような問題があるのなら、早く解決するのが望ましいと思われます。逆に、簡単なタスクを片づけていけば進捗がはかどり、残りの仕事をこなす準備もできるので、難しい問題を後回しにできます。
メモを片づける時間をとっておきます。 探索的テストの最後 30 分程度は、配布するメモと結論を準備し、テストにやり残しがないかどうかの最終チェックを行うために取っておきます。
先に進みます。 重大な問題や障害に遭遇しない限りは、プロセスを続けていきます。プロセスの流れに乗って先へ進みます。疑問と問題を書き留めておき、発生時点で対処せず、後でまとめて対処します。
基本指令 (Prime Directive) : 慎重かつ組織的に
テストプロシージャを通じて、タスクを完了する限りは、仕事の進め方にはかなりの自由が認められています。しかし、プロセスの流れにそって組織的に作業する必要があります。各タスクの結果作成中に、相当量の推測をする必要がありますが、中には間違っている推測があるかも知れません。そこで、考える必要があります。製品の動作原理、どの機能がプライマリで貢献タイプなのか、またはそれ以外について、自分自身が根拠のない無教養な推測をしていると感じた場合は、ただちにテストマネージャに相談してください。
テスト プロシージャ
以下の 5 つのタスクを完了しなさい。
製品の目的を明らかにします。
機能を明らかにします。
潜在的に不安定な箇所を明らかにします。
問題点と疑問を明らかにします。
テスト ケース概要 (TCO : test case outline) を作成します。各機能をテストし、問題を記録するのに使用します。
提供物 |
次のようなときに完了したと言えます |
|---|---|
|
|
製品の目的を明らかにします。
製品をレビューし、どのような基本サービスを提供するものなのかを把握します。できる限り、製品の利用者を定義します。
製品の目的と、想定される利用者を簡単に説明する段落を書き (または編集し) ます。
文中で目的を表す動詞として使用される可能性があるもの
保存する、取り出す
作成する、編集する
表示する、分析する、報告する
印刷する
解決する、計算する
管理する、監督する、制御する
通信する、相互運用する
データを用意する、アクセスを提供する、検索する
サポートする、保護する、維持する
クリーニングする、修正する、最適化する
読み取る、フィルターをかける、言い換える、変換する
知らせる、教育する、助ける
構成する
探索する
自動化する
楽しむ
文中で話題にする価値のあるユーザー属性
特殊スキル、知識、能力、または欠陥
トラブルシューティング能力
期待または必要性
制約 (この製品を使わないユーザー、というカテゴリはありますか)
提供物 |
次のようなときに完了したと言えます |
|---|---|
|
|
目的 : よく寄せられる質問
このタスクがなぜ大事か。
製品の目的を理解していなければ、プライマリ機能と貢献機能を区別できるとは言えません。そして、この区別を付けられることがキーとなります。テスト作業のほとんどがプライマリ機能のテストに費やされるからです。エッセーを書く必要はありませんが、プライマリ機能だと考えるほどに重要な機能は、この目的の文にまで戻って判断できるように、かなり詳細に書いておく必要があります。
目的の文はどのように書くのか。
ベンダーが用意している製品説明があれば、これに必要に応じて肉付けしていきます。自分自身で書く必要があれば、「簡単なテキストドキュメントを編集する」または「法的書類に関する訓練を受けていないユーザーからの情報に基づいて法的ドキュメントを作成する」のように、名詞 (～を)＋動詞（～する）の形式にします。また、製品の通常ユーザーの特性を示す特別な属性があれば、はっきり述べておきます。
目的を示す動詞のリストは、すべて、典型的なソフトウェアをレビューして取り出したものです。これがあれば、以前なら見逃していた、製品の目的に気付くようになるかもしれません。目的を示す動詞で似た使い方のものは、スペース削減の目的もあって、(計算する、解決する、のように) まとめて示してあります。一緒に使用すべき動詞、という意味ではありません。
目的と機能はどのように異なるのか。
目的はユーザーのニーズと関連します。機能は、製品が作り出すか、実行する具体的なものと関係します。
印刷のように、機能目的と機能名が同じものもあります。印刷は印刷機能の目的です。たいていの場合、機能の目標は見つけだせるものよりも一般的なものになります。たとえば、ワードプロセッサの目的はテキストの検索と置換ではありません。検索と置換はドキュメントの編集作業の一部です。編集が真の目的になります。一方、「スーパー検索と置換プロ」という仮想的な製品では、検索と置換機能が製品の目的であることは予想されます。
機能を明らかにします。
製品をウォークスルーして、何をするものかを発見します。
すべてのプライマリ機能の概要を作成します。
興味深い貢献機能またはプライマリとの境界にある貢献機能を記録しておきます。
分類方法が分からない機能や、テストできない機能は、テストマネージャの判断に委ねます。
機能を探す方法
ベンダーの製品広告を調べます。
製品の一部になっている印刷物を調べます。
オンラインヘルプを調べます。
製品を構成する全プログラムを調べます。
製品メニューをすべて調べます。
ウィンドウをすべて調べます。
ツールバーを調べます。
ダイアログ ボックスとウィザードをすべて調べます。
すべてのデータオブジェクト、インターフェイス要素、およびウィンドウで右クリックします (ショートカットメニューが見つかります)。
すべてのデータオブジェクト、インターフェイス要素、およびウィンドウをダブルクリックします (隠れた機能を引き出します)。
製品が機能に用意しているオプション設定で、(Microsoft Word の自動文法チェックのように) スイッチをオンにすると有効になるものを調べます。
ある種の入力でのみ起動される機能を調べます (JPEG 画像での保存を選ぶと、JPEG オプションウィザードが起動されます)。
製品と共に提供されるサンプルデータを念入りに調べます。
他の機能に埋め込まれているエラー処理と回復機能を調べます。
機能分類
プライマリ機能 : 普通のユーザーの立場から見て、動作不能や欠陥があると、製品としての用をなさない重要な機能。
貢献機能 : 製品の有用性には貢献するが、プライマリ機能ではない機能。
提供物 |
次のようなときに完了したと言えます |
|---|---|
|
|
機能 : よく寄せられる質問
このタスクがなぜ大事か。
製品の操作を構成する機能一覧を作成することで、テスト可能なものの概要を作成できます。テストを完了すると、この概要は製品の理解度と、テストしたものとの指標になります。また、この概要はテストマネージャと、将来、この製品をテストするテスト担当者が使用するための重要な記録になります。
何がプライマリ機能なのかが、全く混乱して分からなくなったらどうしますか。
適当に選択をせず、テストマネージャに相談します。テストマネージャはベンダーに連絡を取って、情報やドキュメントを見つけてくれます。または、何をすべきかのヒントをくれます。
どのフォーマットで機能を記録すべきですか。
簡単なものにします。2 ～ 3 段階で記述する概要にします。
機能または機能分野ごとに 1 行の箇条書きで記録します。機能は公式な名前またはラベルを持っていないことがあります。この場合には、名前を考えて、角括弧に入れて、名前を作ったことを証明します。
機能を提供するベンダー名、または機能セット名は、アクション (動詞) のかわりにカテゴリ (名詞＋形容詞) になります。必要とあれば、括弧内に言葉を追加して、製品内のカテゴリ名を適切な機能名に変更します。たとえば、製品には「地図」というメニューがあり、市、州と郡の項目が付随しているとします。実際の機能は「地図 (この中のそれぞれの・・・を見てください) 」です。
1 つのファミリに属する機能が 100 あれば、1 つずつ一覧にしていくのではなく、「描画機能」のようなグループ名の一覧にします。
貢献機能が判定できるなら、プライマリ機能とは明確に区別します。
たとえば、以下に Microsoft Bookshelf の機能概要の一部を示します。
注
最近調べた項目の追加
削除
移動
注釈 (を作成)
(以下の) 全検索
[結果一覧]
～に関する項目
特定の語句を含む項目
メディアの検索
メディア検索
オーディオ
イメージ
アニメーション
[結果一覧]
(～の) オンライン検索
BookShelf 最初の検索
BookShelf 最初のニュース
Encarta オンラインライブラリ
(～の) 詳細検索
書籍
メディア
項目
[検索ヒットハイライト]
潜在的に不安定な箇所を明らかにします。
製品を探索していくと、他のものよりも不安定な機能に気が付きます。特に障害を起こす可能性があると思えるなら、貢献機能を使うことも考えますが、プライマリ機能に不安定さがあることの方が重要です。
潜在的に不安定さを引き起しそうな機能に対して試せる作業を決めます。大量、複雑、または挑戦的な入力を考えます。
選び出した不安定な部分は、テスト時に使用するデータや戦略を付加して、一覧にします。
潜在的に不安定な部分の例
他製品と相互作用する機能 (オブジェクトリンク、オブジェクト埋込み、ファイル変換等)。
アプリケーションの外部イベントを処理する機能 (ファックスの到着時にコンピュータを立ち上げるウェイクアップ機能等)。
メモリを集中的に使用する機能。
オペレーティングシステムとのやりとりを頻繁に行う機能。
異常なほど複雑な機能。
操作パラメータを変更する機能 (基本設定等)。
オペレーティング システム構成を操作する機能。
エラーを途中でくい止めるか、またはエラーから回復する機能。
基本オペレーティングシステム機能を置き換える機能 (ファイル削除取消し、またはユーザーログオン処理)。
複数同時プロセスに関係する機能または機能群。
複数ファイルを同時に操作する機能。
ネットワークを超えてファイルをオープンする機能。
チャレンジ データのアイデア
ドキュメント : 大きなドキュメント、多数の同時オープンドキュメント、または多数の異なるオブジェクトを含むドキュメント。
レコード : 長いレコード、多数のレコード、または複雑なレコード。
一覧 : 長い一覧、空の一覧、複数列の一覧。
フィールド : 多数の文字、多数の異なる文字、多すぎる文字、非常に大きな値、「不正な」値の入力。
オブジェクト : 多数のオブジェクト、大型オブジェクト、複合オブジェクト。
変更 : 追加と削除の実行。保存または終了せずに編集。
ロード : 多数のプロセスの同時動作、大きな単位でのバッチ処理、非常に短い時間で多くを実行。
不合理な入力 : ウィンドウ回りでのランダムクリック。キーのランダム入力。予想もしない入力のインプット。
例外とエスケープ : プロセスへの割り込みの繰り返し。操作のキャンセル。エラー処理のきっかけとなる誤ったデータの入力。
提供物 |
次のようなときに完了したと言えます |
|---|---|
|
|
不安定性 : よく寄せられる質問
このタスクがなぜ大事か。
安定性のテストをする場合には、不安定になりそうな所のテストに注力するとよいでしょう。製品に与える入力データによっては、不安定さを引き起す可能性が高いものがあります。
不安定さとは何か、そして障害との違いは何か。
クラッシュは最もはっきりとした不安定さですが、劇的さのあまりない不安定さもあります。機能障害と不安定さの基本的な違いについて説明します。後者では、機能が動作する場合と動作しない場合があります。機能は不安定ですが、完全に操作不能ではありません。また、機能は正しく動作する面もありますが、他の機能や製品に悪影響を与える負の副次効果があります。
潜在的に不安定であることを、どのようにして認識しますか。
確実に知ることはできません。ヒューリスティックス法では、一般的なヒントが得られます。製品を探索していくと、製品のどの部分が不安定なのかを感覚的に知ることができます。最初に変だと感じたことを手早くテストで裏付けます。ある機能が複雑でメモリを集中的に使うため、不安定ではないかと疑っているとしましょう。見た目の入力と出力、および動作の多様性を見ただけで、仮定した複雑さを確認できます。タスクマネージャを使って、機能実行中に製品がメモリを使用する様子を見ているだけで、メモリ使用に関する複雑さを確認できます。
機能が不安定であることを確信するか、または不安定さと結びつくことが多い属性がありさえすれば、機能を圧倒するテスト、または「ストレスをかける」テストを 2、3 種類設計してみます。不安定さのテストの場合には、通常の入力パターンに制限する必要はありません。ただし、通常の入力で不安定さが分かる場合は、かなり興味深いケースです。
問題点と疑問を明らかにします。
製品を探索するときには、遭遇する問題のメモを取っておきます。
潜在的な問題点と疑問分野
特殊なハードウェアまたは別のソフトウェア製品がなければテストできない機能。
サポートしているビデオシステムには制限があるか、または通常よりも多くのメモリ量を必要とするような、特殊な製品要件。
理解できない機能。
探索的テストにおいて、将来のテスト合格のために吟味する必要がある制限事項。
特別な注意が必要な、変わった製品機能。
理解するのによけいな時間がかかったもの。
リーダーやマネージャに質問する必要があったこと、および彼らからのアドバイス。
障害ではないが、製品が示す奇抜で、解決の難しいエラーがらみの動きについてのコメント。
提供物 |
次のようなときに完了したと言えます |
|---|---|
|
|
問題点と疑問 : よく寄せられる質問
このタスクはなぜ大事か。
自分自身または他のテスト担当者が、2 ～ 3 日または数ヶ月してから、今回作成したメモと TCO を使うことがあります。製品を探索するときには、問題点を見て、決定を下します。製品を最初に探索する際に、発見する問題とそれに対して行う決定のメモを取っていくなら、同じ製品を再びテストする際には、自分または次のテスト担当者がこのメモをレビューして、TCO を使うことで時間を節約できます。
テスト ケース概要 (TCO) を作成します。各機能をテストし、結果を記録するのに使用します。
与えられた時間内に問題なくテストできる、すべてのプライマリ機能から TCO (テストケース概要) を作成します。
時間があれば、興味深い貢献機能のサンプルのテストを概要に追加します。
発見したすべての潜在的不安定箇所のテストを、この概要に追加します。
概要のテストを実行し、障害が見つかれば、これを記録します。
テスト失敗の根拠
目的と一貫した動作ができないように見えるプライマリ機能があります。
製品に見られる不正確な動作は、通常の使用を著しく損なうものです。
製品は Windows に悪影響を与えると判断します。
製品は、ハング、クラッシュ、およびデータ破壊を起こします。
プライマリ機能が、テスト中に動作不能や不具合を引き起こしています。
障害調査
- テストマネージャが作成したプロシージャに従って、障害を調査、デバッグ、再現確認を行い、報告します。
提供物 |
次のようなときに完了したと言えます |
|---|---|
|
|
問題点のテストと記録 : よく寄せられる質問
このタスクはなぜ大事か。
これがプロセス全体の心臓部です。これは実際のテストになります。他のタスクが、この作業の遂行に役立ちます。
他のタスクをすべて終わらせてから、このタスクに取りかからなくて良いのでしょうか。
理屈的にはそうです。実際に、他のいかなる方法でもうまく見つけられなかった、他のタスクに関する重要な情報を、いつも見つけてくれるのがテスト作業そのものです。ここで言う他のタスクは完了したと考えてもかまいませんが、この機能を実際にテストする際に、もう一度タスクを調べる必要性を感じてください。
テスト ケースを記録する 際に、どのフォーマットで記録すべきですか。
簡単なものにします。プライマリ機能の一覧を作るのに、2 ～ 3 段階で記述する概要フォーマットを使えます。各テスト「ケース」に十分な情報を記入しておけば、自分または他のテスト担当者が再度テストを実行する際に、テスト方法を理解できます。たとえば、Microsoft WordPad の [開く] 機能をテストする際にこのテストケースを使えます。
WordPad 文書を次のように開きます...
[ファイル] メニューで開きます
Ctrl+O
ツールバーの[開く] を使います
ドキュメントアイコンをダブルクリックします
ドキュメントアイコンを WordPad にドラッグアンドドロップします
このケースでは「標準ユーザー」は、[開く] 機能を開始する 5 種類の方法すべてがプライマリであると感じています。この方法のどれかが動作しない場合には、WordPad が壊れています。このユーザーには、実際に 5 種類の [開く] 機能があります。メニューを使って[開く]、アクセラレータキーを使って [開く]、ツールバーから [開く] 等です。この概要では、順を追ってテスト詳細を説明していません。たとえば、最初の 3 つのケースでは、[開く] ダイアログボックスが現れますが、テストケースでは、そのことに触れていません。どのような種類のドキュメントを使うべきか、についても何も述べていません。つまり、単純か複雑か、短いか長いかについては規定していません。しかし、Microsoft WordPad に慣れているテスト担当者は、この 5 種類のテストを全員が同じように実行させられます。
設計、実行するすべてのテストを詳細に書き留めておかないのは どうしてでしょうか。
テストを成功させるには、テスト中にメモを取っていくことが良いとされていますが、時間がかかることが問題であり、プロジェクトのテストの流れを中断してしまいます。テストの詳細を書き留めるのをやめると、たくさん書いてテストをほとんど実行しないようなことはなくなります。なお、テスト対象の概要をきちんと作成している限りは、詳細に書き留める必要はありません。このプロセス中に作成する他のメモをすべて合わせれば、詳細な結果を残せることになります。
[ 1 ] James Bach の情報については、http://www.satisfice.com を、Windows 2000 の認定プログラムの情報については、https://www.microsoft.com/japan/windowsserver2003/partners/isvs/cfw.mspx を参照してください。
[2] このプロシージャでは、仕事を監督し、必要な情報の取得を助け、テストの進め方に疑問がある場合にいつでも決定を下してくれる人がいると仮定しています。説明の都合上、この人はテストマネージャであると決めておきます。
ダウンロード
.gif "Cc835598.icon_Word(ja-jp,TechNet.10).gif"){kind=icon}
Windows アプリケーションの探索的テスト プロシージャ
187 KB
Microsoft Word ファイル