★★概要 ■ISTQBとJSTQBの概要,, ,, ,　現在、私たちの身の回りは様々なソフトウェアで占められています。たとえば、普段持ち歩いている携帯電話は、す, ,でに10年以上前の基幹系システムと遜色のないコード量のソフトウェアで構成されています。また、最新の交通情報, ,をもとに目的地への最短時間での到達を実現するカーナビは、すでに数百万行規模のソフトウェアとなっています。, ,, ,　インターネット上に目を向けると、一部のEC（電子商取引）サイトや検索ポータルサイトでは、1日に数千万件から数, ,十億以上ものアクセスがあります。これらの何気なく利用しているシステム、情報家電、制御システムに不具合が発, ,生すれば、単純に利用できないという問題だけでなく、社会的インフラの停止や財産の安全性を損なう可能性、はた, ,また生命の危険に遭遇するような問題が発生します。, ,, ,　信頼性や安全性を確保する重要な技術としてソフトウェアテストがありますが、昨今のさまざまなシステム障害や, ,不具合騒動などの報道でしばしば目にする「テスト不足」というキーワードは、単純にテストの工数の不足を意味して, ,いるだけではなく、やはり業界全体で「テストの技術力」が低迷していると言わざるを得ません。信頼性や安全性を確, ,保していくためには、ソフトウェア技術者全員がテスト技術を向上させなくてはならないでしょう。, ,, ,　ソフトウェア技術者向けの資格として、情報処理技術者試験、ベンダーが主催する認定試験など数多く存在してお, ,り、これらの資格試験や認定試験などは技術力を向上させる手段の一つとなっています。そこで、ソフトウェア技術, ,者のテスト技術力を向上させるきっかけとして、JSTQB（日本ソフトウェアテスト資格認定委員会：Japan Software, ,Testing Qualifications Board）は、テスト技術者の資格認定制度を開始しました。, ,, ,　JSTQBは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、各国のテスト技術者組織が参加してい, ,るISTQB（International Software Testing Qualifications Board）の加盟組織として2005年4月に認定されています。, ,ISTQBの加盟組織の各国団体は、資格及び教育・訓練組織認証について相互認証を行っています。つまり、JSTQB, ,が運営するソフトウェアテスト技術者資格は海外でも有効な資格となっています。, ,, ,～, ,, ,◆Foundation Level認定資格の想定対象者, ,, ,,　Foundation Levelの資格は、ソフトウェアのテストに関係するすべての人が対象です。テスト担当者、テストアナ ,,リスト、テストエンジニア、テストコンサルタント、テストマネージャ、ユーザの受入テスト担当者などは当然ですが ,,、そのほかにソフトウェア開発者やプロジェクトマネージャ、品質管理者、ソフトウェア開発マネージャ、ビジネスア ,,ナリスト、IT部門長、経営コンサルタント、および学術研究者や学生などでソフトウェアテストに興味を持つすべて ,,の人が対象となります。 ★★第1章 第1章　テストの基礎,,,,,, ,,,,,, ■１．１　テストの必要性,,,,,, ,,,,,, ,　この節では、ソフトウェアテストの必要性について解説します。,,,,, ,,,,,, ,■１．１．１　ソフトウェアシステムの状況,,,,, ,,,,,, ,,　ソフトウェアシステムは、銀行などのビジネス分野から自動車などの製造分野に至るまで、さまざまな分野で使,,,, ,,われることが必須となっています。ソフトウェアが期待通りに動作せず、なんらかの不都合をユーザに与えること,,,, ,,もあります。ソフトウェアが期待通りに動かないことによる不都合は、大きく分けて次の4つがあります。,,,, ,,,,,, ,,◆経済的な損失,,,, ,,,,,, ,,,　経済的な損失には、トラブルが発生したソフトウェアの修正および再テストにかかるコスト、クレーム受付や,,, ,,,製品回収などのトラブル対応にかかるサポートコストが考えられます。また、ソフトウェアを使用しているユー,,, ,,,ザ企業の業務がとまってしまうことにより発生する損害への補償や機会損失も忘れてはいけません。,,, ,,,　最近の例でも、銀行のATMの動作トラブルや携帯電話のトラブルなどソフトウェアに起因する問題はあとを,,, ,,,絶ちません。少し前のデータになりますが、米国NISTの調査報告書によれば、ソフトウェアが正しく動作しない,,, ,,,ことにより、米国経済は、年間595億ドルの損害を被っているそうです。そのうち3分の1は適正なテストを実施,,, ,,,することにより回避可能なものと見込まれています。,,, ,,,,,, ,,◆時間の浪費,,,, ,,,,,, ,,,　上記のような経済的損失で発生するコストは、たいてい時間的な損失として発生します。時間的な損失は、,,, ,,,単純なコストだけでは済まされない浪費となります。たとえば、システムのトラブルによって起こるソフトウェア,,, ,,,の修正作業は、本来別の開発に使う予定であった開発担当者の時間を圧迫します。単純に対象の製品に対,,, ,,,するコストが増加するのではなく、一見関係ないと考えられる他の製品の開発コストやスケジュールにまで影,,, ,,,響を及ぼし、マネジメント的な調整が必要になります。,,, ,,,　問題が大きくならないようにするために、開発担当者の労務時間を増やすことで対処する場合も多く、精神,,, ,,,的、体力的なストレスから健康問題にもつながることがあります。,,, ,,,,,, ,,◆信用の失墜,,,, ,,,,,, ,,,　品質の低下は信用の失墜につながり、製品競争力の低下につながります。家電や自動車などの市販される,,, ,,,製品でリコールが多発すれば、製品の競争力低下だけではなく会社そのもののブランドイメージの低下にもつ,,, ,,,ながり、「あの会社の製品は品質が悪いから買うのをやめた方がいい」と言われるようになってしまいます。ソ,,, ,,,フトウェア分野ではありませんが、品質問題が会社の存続にまで影響を与えた例としては、2000年の某食品,,, ,,,メーカーの食中毒事件があります。,,, ,,,,,, ,,,【note】某食品メーカーによる食中毒事件とは,,, ,,,,,, ,,,,　2000年、近畿地方で販売された某食品メーカーの低脂肪牛乳を飲んだ人が下痢などを訴えた問題で、被,, ,,,,害者は1万人弱にも及びました。問題を引き起こした牛乳の品質保持期間が改ざんされたことと、事件発生,, ,,,,後の発表内容が二転三転したことなどが消費者の不信を招きました。,, ,,,,,, ,,◆障害や死亡事故,,,, ,,,,,, ,,,　ソフトウェアの用途によっては、正しく動作しないと、傷害や死亡事故につながる場合があります。たとえば、,,, ,,,2001年にパナマの病院でがん治療に利用する放射線装置のソフトウェアにミスがあり、患者に対して許容量,,, ,,,以上の放射線を浴びせたため、5名もの命が絶たれてしまうという惨事がありました。,,, ,,,,,, ,■１．１．２　ソフトウェアの欠陥の原因,,,,, ,,,,,, ,,　ソフトウェアの欠陥と一言で表現することは多いのですが、必ずしも正確な言い方ではありません。欠陥とはプ,,,, ,,ログラムのコード上の間違いであり、ソフトウェアの動きが意図した動きと一致しない現象ではありません。欠陥,,,, ,,の原因と、欠陥のために生じた結果を混同してしまうと、コミュニケーションを行う時に問題が発生します。ISTQB,,,, ,,では、欠陥に関連する用語を以下の4つに分類しています。,,,, ,,,,,, ,,◆エラー（誤り）,,,, ,,,,,, ,,,　ISTQBでは、エラーを「間違った結果を生み出す人間の行為」と定義しています。人間は、勘違いや思い込み,,, ,,,など、何かしらの原因でエラー（誤り）を犯します。そのエラーがコード、ソフトウェア、システム、ドキュメントの,,, ,,,欠陥となります。勘違いや思い込みの発生する原因としては、納期のプレッシャー、コードの複雑さ、内部構造,,, ,,,の複雑さ、技術の変更、他システムとの通信ミスなどが挙げられます。,,, ,,,,,, ,,◆フォールト(fault）,,,, ,,,,,, ,,,　フォールトとは、「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシ,,, ,,,ステムの中の不備」と定義されています。エラー(誤り）によってプログラムにフォールトを埋め込んで実装して,,, ,,,しまうと考えればよいでしょう。ISTQBでは、バグ、欠陥、フォールトは同義であるとしています。,,, ,,,,,, ,,◆故障（failure）,,,, ,,,,,, ,,,　欠陥のあるプログラムを実行したときに、実行すべきこと（あるいは実行してはならないこと）を正しく実行で,,, ,,,きず、故障が起きます。ISTQBでは、「コンポーネントやシステムが、期待した機能、サービス、結果を提供でき,,, ,,,ないこと」と定義しています。,,, ,,,　ソフトウェア、システム、ドキュメントの欠陥で故障が発生することもありますが、すべての欠陥が故障となる,,, ,,,わけではありません。欠陥があっても、ソフトウェア（もしくはシステム）を実際に動かしたときに、欠陥があるコ,,, ,,,ードが実行されなければ、故障にはなりません。また、故障は、環境条件により起きることもあります。たとえ,,, ,,,ば、放射能、磁気、電界、汚染がファームウェアの誤動作を起こしたり、ハードウェアの構成を変更することに,,, ,,,よってソフトウェアの実行が影響を受けたりすることがあります。,,, ,,,,,, ,,◆インシデント,,,, ,,,,,, ,,,　テスト担当者にとって、最も身近なものがインシデントでしょう。なぜなら、テストを実行して、テストケースの,,, ,,,期待結果と実際の動作が違った時に記載するのがインシデントレポートだからです。インシデントとは、ソフト,,, ,,,ウェアシステムを実際に使うユーザやテスト担当者が期待する動きと、実際の動きが一致しない事象を指しま,,, ,,,す。インシデントと故障は同じではありません。テスト環境の設定ミスのために期待通りにソフトウェアが動か,,, ,,,ないことがありますし、テスト担当者の勘違いということもあります。このため、必ずしも「インシデント」＝「故障,,, ,,,」とはならないのです。,,, ,,,　なお日本では、インシデントのことを「不具合」または「障害」と呼ぶことの方が多いので注意してください。,,, ,,,,,, ,,,□注意,,, ,,,,,, ,,,,　SWEBOKでは、エラーを「計算、観測、または測定された値あるいは状態と、正しい、仕様化された、また,, ,,,,は理論的に正しい値あるいは状態との差異」と定義しています。ISTQBの定義とは異なるので注意してくだ,, ,,,,さい。,, ,,,,,, ,■１．１．３　ソフトウェアの開発、保守、運用におけるテストの役割,,,,, ,,,,,, ,,　ソフトウェアテストの主な役割として、システムが稼働する前にシステムやドキュメントを詳細にテストし、欠陥を,,,, ,,検出して修正することで、市場で問題が発生するリスクを減らすことが挙げられます。リスクとは、「悪い結果にな,,,, ,,ってしまう可能性」のことです。,,,, ,,　ソフトウェアシステムのリスクには、たとえば以下のものがあります。,,,, ,,,,,, ,,,・,リリース後の致命的なバグで全品回収となるかもしれない,, ,,,・,稼働中のシステム性能が著しく低いため、顧客の業務に支障が出るかもしれない,, ,,,,,, ,,　このような「悪い結果」、つまり「１．１．１　ソフトウェアシステムの状況」で触れたソフトウェアが期待通りに動か,,,, ,,ないことによる不都合（経済的損失・時間の浪費・信用の失墜・障害や死亡事故）へつながる確率を下げるために,,,, ,,もテストを行うのです。,,,, ,,,,,, ,,　「悪い結果」につながらないまでも、ソフトウェアシステムの欠陥を多く見つけて修正をすれば品質は改善し、使,,,, ,,い勝手などの非機能要件にかかる課題をテストで発見し、修正することで製品の魅力すら高めることができるよう,,,, ,,になります。,,,, ,,　そのほかに、契約や法律上の適格要件や各業界の標準に合致していることを証明するため、ソフトウェアのテ,,,, ,,ストが必要になることもあります。,,,, ,,,,,, ,■１．１．４　テストと品質,,,,, ,,,,,, ,,　ソフトウェアの品質は「顧客の満足度」につながります。顧客（お客様）は、なんらかの目的を達成する手段とし,,,, ,,てソフトウェアシステムを使います。その目的を達成できていると感じられなければ、たとえ顧客自身が同意した,,,, ,,仕様通りに作られていたとしても、決して満足することはないでしょう。「顧客が喜ばなければ品質は高いとは言え,,,, ,,ない」ものなのです。,,,, ,,,,,, ,,　品質は、大きく「当たり前品質」と「魅力的品質」と捉える事ができます。「当たり前品質」とは、機能そのものが意,,,, ,,図したとおりに動くことを指しています。製品に欠陥があり、当たり前に動くと思っていたことが思い通りに動かな,,,, ,,ければ、顧客は「別のものを買えばよかった」と思うでしょう。これに対して「魅力的品質」は、その製品を使いたく,,,, ,,なるような特徴を指しています。,,,, ,,,,,, ,,　「当たり前品質」と「魅力的品質」は相反することもあります。納品間際に顧客が本当に求めていた有用な機能,,,, ,,を盛り込んだ場合、「魅力的品質」は向上しますが、納品直前に仕様追加するとそれまで行ってきたテスト結果の,,,, ,,信頼性は低下するので、「当たり前品質」は下がるかもしれません。このように、品質にはトレードオフが存在しま,,,, ,,す。,,,, ,,,,,, ,,　ソフトウェアテストと品質は、次の3つの点で関係があります。,,,, ,,,,,, ,,,◆品質の確保,,, ,,,,,, ,,,,　ソフトウェアテストでは、期待する結果と実際の結果の差異をインシデント（不具合）として報告し、,, ,,,,リリースする前に欠陥を減らし、品質を確保することが主な仕事となります。適切に設計したテストを,, ,,,,実施して、欠陥がほとんど見つからなかったなら、対象のソフトウェアの品質が確保できたと判断し、,, ,,,,自信をもって顧客へ納品することができるでしょう。テストで欠陥が見つかった場合、その欠陥を修正,, ,,,,すれば、システムの品質を確保できます。,, ,,,,,, ,,,◆品質の計測,,, ,,,,,, ,,,,　テストで検出した欠陥に関する情報をもとにして、ソフトウェアの品質を計測できます。欠陥や故障を,, ,,,,計測することにより、品質に対して定量的な判断が可能になります。前述したとおり、品質は「顧客の,, ,,,,満足度」というあいまいなものであるため、現実的には何かしら客観的に判断できる指標が必要となり,, ,,,,ます。指標に使うデータは、ソフトウェアの機能要件/非機能要件の両面、品質特性（機能性、信頼性、,, ,,,,使用性、効率性、保守性、移植性）の観点などから定義した上で計測します。計測の例としては、以下の,, ,,,,ものがあります。,, ,,,,,, ,,,,,・,要件ごとのテストカバレッジと故障発生件数 ,,,,,・,テスト実施時間の経過と故障発生件数の推移 ,,,,,・,システムの性能（応答時間やスループットなど）に関するデータ収集 ,,,,,, ,,,◆プロセス改善のための情報提供,,, ,,,,,, ,,,,　システム開発で過去のプロジェクトから学ぶべきことはたくさんあります。ほかのプロジェクトで見つ,, ,,,,かった欠陥の根本原因を教訓として活用すればプロセスを改善でき、同じ原因の欠陥の作り込みを防ぐ,, ,,,,事ができます。同じ過ちを繰り返すことがなくなれば、将来開発するシステムの品質の改善につながり,, ,,,,ます。,, ,,,,,, ,,　上記３つの説明で分かる通り、テストは品質に対してさまざまな方法で貢献することができますが、そのために,,,, ,,は、テストを開発標準、教育、欠陥の分析と並ぶ活動のひとつとして品質保証活動に統合しなければなりません,,,, ,,。具体的には、開発標準におけるテストの位置づけを見直したり、欠陥分析を開発プロセスに取り込むなどの活,,,, ,,動が挙げられます。,,,, ,,,,,, ,,□ここがポイント！,,,, ,,,,,, ,,,　ソフトウェアテストと品質の関係で重要なことは、テスト結果をそのままにせず、品質向上のための活動（欠,,, ,,,陥の修正やプロセス改善）に反映させることです。テストそのものが目的にならないよう注意しましょう。,,, ,,,,,, ,■１．１．５　テストの十分性,,,,, ,,,,,, ,,　どこまでテストをすべきかは、以下に挙げる要因などを考慮して決めます。,,,, ,,,,,, ,,,・,技術面、安全面、ビジネス面からみたプロダクトリスクの度合い（テストカバレッジ、故障率など）,, ,,,・,プロジェクトリスク（テストを含む開発全体の進捗など）,, ,,,・,開発期間や予算などプロジェクトの制限（納期やコストに対する遵守度合い）,, ,,,,,, ,,　テストを計画する時に、これらの要因をもとに終了基準を定めることで、どこまでテストをするべきか見極めるこ,,,, ,,とができます。テスト終了時は、計画で定めた終了基準を満たしているか確認しますが、現実的には終了基準だ,,,, ,,けではなく、３つの要因を再度加味して総合的に判断します。,,,, ,,,,,, ,,◆テスト結果をもとにした将来のための情報提供,,,, ,,,,,, ,,,　テストは、ステークホルダ（利害関係者）へプロダクトの品質に関して十分な情報を提供できなくてはなりませ,,, ,,,ん。さらに、次の開発ステップや次回リリースにおけるリリース戦略を決められるように品質に関わる情報を提,,, ,,,供すべきです。具体的には、未対応インシデント一覧の提示や、欠陥原因の分析などが考えられます。,,, ,,,,,, ■１．２　テストとは何か,,,,,, ,,,,,, ,　「テストとは何か？」と聞かれてすぐに答える事が出来るでしょうか。開発担当者が行うデバッグと、テスト技術者の,,,,, ,行うテストの違いについて説明できるでしょうか。本節では、これらのことについて説明していきます。,,,,, ,,,,,, ,■１．２．１　テストとは？,,,,, ,,,,,, ,,　一般にテストとは、ソフトウェアを実行して動きを確認することだと思われていることが多いようです。これはテス,,,, ,,トの一部ではありますが全部ではありません。テストという概念には、ドキュメント（要件定義書、機能仕様書、構,,,, ,,成仕様書など）とソースコードのレビューや静的解析を実施することも含まれることもあります。,,,, ,,　テストの活動は、テストスイートやテストツールを駆使した作業といったテスト実行だけにとどまるものではありま,,,, ,,せん。例えば、次のようなものがあります。,,,, ,,,,,, ,,,・,テスト実行前作業,, ,,,・,テスト実行時の作業,, ,,,・,テスト実行後の作業,, ,,,・,全体を通して行う作業,, ,,,,,, ,,◆テスト実行前作業,,,, ,,,,,, ,,,　テスト実行前に実施しておくべき作業です。この作業を軽視して、事前作業を行わずテスト実行に取り掛かる,,, ,,,と、自分が何のためのテストをしているのかわからなくなります。以下に、実施すべき作業の一例を示します。,,, ,,,,,, ,,,◇計画,,, ,,,,,, ,,,,　テストの準備作業、リソース配分、いつまでにどのような作業を実施するかを計画します。テスト終了基準,, ,,,,についても決定します。主にテストリーダやテストマネージャが行います。,, ,,,,,, ,,,◇テスト条件の選択,,, ,,,,,, ,,,,　テストベースを分析し、何をテストするのかを決定します。主にテスト担当者が行います。,, ,,,,,, ,,,◇テストケースの設計,,, ,,,,,, ,,,,　特定したテスト条件を網羅して確認できるようテストケースを設計します。主にテスト担当者が行います。,, ,,,,,, ,,◆テスト実行時の作業,,,, ,,,,,, ,,,　テスト実行時に行うべき作業です。単にテストケースを実行するだけでなく、計画およびテストケース設計時,,, ,,,に決定した事項の確認を忘れないようにしなければなりません。以下に、実施すべき作業の一例を示します。,,, ,,,,,, ,,,◇実行結果のチェック,,, ,,,,,, ,,,,　テストケースを実行して得られた結果の確認を行います。何度も実行するテストケースであれば、結果の,, ,,,,確認を自動化したほうがよいでしょう。主にテスト担当者が行います。,, ,,,,,, ,,,◇テスト終了基準の検証,,, ,,,,,, ,,,,　計画時に決定した終了基準を満たしているかを検証します。主にテストマネージャが行います。,, ,,,,,, ,,,◇テスト結果の報告,,, ,,,,,, ,,,,　テスト実施結果、インシデントの対応結果、終了基準の達成度合いなどについて、ステークホルダへ報告,, ,,,,します。主にテストマネージャが行います。,, ,,,,,, ,,◆テスト実行後の作業,,,, ,,,,,, ,,,　次のテストプロジェクトのための作業です。この積み重ねが行われることにより、テストプロジェクトが成熟し,,, ,,,ていきます。また、担当者自身のテスト技術の向上につながります。,,, ,,,,,, ,,,◇テストウェアの整理,,, ,,,,,, ,,,,　テストプロジェクトが終了した時に、テストウェアの整理を行い資産化し、次回のテストプロジェクトに引継,, ,,,,ぎ、良いスパイラルを回していくための作業を行います。,, ,,,,,, ,,◆全体を通して行われる作業,,,, ,,,,,, ,,,　テストプロジェクト全体を通して行われる作業です。以下に一例を示します。,,, ,,,,,, ,,,◇コントロール,,, ,,,,,, ,,,,　テストの進捗管理、テストカバレッジや終了基準の達成状況のモニタリングなどを実施します。主にテスト,, ,,,,マネージャが行います。,, ,,,,,, ,■１．２．２　テストの目的,,,,, ,,,,,, ,,　テストの目的は１つではありません。以下のような目的があります。,,,, ,,,,,, ,,,・,欠陥の検出,, ,,,・,対象ソフトウェアの品質レベルが十分であることの確認,, ,,,・,意思決定のための情報の提示,, ,,,・,欠陥の作り込みの防止,, ,,,,,, ,,　動的テストと静的テストは、方法は違っても同じような目的のために使えます。たとえば、欠陥の検出のように、,,,, ,,品質レベルが十分であることを確認するために使う事が出来ます。テストは、テスト対象のシステムだけでなく開,,,, ,,発やテストプロセスを改善するための情報を提供します。,,,, ,,,,,, ,,　プロダクトのライフサイクルで初期にテスト設計の関りを考えるプロセス（テスト設計を通してテストベースを検証,,,, ,,すること）と活動は、コードの中に欠陥が入り込まないようにする効果があります。また、ドキュメント（たとえば、要,,,, ,,件定義書）のレビュー、問題の認識と解決も仕様やコードに欠陥が入ることを防ぎます。,,,, ,,,,,, ,,　テストの視点が異なると目的も異なってきます。たとえば、以下のようになります。,,,, ,,,,,, ,,◆製品がリリースされるまでのテスト,,,, ,,,,,, ,,,○開発でのテスト（コンポーネントテスト、統合テスト、システムテスト）,,, ,,,,,, ,,,,　開発でのテストの主たる目的は、なるべく多くの故障を発見して、ソフトウェアの欠陥を特定して修正する,, ,,,,ことです。,, ,,,,,, ,,,○受入テスト,,, ,,,,,, ,,,,　受入テストの主たる目的は、システムが期待通りに動作し、要件に合致することの確認です。また、欠陥,, ,,,,の修正を目的とはせずに、ソフトウェアの品質確認を行い、所定の時期にソフトウェアをリリースすればど,, ,,,,んなリスクがあるのかをステークホルダに提供するために行われることもあります。,, ,,,,,, ,,◆保守テスト,,,, ,,,,,, ,,,　保守テストの主たる目的は、ソフトウェアの変更時（機能追加、インシデント対応など）に、新たな欠陥が潜ん,,, ,,,でいないかを確認することです。,,, ,,,,,, ,,◆運用テスト,,,, ,,,,,, ,,,　運用テストの主たる目的は、信頼性や可用性などのシステム特性を確認することです。,,, ,,,　ステークホルダへのリスクの報告は、テストの視点や目的にとらわれず、必要に応じて行われるべきです。リ,,, ,,,スクの内容により、報告すべきステークホルダが変わることがあります。たとえば、欠陥を特定して修正するこ,,, ,,,とを主目的とする開発でのテストにおいて、欠陥が多すぎて期日までに品質が確保できる見込みがないなら,,, ,,,ば、テスト担当者はテストマネージャに品質に対するリスクを報告し、テストマネージャは経営者に報告を行い,,, ,,,ます。,,, ,,,,,, ,■１．２．３　デバッグとテスト,,,,, ,,,,,, ,,　（動的）（※８）テストとは、バグ（bug）を発見することだという考えがあります。この言葉だけでは間違いとも正し,,,, ,,いとも言えません。,,,, ,,　そもそも、デバッグ（debug）とテストは同じなのでしょうか。結論から言うと、デバッグとテストは同じではありませ,,,, ,,ん。（動的）テストとは、欠陥から発生する故障を発見することを目的としています。これに対してデバッグとは、故,,,, ,,障の原因を突き止め、解析し、取り除く一連の開発の活動です。その後、テスト担当者が再テストを実施し、修正,,,, ,,により故障が解消したことを確認します。,,,, ,,　たとえば、バッファオーバーフローを例にして考えてみましょう。テスト実行によりバッファオーバーフローが発生,,,, ,,し、ソフトウェアが異常終了するという故障を検出することがテストです。異常終了の原因をデバッガなどのツール,,,, ,,を利用して突き止め、欠陥個所を特定した上でバッファオーバーフローを修正することがデバッグです。,,,, ,,　テスト担当者はテストに責任を持ち、開発担当者はデバッグに責任を持つことになります。,,,, ,,,,,, ,,※８,,シラバスの改訂で動的テストとなっていますが、静的テストを除外する必要もないので、（動的）テストとして,, ,,,,います。,, ,,,,,, ■１．３　テストの７原則,,,,,, ,,,,,, ,　この節では、ソフトウェアテストの７原則について確認します。,,,,, ,,,,,, ,■１．３．１　ソフトウェアテストの原則,,,,, ,,,,,, ,,　ソフトウェアがこの世に生まれてきたのと同じくして、ソフトウェアテストも生まれました。それ以来、さまざまなソ,,,, ,,フトウェアテストの原則が編み出されてきました。その中から、共通して使えるエッセンスが一般的なガイドライン,,,, ,,として使われています。それらの中から、JSTQBでは７つの原則を示しています。,,,, ,,,,,, ,,◆原則１：テストは「欠陥がある」ことしか示せない,,,, ,,,,,, ,,,　テストにより、故障を見つける事が出来れば、そのソフトウェアに欠陥があることはわかります。しかし、テス,,, ,,,トをしても故障を見つけることができなかった場合にはどう考えたらよいでしょうか。本当にそのソフトウェアに,,, ,,,欠陥がなかったのかもしれません。しかし、そのテストでは「たまたま」故障しなかっただけかもしれません。ま,,, ,,,た、そのテスト自身に不備があって、「たまたま」故障するパターンをテストしなかっただけかもしれません。,,, ,,,　たとえば、２つの数の和を求めるプログラムがあったとします。テストでは３桁までのすべての入力の組み合,,, ,,,わせを行ったとします。しかし、４桁以上を入力した場合にシステムをハングアップさせる組合せがあったとし,,, ,,,たらどうでしょうか。３桁までの入力では故障は起きません。しかし、そのソフトウェアには欠陥はあるのです。,,, ,,,まさかと思うかもしれませんが、このようなまさかがよくあります。テストでは「故障する＝欠陥がある」ことは,,, ,,,示すことができますが、「故障しない＝欠陥がない」ことを示すことはできないのです。,,, ,,,,,, ,,◆原則２：全数テストは不可能,,,, ,,,,,, ,,,　全数テストとは、ソフトウェアに入力する可能性のある、すべてのパターンをテストすることです。具体的には,,, ,,,どのようなことでしょうか。,,, ,,,　たとえば、２つの数の和を求めるプログラムがあるとします。入力できる数は１桁の正の整数のみとしたら、,,, ,,,テストは０＋０、０＋１、０＋２・・・１＋０、１＋１・・・２＋０、２＋１・・・９＋９というように１０×１０＝１００通りのパ,,, ,,,ターンを入力してみて結果を確認することになります。では、入力できる数が2桁までの正の整数としたら、テス,,, ,,,トパターンはいくつになるでしょうか。,,, ,,,　答えは１００×１００＝10000通りになります。仮に、１０のパターンをテストするのに１分かかるとしたら、1桁,,, ,,,の入力の場合は10分、2桁の入力の場合は１０００分＝１６時間以上かかることになります。しかも、これらは,,, ,,,正しい結果を確認するパターン（正常系と呼びます）のみです。では、-１を入れたら？１００では？Aは？これ,,, ,,,らの場合は「エラー」を正しく出すテストパターン（異常系と呼びます）になります。実際、故障の多くは、このよ,,, ,,,うな「予期せぬ」入力パターンで引き起こされます。,,, ,,,　したがって、このような「エラー」を出すことを確認するテストも非常に重要なのです。これらを組み合わせて,,, ,,,テストするとなれば、さらに多くの時間を費やすことになります。通常、テストパターンはもっと複雑ですから、テ,,, ,,,ストを有限の時間で行うことはとても難しいのです。だからこそテストの現場では、ソフトウェアの性質や目的、,,, ,,,使われ方などから重点的にテストをする場所を絞ったり、優先順位を決めてテストをしたりするのです。,,, ,,,,,, ,,◆原則３：初期テスト,,,, ,,,,,, ,,,　欠陥は作り込まないほうがよいのですが、作り込んでしまった欠陥を見つけるのは、なるべく開発の早い段,,, ,,,階に行うべきです。欠陥を見つけるのが、その欠陥を作り込んでしまった時期から離れてしまうほど、修正のコ,,, ,,,ストは指数関数的に大きくなります。たとえば、大きな壁の色塗りで、ペンキの色を間違えてしまったことを考,,, ,,,えてみましょう。,,, ,,,　ペンキを用意した時点で気が付けば、ペンキを取り替えるだけで済みます。もし、塗り始めてしまったら、気,,, ,,,が付いた時点でペンキを取り替え、塗りなおせばよいでしょう。しかし、すべて塗り終えてから気が付いた場合,,, ,,,は大変です。新しいペンキを用意し、塗り替えればよいのですが、ペンキ代も、ペンキを塗るのに費やした時,,, ,,,間も、丸々無駄になってしまいます。,,, ,,,　ソフトウェアになると、欠陥を見つけるのが遅くなればなるほど、さらに悪いことが待っています。ソフトウェア,,, ,,,の欠陥をリリース間際になってから見つけると、次のような事態が想定されます。まず、ソフトウェアの設計者,,, ,,,は時間がたてばたつほど、その設計またはコーディングを行ったときのことを忘れています。,,, ,,,　その結果、欠陥を特定するのに時間がかかってしまいます。欠陥の修正にも時間がかかってしまうかもしれ,,, ,,,ません。さらに、欠陥の関連する箇所が多かった場合、間違った直し方をしてしまう可能性も高まります。,,, ,,,特に、欠陥を持った関数があちこちで参照されていたり、さらにほかのソフトウェアに流用されていたりしてい,,, ,,,た場合、関連する箇所を探し当てるだけでも一苦労です。,,, ,,,　ところが、この欠陥を見つけたのがコードを書いた翌日だったらどうでしょう。翌日であれば、設計者はそのコ,,, ,,,ードの内容を鮮明に覚えています。欠陥の特定も、その修正もあっという間にできるでしょう。さらによいことに,,, ,,,、きっとまだほかのソフトウェアのへの流用は行われていないので、関連する箇所の調査をしなくてもすむかも,,, ,,,しれません。,,, ,,,　このように、テストはソフトウェア開発もしくはシステム開発のなるべく早い時期に開始し、なるべく早い時期,,, ,,,に欠陥を見つけるようにするのが得策なのです。,,, ,,,,,, ,,◆原則４：欠陥の偏在,,,, ,,,,,, ,,,　ソフトウェアの品質は均一なものではなく、欠陥が見つかるのはある部分に集中しているということが良くあ,,, ,,,ります。これはソフトウェア自体がいろいろな要素から構成されているからです。パソコンに搭載されるアプリケ,,, ,,,ーションなら、動作する環境（パソコンなど）、ユーザとのインタフェースとなるUI（User Interface）部、データを,,, ,,,変換する中心機能部、データを格納するデータベースなどで構成されます。ソフトウェアによっては通信機能を,,, ,,,備えたものもあるでしょう。,,, ,,,　これらの各機能が一体となり、ソフトウェアとして動きます。各機能は、その機能を実現するための設計も異,,, ,,,なりますが、構築するための難しさの質も程度も異なります。また、規模が大きくなれば、ソフトウェアを分担し,,, ,,,て（大規模ソフトウェアの場合はさらにいくつものチームで分担して)作成します。このように、ソフトウェアは複,,, ,,,雑なつくりになっています。そのため、欠陥の存在も一様ではなく、特定の個所に集中する傾向があります。一,,, ,,,説には、ソフトウェアの欠陥の8割は全体の2割の個所に集中して存在する、という話もあります。このような欠,,, ,,,陥の偏在は、過去の不具合分析や、直近のテスト結果によって予測することができます。効果的にテストを行,,, ,,,うためにはその予測結果に基づいて、重点的にテストをする個所を絞り込むのが良いでしょう。,,, ,,,,,, ,,◆原則５：殺虫剤のパラドックス,,,, ,,,,,, ,,,　害虫を退治するのに、同じ殺虫剤をずっと使い続けていると、だんだん効かなくなってしまいます。これは耐,,, ,,,性を持つものが出てきて、それ以降はその殺虫剤は効果がなくなってしまうからです。こうなると、新しい成分,,, ,,,の殺虫剤を開発しなくてはなりません。これと同じことがソフトウェアテストにも当てはまります。,,, ,,,　一つのソフトウェアに対して同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけ,,, ,,,られなくなります。欠陥をどんどん直しているのですから当たり前です。欠陥を直していくという事は、そのソフ,,, ,,,トウェアのテストセットに対する耐性を作っている、ということになります。これを「殺虫剤のパラドックス」と呼び,,, ,,,ます。殺虫剤では、耐性のできてしまった害虫に対し、新しい成分の殺虫剤を開発していきます。,,, ,,,　これと同じように、ソフトウェアテストでは、新しい内容のテストを常に作っていく必要があります。システムの,,, ,,,ほかの部分を狙ったテストを実行するとか、異なったパターンの入力をしてみるとか、絶えず視点を変えるの,,, ,,,です。そうしていけば、多数の欠陥を検出できるようになるはずです。パターンを追加するごとに欠陥が減って,,, ,,,きたなら、それはそのソフトウェアの品質が向上していると示すことになるのです。,,, ,,,,,, ,,◆原則６：テストは条件次第,,,, ,,,,,, ,,,　ソフトウェアが使われる状況、目的によって、テストの方法を変える必要があります。２４時間稼働し続けなけ,,, ,,,ればならないシステムのテストでは「どんなことをしてもシステムダウンしない」ことをテストする必要があります,,, ,,,。この場合、テスト担当者は「どのようなことをすればシステムがダウンするか」ということに重点を置いて、,,, ,,,システムへの過負荷、多重入力、競合、割り込みなどに対するテストケースを作成する必要があります。その,,, ,,,一方で、システムの稼働に直接関わらない部分のテストは優先順位を下げて行うこともあります。,,, ,,,,,, ,,,　一方、eコマース（電子商取引）のシステムならば、会社または個人が取引を行うものなので、正確性、セキュ,,, ,,,リティなどを重点にテストする必要があります。つまり、「どんな入力があっても間違った結果を出さない」「元の,,, ,,,データを壊さない」「情報が他へ漏れない」といったテストケースを作成していきます。,,, ,,,,,, ,,,　パソコンで動作するような汎用ソフトウェアなら、誰がどんな使い方をしてもマニュアル通りに動くか、インスト,,, ,,,ールはきちんと行えるか、システムに悪さはしないかなどに関してテストケースを作成していきます。,,, ,,,,,, ,,,　このように、すべてのソフトウェアに共通するテストはありません。ユーザは専門のオペレータなのか、どのよ,,, ,,,うな環境で動作するのか、など、さまざまな条件を見極めてテスト設計とテストの方法を決めていくのです。,,, ,,,,,, ,,◆原則７：「バグゼロ」の落とし穴,,,, ,,,,,, ,,,　ソフトウェアテストで故障を見つけて、欠陥を完全に治したとしても、ソフトウェアとしては役に立たないことが,,, ,,,あります。,,, ,,,　たとえば、「入力時に4桁の数値しか入らない」というインシデント報告があったとして、それを直すためにデー,,, ,,,タベースをすべて書き換えて対応したとします。これにより、5桁も100桁も入るようになったとしたら、「4桁まで,,, ,,,しか入力できない」という問題は、そのソフトウェアからなくなります。ところが、データベースを書き換えたこと,,, ,,,により、動作が遅くなってしまい、入力してから出力するまでの時間が今までの10倍になってしまったとしたら、,,, ,,,どうでしょうか。たしかに「～ができない」という問題はなくなったとしても、そのソフトウェアは遅くて使い物にな,,, ,,,らなくなってしまったとクレームがつき、別のインシデントとなるでしょう。,,, ,,,,,, ,,,　このように、そのインシデントに対処することによって役に立たなくなってしまったら、適切な修正を行ったとは,,, ,,,言えません。ここにバグゼロの落とし穴が潜んでいます。インシデントの報告を受け、修正を行うことは大切で,,, ,,,すが、修正を行う際に、機能や性能、システム全体に影響はないか、といったことを確認することも修正する上,,, ,,,で大切な作業です。,,, ,,,,,, ■１．４　基本的なテストプロセス,,,,,, ,,,,,, ,　この節では、ソフトウェアテストにおける基本的なアクティビティ（活動）とその一連の手順（プロセス）について確認,,,,, ,します。,,,,, ,,,,,, ,■１．４．１　背景,,,,, ,,,,,, ,,　テストにある程度慣れてくると、本来は事前に行うテストケースの抽出やテスト手順の作成を、テストを実施しな,,,, ,,がら同時並行的に行えばよいと思う人がいるかもしれません。しかし、それでは行き当たりばったりなテストになり,,,, ,,、テストケースが漏れてしまったり、テストの時間が足りなくなり、故障を見つけられなくなる可能性があります。合,,,, ,,理的で効率的なテストに取り組むためにはテスト計画が欠かせません。正しいテストプロセスを実行する必要が,,,, ,,あります。,,,, ,,,,,, ,,　テストプロセスとは、テストの準備段階から終了段階までの一連の作業のことです。テストプロセスでは、すべて,,,, ,,の作業の手順や段取りを検討したり、テストの結果を評価・分析したりします。,,,, ,,,,,, ,,　テストプロセス全体の主要なアクティビティとして、以下のものがあります。,,,, ,,,,,, ,,,・,計画とコントロール,, ,,,・,分析と設計,, ,,,・,実装と実行,, ,,,・,終了基準の評価とレポート,, ,,,・,終了作業,, ,,,,,, ,,　一連のアクティビティを順に直線的に進めることもあれば、分析と設計を行いつつ、仕様が明確なテストケース,,,, ,,を同時に作成するといったように、複数のアクティビティを並行して進めることもあります。このため、どのような流,,,, ,,れでテストのアクティビティやそれに付随するタスクを行うかを計画立てて検討し、テストプロセス自体を調整して,,,, ,,いくことが重要となります。,,,, ,,,,,, ,■１．４．２　テスト計画作業とコントロール,,,,, ,,,,,, ,,　テスト計画の策定では、テストの目的が何かを最初に明らかにしなければなりません。テストの目的は、テスト,,,, ,,対象となるプロダクトの出荷時期や、プロダクトの存在理由によって異なります。たとえば、納期が優先されるの,,,, ,,であれば、必要最低限の機能が動作することだけを確認することがテストの目的になることがあります。コンポー,,,, ,,ネントテスト（ユニットテスト）、統合テスト、システムテストというように、テストのレベルごとに検証すべき目的が異,,,, ,,なるのが普通です。テストの目的を明確化することにより、どんなテストを「何のために」行うかというテストの使命,,,, ,,を明らかにできます。,,,, ,,,,,, ,,　コントロールで大切なのは、テストの一連のプロセスをコントロールできるように、テストのアクティビティやタスク,,,, ,,の状況を把握すること、つまりモニタリングを行わなければなりません。モニタリングなしでは、間違った方向にテ,,,, ,,ストが進んでいるのか、それとも順調なのかを客観的に理解することなどできません。,,,, ,,,,,, ,,　具体的には、テストの実施中であれば、テスト計画と進捗との乖離を計測したり、インシデントの発生状況とテス,,,, ,,トケースの日々の進捗状況からテスト対象の品質を分析したりします。こういった活動により、テスト計画のみなら,,,, ,,ずプロジェクト計画で定めた目的や使命との乖離を併せてモニタリングしコントロールし、必要に応じてテスト計画,,,, ,,やプロジェクト計画を見直すというフィードバックを行います。,,,, ,,,,,, ,,　なお、マネジメントの側面についての詳細は５．２節および５．３節を参照してください。,,,, ,,,,,, ,,◆テスト計画,,,, ,,,,,, ,,,　テスト計画を構成するタスクにはさまざまなものがあります。以下ではシラバスで取り上げられている幾つか,,, ,,,のタスクを紹介します。,,, ,,,,,, ,,,　なお、以下ではテスト計画以外のアクティビティにおいても、シラバスに説明のあるタスクを抜粋して紹介しま,,, ,,,す。紹介するタスクは必ずしも順番に実施する必要はありません。理解しやすくなるよう、タスクの記述の順番,,, ,,,はシラバスとは異なる個所もありますのでご注意ください。,,, ,,,,,, ,,,◇スコープとリスクを特定し、テストの目的を定義する,,, ,,,,,, ,,,,　まず、テスト対象とする範囲（スコープ）を決定します。テスト対象となるのはプロダクトやサービスを構成,, ,,,,する機能やサブシステム、システムであり、そのすべてを対象とするのか、それとも一部分になるのかを検,, ,,,,討します。対象範囲は納入範囲かどうかといったように、契約に基づいて決まる場合もあるでしょうし、シス,, ,,,,テムの規模によって決まる場合もあるでしょう。そして、どういったテストを行うのかといった、テストの目的,, ,,,,を定めていきます。たとえば、欠陥の検出を主眼に置くのか、外部システムとのインタフェースレベルでの,, ,,,,疎通確認を網羅的に行うのかなどを決定します。,, ,,,,,, ,,,,　通常、テストの目的はテスト対象やスコープによって異なります。テスト時にはすべてのケースを実施する,, ,,,,ことは難しいため、テストのスコープを限定することも行います。,, ,,,,,, ,,,,　さらにこのタスクでは、テストの目的を達成するときに障害となり得る要因を挙げていきます。プロジェクト,, ,,,,全体に及ぶようなリスクならば、テスト計画で取り上げるのではなく、プロジェクト計画のリスクとして管理す,, ,,,,る必要があるでしょう。,, ,,,,,, ,,,◇,テストに対する包括的なアプローチを定義する。これには、テストレベル、開始基準、終了基準などの定義,, ,,,,も含む,, ,,,,,, ,,,,　このタスクでは、どのようにテストをすべきかといったポリシーや戦略を決定します。つまり、テストの目的,, ,,,,をここで具体的にします。プロジェクトや企画のゴールに沿ったテストの目的を定めてから、実際にテストで,, ,,,,実行することを決めるという事になります。,, ,,,,,, ,,,,　いったんテストの戦略が決まったら、戦略に沿ったテストとなるよう以降のアクティビティ（テストケースの,, ,,,,設計など）を定義していきます。テストの目的を達成できたかどうか、テストを完了してよいかどうかを判断,, ,,,,するための基準はこの段階で決定します。この基準はステークホルダ間で合意を得る事が出来るものでな,, ,,,,ければならず、テストの終了基準となります。,, ,,,,,, ,,,,　テストケースの実施率や合格率だけではなく、あらかじめ決められたカバレッジを満たしているかどうか、,, ,,,,成果物は揃っているかどうか、インシデントはすべて解決済みかどうか、インシデントは収束しているかな,, ,,,,ど、総合的に判断できるように、複数の基準を決めていきます。,, ,,,,,, ,,,◇,何をテストするか、テスト活動でどのような職務を実行するか、いつどのようにテスト活動を進めるか、,, ,,,,テスト結果をどのように評価するか、いつテストを終わらせるか（終了基準）を決める,, ,,,,,, ,,,,　テストの目的、戦略やアプローチに基づいて、実際にどのようにテストの活動をいつ進めていくかや、どう,, ,,,,進めるのかという手段（職務）を決定していきます。テスト結果を適切に評価するために、テストのレベルご,, ,,,,とに適用するテスト技法を決めたり、どのようなテストアイテムが必要かを決めていきます。,, ,,,,,, ,,,,　テストの目的や、戦略に沿うようにするだけではなく、テスト結果を正しく評価し、テストをいつ終わらせて,, ,,,,良いかを判断できるよう、終了基準の検討も行います。たとえば、テストの目的を考えずにカバレッジを決,, ,,,,めたとします。この場合、テストの目的とは異なったカバレッジ基準を選択してしまうと、不必要なテストケー,, ,,,,スを実施することになりかねませんし、終了基準としても不適切なものになってしまいます。,, ,,,,,, ,,,◇,定義したいろいろな活動にリソースを割り当てる,, ,,,,,, ,,,,　物理的なリソースとしては、まずテスト環境が挙げられます。テストを実施する場所や、テスト対象の動作,, ,,,,環境、テスト対象のバージョン、使用すべきテストツールなどを検討します。人的リソースなら、単に必要な,, ,,,,ヘッドカウント（人数）だけではなく、テストを担う技術者が保有すべきテスト設計や実施に必要となるテクニ,, ,,,,カルスキルやドメインスキルを明らかにします。,, ,,,,,, ,,,,　また、テスト環境やツールを理解するためのトレーニングを施す必要があるかないかなど、検討すべきこ,, ,,,,とは少なくありません。これら検討事項はすべてコスト（予算）に直結することばかりです。このことからも、,, ,,,,テスト計画はソフトウェア開発の初期段階で実行すべきであることがわかります。,, ,,,,,, ,,,◇,テストの分析と設計の活動をスケジューリングする,, ,,,,,, ,,,,　テスト対象を理解するための分析は、分析材料をそろえることから始めます。ブラックボックステストを行,, ,,,,うのであれば、要求仕様書やそのもととなる企画書やRFP（Request for Proposal）といったドキュメントを準,, ,,,,備します。グレーボックスやホワイトボックス的な観点ならば、アーキテクチャ定義書、基本設計書や詳細,, ,,,,設計書、モデル定義書、データベース設計書といったテスト対象が持つ核となる処理やアルゴリズムといっ,, ,,,,た内部構造を理解できる材料が必要となります。,, ,,,,,, ,,,,　現実の開発では、テスト設計をする技術者が欲しいドキュメントが揃っていないことの方が多いため、ある,, ,,,,だけの材料を集めたうえで、テスト対象の仕様を開発元やユーザに確認しつつ、テスト設計を進めることは,, ,,,,珍しくありません。ですから、材料の入手や仕様の問い合わせといった、分析のためのオーバーヘッドを計,, ,,,,算に入れておかなければなりません。また、分析やテスト設計の速さは、テスト技術者が持つ技術スキル,, ,,,,が大きく影響します。テストの分析と設計の活動をスケジューリングするにはこういった様々な要因を考慮,, ,,,,しなければならないため、できるかぎりプロジェクトの早い段階でスケジュールを立てておく必要があります,, ,,,,。,, ,,,,,, ,,,◇,テストの実装と実行、テスト結果の評価にかかる活動をスケジューリングする,, ,,,,,, ,,,,　計画の段階では、分析や設計作業のスケジューリングのように精密に行われることはなく、概算スケジュ,, ,,,,ールになります。テスト計画段階の初期において、大枠の工数やリソースを割り当てるために用います。実,, ,,,,際には、テストプロセスを取りまとめるリーダクラス以上の開発担当者やプロジェクトマネージャなどの管理,, ,,,,層が、過去の経験やテストに関わる工数の実績値などをもとに見積りを行うことが多いでしょう。,, ,,,,,, ,,,,　一方、詳細スケジューリングを立てる段階では、実際にテストケースを作成（実装）したり、テストを実施す,, ,,,,る開発担当者が詳細見積りを行います。なぜなら、実際にテストを行う担当者でないと工数予測が立てにく,, ,,,,い作業が多いからです。例えば、テストの作成段階では、テスト設計に基づくテストケースや手順の作成の,, ,,,,みならず、テストデータの準備やテスト自動化ツールのためのテストスクリプトの準備やその検証が必要で,, ,,,,しょうし、テスト環境の整備といった工数を勘定に入れなければなりません。,, ,,,,,, ,,,,　また、テスト実施中なら、事前準備やテスト実施後のデータや設定値などの復旧処理、インシデント発生,, ,,,,時にかかる工数もそれなりに必要となります。テスト実施結果を分析したり、テスト対象の品質を評価する,, ,,,,といったことも行うでしょう。こういった、純粋にテスト実施だけにかかる工数ではない作業があるため、直,, ,,,,接テストを設計し実施する技術者自身でないと、精度の高い見積りを行うのは難しいのです。,, ,,,,,, ,,◆テストのコントロール,,,, ,,,,,, ,,,　テストの計画段階を経て、テストの実施段階になりますが、この段階でコントロールのために行うタスクをいく,,, ,,,つか例示します。以下のタスク等を行うことで、テスト計画で定めたテストの目的を達成し、テスト戦略に合致し,,, ,,,たテスト戦術の遂行、つまりテスト実施になるようにコントロールしていきます。,,, ,,,,,, ,,,◇テスト結果の計測と分析,,, ,,,,,, ,,,,　テスト実施の評価は、合否判定が伴う項目だけではありません。パフォーマンス測定やリソース利用率の,, ,,,,計測などは、基準値の近似値であれば問題ないこともあれば、単に測定するだけという事もあるでしょう。,, ,,,,テストにより収集した計測値をもとに統計処理などを施し、妥当なパフォーマンスが得られているかどうか,, ,,,,分析するといったことも行います。,, ,,,,,, ,,,,　分析結果や計測値から合否判定を行う場合もあります。ホワイトボックステストであれば、コードカバレッ,, ,,,,ジをテスト実施と共に計測し、カバレッジを満たさないようならテストケースを追加・修正するといったことを,, ,,,,行います。,, ,,,,,, ,,,◇進捗、テストカバレッジ、終了基準のモニタリングと文書化,,, ,,,,,, ,,,,　テストの進捗をテストの消化率や合格率、テストケース当たりの故障の発生率や、機能単位の欠陥混入,, ,,,,率といったメトリクスを用いて、テストそのものが妥当かどうかを随時モニタリングしていきます。基本的にこ,, ,,,,ういったメトリクスの収集は日々行います。開発プロジェクトへのフィードバックや妥当性の検証は毎日行う,, ,,,,こともあれば、週に一度のプロジェクトミーティングなどでフォローすることもあります。このフォローは、テス,, ,,,,ト実行の日次報告や週間報告といった形式でドキュメント化し、テストの進捗状況を開発プロジェクトのステ,, ,,,,ークホルダ全員で把握できるようにします。,, ,,,,,, ,,,,　テストの進捗状況を把握する頻度は、テスト対象の開発規模（総工数、期間、機械の複雑度）や品質、納,, ,,,,期によって異なります。プロジェクトに適したモニタリングとフィードバックを行いながら、順調に終了基準を,, ,,,,満たす方向で進捗しているかを見極めつつ、テスト実行をコントロールしていきます。,, ,,,,,, ,,,◇欠陥修正の開始,,, ,,,,,, ,,,,　テスト実行を開始すると、テスト担当者からインシデントが順次報告されてきます。基本的には欠陥の修,, ,,,,正とテスト実行は並行で行われます。欠陥を修正したコンポーネントのテスト対象への反映は、プロジェクト,, ,,,,計画やテスト計画で定められた構成管理のタイミングで実施していきます。また、インシデントが発生しなく,, ,,,,なったかどうかを再度テストで確認するタイミングも、テスト計画で定められたタイミングになります。欠陥修,, ,,,,正の影響度によっては回帰テストを行い、既存の機能を破壊していないかどうかといったことも検証します,, ,,,,。,, ,,,,,, ,,,,　もし、テストの進捗全体を止めるようなインシデントや、そもそも発生してはならないような性質(アーキテク,, ,,,,チャに大きな影響を及ぼすものや、基本機能自体に欠陥があるなど）のインシデントがテスト実施時に発生,, ,,,,した場合はいったんテストを中断し、テストの前段階に差し戻して開発作業をやり直すかどうかを検討しま,, ,,,,す。,, ,,,,,, ,,,◇意思決定,,, ,,,,,, ,,,,　テスト進捗のモニタリングを行い、テストの中断、再開、終了といったテスト実施そのものに関わる意思決,, ,,,,定を適切に行っていきます。意思決定は開発プロジェクトそのものに影響を及ぼすことが多いため、テスト,, ,,,,をコントロールしている管理層のみならず、さらに上位の管理層やプロジェクトマネージャ、ときにはユーザ,, ,,,,が意思決定に参画する必要が出てきます。このため、意思決定には開発組織でのエスカレーション（上申）,, ,,,,手段を備えておかなければなりません。,, ,,,,,, ,■１．４．３　テストの分析と設計,,,,, ,,,,,, ,,　テストの分析と設計は、テストの実装とは別のアクティビティです。テストの分析では、テスト計画で定めたテスト,,,, ,,戦略に基づいてテストを行うための情報、つまりテスト対象の性質や品質、特徴などが記されたテストベースを収,,,, ,,集した上で、情報の取捨選択、再収集、新たに作成するなどを検討していきます。,,,, ,,,,,, ,,　分析を経てテスト対象に対して、どのようなテストをどのような手段で実施すべきかというテスト戦術を検討する,,,, ,,ためのタスクがテスト設計となります。シラバスでは、テストの分析と設計のアクティビティとして、以下の7つのタ,,,, ,,スクが定義されています。,,,, ,,,,,, ,,◆,テストベース（例えば、要件、ソフトウェア完全性レベル（リスクレベル）、リスク解析レポート、アーキテクチャ、,,, ,,,設計、インターフェース仕様）をレビューする,,, ,,,,,, ,,,　テスト設計の入力となるテストベースをテスト設計する技術者がレビューします。テストベースにはRFPや企,,, ,,,画書、購買証書といった発注者やユーザの視点で記されたドキュメントがあれば、要求仕様書やアーキテクチ,,, ,,,ャ定義書、リスク解析レポート、設計仕様書、インターフェース仕様書、標準文書（RFCやISO/IEC標準といった,,, ,,,公のものから、社内標準、組織内標準など、組織内での規定も含みます）といったものまで、テストのスコープ,,, ,,,により様々なものがあります。,,, ,,,,,, ,,,　テストベースにはドキュメントとして明文化されたものだけではなく、会議の議事メモやメールでのやりとり、ホ,,, ,,,ワイトボードでの開発時点でのメモ書きなども含まれます。必ずしも正規のドキュメントだけとは限りません。ま,,, ,,,た、開発でのコミュニケーション手段やスタイルによっても異なることを覚えておきましょう。,,, ,,,,,, ,,◆,テストベースやテスト対象のテスト容易性を評価する,,, ,,,,,, ,,,　テストベースのレビューを行った後、テストケースの実現性を検討します。たとえばユーザビリティ評価で、「,,, ,,,見えやすい」とか「聞こえやすい」とか「使いやすい」といったことを検証する必要があったとします。そのままで,,, ,,,はあいまいなため、テストを行うものの主観によりテスト結果が左右されてしまうでしょう。人に依存しない検証,,, ,,,とするためには、定性的な評価を定量的な評価に置き換えるテスト設計が必要です。具体的には、段階的な,,, ,,,評価を可能とするための基準や、標準といった「ものさし」を用いるか、ないのなら自ら用意できないか検討し,,, ,,,ます。,,, ,,,,,, ,,,　テストの容易性は、テスト対象が持つ構造的な観点からも考えていきます。アルゴリズムや中間的に生成さ,,, ,,,れるデータを確認するような場合、テストで直接UIから結果を見る事が出来なかったり、タイミングによっても目,,, ,,,で観測できないことがあるでしょう。こういった条件をテストする場合は、基本設計や詳細設計段階からテスト,,, ,,,実施時に、結果が確認できるためのメカニズムを実装に組み込んだり、あらかじめテストツールの利用を見越,,, ,,,した設計が必要となるでしょう。「テスト容易性」の開発段階早期での作り込みは、テストの効果や効率といっ,,, ,,,た点からも重要かつ有効です。,,, ,,,,,, ,,◆,テストアイテム、仕様、動作、ソフトウェアの構造などの分析に基づいて、テスト条件を識別し優先順位を付け,,, ,,,る,,, ,,,,,, ,,,　テストベースの収集からレビューを通した分析により、テストで検証すべき条件や要件を明らかにします。テ,,, ,,,スト環境を準備する都合から生じるテストが実施できる期間などといったスケジュール面の制約、テストを実施,,, ,,,する技術者が持つべき資格要件といったものも検討材料に加えるようにします。テストアイテムごとの仕様の,,, ,,,相違、類似点などをアイテム自身の動作や、ソフトウェアの構造などを分析することによりテスト条件を識別し,,, ,,,ていきます。テスト条件が明らかになったら、テストの目的（戦略）に沿うように、テスト条件の優先順位付けを,,, ,,,行います。,,, ,,,,,, ,,◆,高度なテストケースを設計し、優先順位を付ける,,, ,,,,,, ,,,　テストベースが揃い、おおよそのテスト分析ができテスト条件が明らかになればテスト設計を開始します。テ,,, ,,,スト設計では、テスト計画で示したテストアプローチやテスト設計方針に基づいて、テスト条件をテストの大項,,, ,,,目から中項目といった粒度で変換していきます。,,, ,,,,,, ,,,　つまり、いきなりテスト手順や期待結果などの詳細なところから検討するのではなく、テスト条件（テスト要件,,, ,,,とも呼ぶ）を網羅するようにテスト技法を用いて設計しています。”高度なテストケース”とは、このように抽象度,,, ,,,の高いテストケースのことを指しています。,,, ,,,,,, ,,,　網羅性を満たすには、要件や仕様に対するカバレッジとコードカバレッジの両方の視点が重要になります。,,, ,,,テスト設計は、基本的にはこれら２つのカバレッジを満たすように行います。,,, ,,,,,, ,,,　主要なテスト設計の視点の例として、テスト対象を利用する視点で見るための「ユーザ指向」、欠陥を見つけ,,, ,,,るための「フォールト指向」、要件の妥当性を見るための「要件指向」、設計通りにテスト対象が動作するかを,,, ,,,みる「設計指向」が挙げられます。,,, ,,,,,, ,,,　このようにテスト設計を行うと同時に、テストアプローチを基にテストケースごとに優先順位を割り付けます。,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,図１．１　テスト設計の視点（Ostrandの区分けをもとに電気通信大学の西康晴氏が図式化）,,, ,,,,,, ,,◆,テスト条件やテストケースをサポートする上で必要なテストデータを識別する,,, ,,,,,, ,,,　テストアイテム間の機能的な連携がどのようなものなのか、アイテムレベルとアイテムを結合したシステムレ,,, ,,,ベルで用意すべきテストデータは異なるのかどうか（テストツールで自動生成したデータをテストレベルごとで,,, ,,,用い、システムレベルでは実測データや本番データを使用するなど)といった検討を行い、必要となるテストデ,,, ,,,ータを識別します。,,, ,,,,,, ,,◆,テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する,,, ,,,,,, ,,,　テスト実施に必要な環境を物理的側面および論理的側面から識別します。,,, ,,,,,, ,,,　クライアント/サーバー構成をとるならば、開発環境と、テスト環境を分離するか否かといったことを検討しま,,, ,,,す。OSやミドルウェアのバージョンやバンドルするアプリケーションの種類やそれらの組み合わせについても,,, ,,,考慮しなければならない場合もあります。組込み開発であれば、テストレベルをプロトタイプ→試作機→量産,,, ,,,試作機→実機の開発段階に、どのようにリンクさせるかについても検討します。,,, ,,,,,, ,,,　論理的な側面としては、テスト実施におけるミドルウェアやファームウェアの可変パラメータに対するデフォル,,, ,,,ト値や、チューニング可能なテーブル設定の組み合わせといったようなこともこのタスクで検討します。,,, ,,,,,, ,,,　テストケースには、テストドライバやテストツール（組込みの世界では冶具（じぐ）とも呼ばれます）無しではテ,,, ,,,スト実施できないものもあるでしょう。たとえテストが実施できたとしても、その準備やテストデータの設定に時,,, ,,,間と労力がかかるようであれば、テストの有効性を損なわないようにして代替項目の検討を行うことがありま,,, ,,,す。品質とテスト実施におけるコストとのトレードオフから、テストの必要性の有無を判断することもあります。,,, ,,,,,, ,,◆,テストベースとテストケースの間で双方向のトレーサビリティを作成する,,, ,,,,,, ,,,　開発の成果物間においてトレーサビリティ(追跡可能性）を確保しておかなければ、一貫性と整合性を保った,,, ,,,製品開発は出来ません。このことは、テスト設計の元となるテストベースと、テスト設計の結果であるテストケ,,, ,,,ースにおいても同様です。例えば、システムテストのテストベースが要求仕様書であったとしましょう。,,, ,,,,,, ,,,　トレーサビリティが確保できている状態であれば、要求仕様書の変更があっても、テストケースのどこを変更,,, ,,,すべきかは容易に把握できます。言い換えると、トレーサビリティの管理がいい加減な状態だと、要求仕様の,,, ,,,変更があった時に、テストケースの変更に抜け、漏れが生じる可能性が高くなります。トレーサビリティが確保,,, ,,,できていないこと自体が、致命的な欠陥を内在する要因となります。トレーサビリティは、トレーサビリティマトリ,,, ,,,クスを作成したり、要求管理ツールやALM（Application Lifecycle Management）ツールを導入することで確保し,,, ,,,ていきます。,,, ,,,,,, ,■１．４．４　テストの実装と実行,,,,, ,,,,,, ,,　「テストの分析と設計」タスクで行われたテストの大・中項目の定義に基づいて、実際にテストを実施するための,,,, ,,手順や確認項目の詳細となるテストケースやテスト手順書、テストスクリプトといったテストウェアへ変換します。,,,, ,,また、テスト実装だけではなく、テスト環境の構築もこのタスクで行います。,,,, ,,,,,, ,,　前段階として、テストの実施で必要となるテスト実施者のスキルセットを定義しておきます。テストツールやテスト,,,, ,,スクリプトを実装するためのプログラミングスキルを要求されたり、ドメインスキルが要求されることがあります。テ,,,, ,,スト実施者のスキルセットはテストウェアを記述する粒度に直接影響します。テストの手順や段取り、テストでの,,,, ,,確認ポイントをどれだけ詳細に記述すべきかは、テスト実施者のスキルレベルによるからです。,,,, ,,,,,, ,,　注意すべき点としては、ユーザ指向でのテストの場合、開発担当者視点がかえって邪魔になることもありえます,,,, ,,。このようなときはテスト戦略に基づいたテスト実施となるように、たとえばプロファイリングを行って、テスト実施,,,, ,,者の適性が、代表的なユーザ層に合致しているかどうかを考慮するなどしなければなりません。テスト実施者の,,,, ,,スキルレベルにあったテストを実装しないと、テストの妥当性が低下したり目的から外れた意味のないテストにな,,,, ,,りかねません。,,,, ,,,,,, ,,　シラバスでは、テストの実装と実行アクティビティは以下の10個のタスクで構成されるとしています。,,,, ,,,,,, ,,◆,テストケースを決定し、実装し、優先順位を付ける,,, ,,,,,, ,,,　テスト設計仕様を基にテストケースを作成し、まとめていきます。ISTQBでは、IEEE 289-1998（以下、IEEE 82,,, ,,,9）に準拠した成果物の定義をしているため、テストで確認すべき事項をまとめたテストケースとテストの実施,,, ,,,手順である手順書が分かれていることに注意してください。,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,図１．２　IEEE 829でのドキュメント体系,,, ,,,,,, ,,,　テストケース実行の優先順位は、テスト計画やテスト設計で決めた優先順位（たとえば、テスト条件に定義し,,, ,,,た優先順位）に基本的に準拠します。ただし、テスト条件をまたがってテストスイートをまとめることも多いこと,,, ,,,や、テストケースごとの優先順位だけではなく、テストの準備や後片付けなどの段取りによって効率の良い実,,, ,,,行手順が異なってくることから、当初の優先順位とはテストの優先順位が変わることがあります。,,, ,,,,,, ,,◆,テスト手順を開発し、優先順位を付け、テストデータを作成する。場合によってはテストハーネスを準備し、テス,,, ,,,トの自動実行スクリプトを書く,,, ,,,,,, ,,,　テスト手順の作成とテストデータの作成、テストハーネスの準備は並行して行うことが多いのですが、この前,,, ,,,提としてテストハーネスの仕様が固まっていなければなりません。またテストデータの作成においてテストハー,,, ,,,ネスを使う場合は、テストハーネスの完成を待ってデータを準備するとともに、テストスクリプトを作成すること,,, ,,,になります。,,, ,,,,,, ,,◆,効率よくテストを実行するため、テスト手順をベースにしてテストスイートを作る,,, ,,,,,, ,,,　前セクションのとおり、テストスイートはテスト手順やテストハーネスの準備、後片付けなどテスト実施効率を,,, ,,,考えた上で、テストケースを組み合わせてまとめていきます。段取りだけではなく、たとえばフォールト指向で,,, ,,,あるなら、欠陥を効率よく検出できるように異常パターンを検証するテストケースをまとめてテストハーネスを,,, ,,,形成することもあります。このようにテストの実施目的、テスト実施の効率に直接影響するため、基本的にはテ,,, ,,,スト実施に責任を持つ技術者自身がテストスイートを作らなければなりません。,,, ,,,,,, ,,◆,テスト環境を正しくセットアップしたことを確認する,,, ,,,,,, ,,,　テスト実施に先立ち、テスト実施環境全体の整備を行います。テスト対象そのもののセットアップのみならず,,, ,,,、テストツールやテストハーネス、計測機器などテストに必要となる設備の準備作業のすべてこのタスクに含ま,,, ,,,れます。テスト対象を外部のシステムや機器と接続してテストを行う場合は、その準備も含まれます。タスクと,,, ,,,してはこうしたテスト全体を実施するためのセットアップと、日々のテストのための準備とを必要に応じて分け,,, ,,,て管理することになります。,,, ,,,,,, ,,◆,テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する,,, ,,,,,, ,,,　テストの分析と設計において、トレーサビリティを確保するための仕掛けは、トレーサビリティマトリクスを作,,, ,,,成することなどで用意します。テストの実装と実行では、仕様変更やインシデントへの対応に伴ってテストベー,,, ,,,スが変更された時点で、関連するテストケースも変更（削除、修正、追加）していきます。,,, ,,,,,, ,,◆,計画した順番に従い、テスト手順を人力、もしくはテストツールで実行する,,, ,,,,,, ,,,　作成したテストケースを手動、自動にかかわらず、計画に従って実行するタスクとなります。テストケースの,,, ,,,実行には、テストスイートまたはテストケースレベルで規定されたテスト実施の最小粒度ごとに行う事前準備、,,, ,,,実行、後片付けのすべてが含まれます。,,, ,,,,,, ,,◆,テストの実行結果の記録を取り、テスト対象のソフトウェア、テストツール、テストウェアのIDとバージョンを記録,,, ,,,する,,, ,,,,,, ,,,　テスト結果をテストケースや手順で定めた方法に従って記録として残します。ここで言う記録とは、コンピュー,,, ,,,タ上に記録されたデータファイルだけではなく、観測結果をまとめた手書きのメモや、計測結果をテスト対象以,,, ,,,外の計測機器で採取した結果も含まれます。また、テストを実施した環境となるテスト対象のソフトウェアやソ,,, ,,,フトウェアが搭載された環境（OS、システム構成、ハードウェア構成、バンドルアプリケーションなど）、テストツ,,, ,,,ールの構成やバージョン、テストウェアのID（項目番号、採番）などをエビデンス（証拠）として記録に残します。,,, ,,,,,, ,,◆,実行結果と期待する結果を比較する,,, ,,,,,, ,,,　テストケースやテスト手順の確認項目や判定項目、テスト全体の合否を規定した標準文書の定義とテスト結,,, ,,,果を比較します。結果が一致した場合や、単に計測を目的にした項目である場合は、テストを合格又は実施,,, ,,,済みとして、ログを残し、次のテストケースの実行に移ります。,,, ,,,,,, ,,◆,両者が一致しない場合、インシデントとして報告し、原因（コード、テストデータやテストドキュメントの欠陥、テス,,, ,,,ト実行手法の誤りなど）を解明するためにインシデントを分析する,,, ,,,,,, ,,,　テストの結果が期待結果と異なっていれば、インシデントとして報告文書にまとめます。報告としてまとめるた,,, ,,,めに、インシデントの直接的な事象だけではなく、ほかの要因で同一の問題が起きるかどうかや、当該テスト,,, ,,,ケース以外にも影響がでていないかどうかといったことを調査、分析します。ISTQBではインシデントを記録し,,, ,,,たものをインシデントログ、その報告をインシデントレポートと定義していますが、不具合報告書やバグレポー,,, ,,,ト、問題点処理票など呼び方は組織によってさまざまです。,,, ,,,,,, ,,◆,実行結果と期待する結果が一致しないケースごとに、テスト活動を繰り返す。例えば、修正が正しいことを確,,, ,,,認するため、前回不一致となったテストケースを再実行（確認テスト）したり、改訂版のテストケースや元のテス,,, ,,,トケースを実行したり、変更していないプログラム部分に新たな欠陥が入り込んでいないことや、欠陥修正によ,,, ,,,り陰に隠れていた欠陥が現れないことを確認したりする（回帰テスト）,,, ,,,,,, ,,,　回帰テストとは、欠陥を修正した後に、既存の機能に悪影響が出ていないことを確認するテストのことです。,,, ,,,テストレベル単位のテスト実施がすべて完了した後に、主要なテストケースを繰り返すテストも回帰テストと言,,, ,,,えます。この場合、当該テストレベルの実施中に修正したすべての欠陥が、これまで実施済みとなったテスト,,, ,,,結果へ影響していないことを検証するために行います。この種の回帰テストは、次の開発プロセスやテストレ,,, ,,,ベルへ移行する判断基準として使うこともできます。,,, ,,,,,, ,■１．４．５　終了基準の評価とレポート,,,,, ,,,,,, ,,　このタスクでは、テスト計画段階でテストレベルごとに設定した終了基準に対して、テスト実施結果やテスト進捗,,,, ,,状況、欠陥の検出/修正状況が、基準を満たしているかどうかを評価します。計画段階での終了基準は、あくまで,,,, ,,テスト開始前の仕様や品質に対する前提を基に決めていますから、テストの進捗によって明らかになってきた仕,,,, ,,様や、顧客ニーズの変化による品質ゴールの再設定などにより見直されることがあります。,,,, ,,,,,, ,,　シラバスでは、終了基準の評価のアクティビティは、以下の３つのタスクで構成されるとしています。,,,, ,,,,,, ,,◆,テスト結果の記録をテスト計画作業で定義した終了基準と比較する,,, ,,,,,, ,,,　テストの記録から、テスト実施によってテスト計画段階でのテスト実施の目的を果たしているかどうかを分析,,, ,,,します。具体的には、コードカバレッジを満たしているかどうかや、要件や仕様に対するカバレッジが十分な,,, ,,,テストを実施しているかどうか、非機能要件に対するテストは十分実稼働を想定したものとなっていたかどうか,,, ,,,、テスト対象の機能やシステム構成などの組み合わせ要因を十分に網羅しきれたかなどを見ていきます。,,, ,,,,,, ,,,　終了基準はテストの目的によって異なります。テスト実施による合否判定や測定結果から直接導かれる基,,, ,,,準以外に、バグ管理図を使ってテストケースの消化率と欠陥の検出が想定通りだったかどうか、欠陥が収束,,, ,,,しているかどうか（まだ欠陥が検出可能かどうか）、検出した欠陥はテストの目的で狙った通りのものなのか（,,, ,,,たとえば、ユニットテストで検出されるべき欠陥が統合テストで多く出ていないかなど）といったものもあります。,,, ,,,このように、テストのコントロールによって収集したメトリクスも基準となります。,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,,,, ,,,図１．３　バグ管理図,,, ,,,,,, ,,◆,追加テストが必要か、あるいは定義した終了基準を変更するべきかを判断する,,, ,,,,,, ,,,　テストの実施結果と終了基準とを比較・分析し、終了基準を満たしていない場合は、さらに追加テストが必要,,, ,,,かどうかを判断します。テストの結果がまったく終了基準を満たしていなかったり、欠陥の分析結果が当該テ,,, ,,,ストレベルより前のテストレベルで検出されるべき欠陥が多くを占めているのなら、テストレベルの差し戻しや,,, ,,,再実行といったことを検討することも起こり得ます。テスト計画段階から条件や前提が変わっている場合には,,, ,,,終了基準自体も見直すことがあります。,,, ,,,,,, ,,,　コードカバレッジを厳密に定義しすぎたため、納期が近づいているにもかかわらずテストが終了できないとし,,, ,,,たら、重要な機能については当初のカバレッジ基準のままにして、それ以外はカバレッジ基準を緩和するとい,,, ,,,ったこともあるでしょう。,,, ,,,,,, ,,◆,ステークホルダにテストサマリレポートを書く,,, ,,,,,, ,,,　テスト結果と終了基準の比較・分析結果から、最終的にそのテストレベルを終了できるかどうかの判定をス,,, ,,,テークホルダに報告するためのドキュメントを作成します。IEEE 829をベースにしている場合、サマリレポート、,,, ,,,つまり概要報告という体裁をとっています。サマリレポートではテストレベルの全体的な合格率が基準を満たし,,, ,,,ているかどうか、インシデントの報告件数や対応状況はどうだったのかといったことを整理して取りまとめ、テ,,, ,,,ストレベルに関わるステークホルダに報告することを求めています。,,, ,,,,,, ,,,　ステークホルダは、テストレベルやテスト対象によって異なります。わかりやすく言うと、そのテストレベルを,,, ,,,終わらせたあとに、直接的/間接的に影響を受ける関係者に状況報告をするということです。,,, ,,,,,, ,■１．４．６　終了作業,,,,, ,,,,,, ,,　テスト結果と終了基準の分析から、当該テストレベルを終了する（場合によっては打ち切る）ことに対して、ステ,,,, ,,ークホルダから合意が得られれば（現実的には、開発責任者の指示により終了することもあり得ますが、その場,,,, ,,合のステークホルダは開発責任者となります）そのテストレベルの終了が宣言されます。テスト結果のエビデンス,,,, ,,を残す必要があるなら、テスト実施により得られた合否判定結果、計測データなど、テストのコントロールのアクテ,,,, ,,ィビティにより分析した結果をとりまとめます。独立したテストチームがテストを行う場合、まとめた結果を文書化す,,,, ,,るのも、このアクティビティで行います。,,,, ,,,,,, ,,　バージョンアップを繰り返すプロダクトやさまざまな機種に移植するプロダクトの場合、テストケースやテストハー,,,, ,,ネス、テスト手順といったテストウェアをメンテナンスして、次のリリースや機種に備えるといったことも実施します,,,, ,,。,,,, ,,,,,, ,,　シラバスによれば、終了作業は以下の７つから構成されています。,,,, ,,,,,, ,,◆,計画にある成果物がリリースされたかをチェックする,,, ,,,,,, ,,,　テスト計画の段階で、テストウェアとして作成することを定めたドキュメントが公式にリリース（発行）されてい,,, ,,,るかどうかのチェックを行います。チェック自体はテクニカルレビューで行い、成果物の有無のチェックはプロジ,,, ,,,ェクトレビューで行います。ただし、成果物のリリースは、開発形態によって異なるため注意が必要です。,,, ,,,,,, ,,,　たとえば、プロダクトを分割してリリースしたり、機種展開の形でリリースするような違いがあります。また、当,,, ,,,該テストレベルの完了を検収するといったシステム受領のためのプロセスやステークホルダが存在するならば,,, ,,,、検収のためのドキュメントを作成したかどうかのチェックも行います。,,, ,,,,,, ,,◆,インシデントレポートを終了させるか、もしくは未対策の欠陥を変更記録に載せる,,, ,,,,,, ,,,　終了作業を行っているテストレベルと以前のテストレベルにおいて発行したインシデントレポートで、まだこの,,, ,,,段階になっても解決できていないものがあるかどうかをチェックします。既に問題ではなくなっているインシデン,,, ,,,トがあれば、そのレポートは完了/クローズ（終了）にします。次のテストレベルでの対応が決まっている場合は,,, ,,,、当該インシデントを次のテストレベルに引き継ぐか、変更記録に未対策であることを記載して、対応が漏れる,,, ,,,ことの無いようにします。,,, ,,,,,, ,,◆,システムを受け入れるために文書を作成する,,, ,,,,,, ,,,　システムテストレベルでの終了作業であった場合は受入テストへ進むときに、受入テストの前準備として必,,, ,,,要となるシステム環境やデータ準備、ファイル設定などを、テスト実施を通して妥当であると検証できた内容に,,, ,,,てまとめ、文書化します。,,, ,,,,,, ,,◆,次回も使えるように、テストウェア、テスト環境、テストのインフラストラクチャをまとめ、文書に記録する,,, ,,,,,, ,,,　テストそのものが再利用可能である場合には、再利用のための整理やメンテナンスを行います。直接テスト,,, ,,,ウェアに手を入れることがあれば、ガイドラインやトレーニング資料を整備したり、テストスクリプトをテストツー,,, ,,,ルのバージョンアップ後も使えるように手直しするなど、再利用のためにすべきタスクではそれなりの工数が,,, ,,,必要となります。,,, ,,,,,, ,,◆,テストウェアを保守部門に引き渡す,,, ,,,,,, ,,,　プロダクトの開発部門と保守部門が異なる場合、テストウェア一式を保守部門へ引き渡します。保守部門で,,, ,,,はテスト結果からプロダクトの品質状況を把握したり、リリース後にインシデントが起きた時のトラブルシューテ,,, ,,,ィングなどにおいてテストウェアを利用します。,,, ,,,,,, ,,◆,次回のリリースやプロジェクトのために教訓とすべきことをまとめる,,, ,,◆,その情報をテストの成熟とを改善するために利用する,,, ,,,,,, ,,,　これら２つのタスクはセットで行います。これらのタスクを実行するために、テスト終了宣言を受けて当該テス,,, ,,,トレベルのステークホルダ全員が集まる「ポストモーテム」を開催します。ポストモーテムとは、日本語では検,,, ,,,死のことです。ポストモーテムは、テストコントロールにおける課題や問題、テスト結果やその分析・評価をもと,,, ,,,に、プロセスやテストウェアを継続的に改善するためにテストのアクティビティ全体の良かった点、悪かった点,,, ,,,を包み隠さず話し合う場（会議）となります。洗いざらいプロセス改善をするための議論を尽くすことから、ポス,,, ,,,トモーテムという用語が用いられています。,,, ,,,,,, ,,,　ポストモーテム（振り返り）の機会で得られた改善ポイントや継続して実施すべき事柄を、次のテストレベル,,, ,,,やプロジェクトに確実に引き継げる体制を構築しないと、その場限りの振り返りに終わってしまい改善には結,,, ,,,び付きません。このため、議事録やアクションアイテムリストを記録し、それをマネジメント層もチェックし、フォ,,, ,,,ローしていくといった組織的な取り組みを行うことで、改善へとつなげることができるようになります。,,, 　,,,,,, ■１．５　テストの心理学,,,,,, ,,,,,, ,　「テスト担当者は、ネガティブで暗い」などという印象を持っていないでしょうか。重箱の隅をつつくようなテストばか,,,,, ,りで、システムのエラーや欠陥を意地悪く指摘されたらテスト担当者の性格を疑いたくもなるものです。しかし、テスト,,,,, ,の目的は「欠陥を見つける」だけではありません。「欠陥を見つける」行為のほかに「正しく動作している」ことの確認,,,,, ,や「欠陥の作り込みを防ぐ」ことも含んでいます。,,,,, ,,,,,, ,　実際のテストでは、「欠陥を見つける」ことより「正しく動作している」ことの確認をしていることの方が多いはずです,,,,, ,。テストの心理学というと、なにやら難しく捉えてしまいがちですが、テストは実行する人の立場により目的が異なるも,,,,, ,のだと捉えれば理解しやすくなります。,,,,, ,,,,,, ,　この節では、テストを担当する人の役割とその目的からテストの心理学の背景を説明します。,,,,, ,,,,,, ,■１．５．１　独立性を確保したテスト,,,,, ,,,,,, ,,　ソフトウェアのテストには、ソフトウェアの作成を担当した開発担当者が自らテストする場合と、ソフトウェアの開,,,, ,,発は行わずにテストを専門に実施するテスト担当者によるテストが存在します。それぞれのテストでは、目的と効,,,, ,,果が違います。ソフトウェアを作成した本人が実施するテストは、対象の中身を理解しているため、多くのコード（,,,, ,,プログラム）の中の欠陥を見つけることが期待できます。,,,, ,,,,,, ,,　反面、開発担当者自身がテストを実施すると、先入観や時間的な猶予の不足およびその他のプレッシャーがテ,,,, ,,ストの結果に大きな影響を与えかねません。テストに十分な時間的余裕があり、欠陥が発見された場合でも適切,,,, ,,な対応を実施できる状況にあれば、テストの結果に高い効果が見込めますが、緊迫した状況の下では効果は望,,,, ,,めないかもしれません。,,,, ,,,,,, ,,　独立性を確保したテストでは、開発担当者であれば影響が心配される先入観や思い込みなどのバイアスを排,,,, ,,除することができる反面、テスト対象の理解などの時間が必要になります。開発担当者のテストと独立性を確保し,,,, ,,たテストは、テストの目的により効果が異なるのです。,,,, ,,,,,, ,■１．５．２　独立性の度合い,,,,, ,,,,,, ,,　一般的に組織的な独立性が高くなればなるほど、バイアスの影響を受けにくくなります。以下に低レベルから高,,,, ,,レベルまでの独立性の度合いの違いを具体的に説明します。,,,, ,,,,,, ,,◆,ソフトウェアを作成した本人がテストを設計する（独立性が最も低い）,,, ,,,,,, ,,,　開発担当者は、自分の作ったソフトウェアの中身を他の誰よりも熟知しています。作成した本人がテストを設,,, ,,,計すると、数多くの欠陥を発見することが期待できます。しかし、設計書をもとにプログラムを記述するときに,,, ,,,誤った解釈をしていたら、作成した本人では故障や欠陥に気が付かない場合があります。開発担当者本人が,,, ,,,担当するテストでは、先入観による影響を最も受けやすくなります。,,, ,,,,,, ,,◆,開発担当者とは別の人（開発チームの人）がテスト設計する（独立性が低い）,,, ,,,,,, ,,,　同じチームでもソフトウェアの作成者以外の開発担当者がテスト設計すると、作成者の先入観が排除される,,, ,,,ため、作成者では見逃してしまうエラーや欠陥を発見することが期待できます。また、作成者のクセや誤りに陥,,, ,,,りやすいポイントなどをチェックするレビュー効果もあります。,,, ,,,,,, ,,◆,開発担当者とは別の部署の人（たとえば独立したテストチーム）またはテストの専門家（たとえばユーザビリテ,,, ,,,ィテストまたは性能テストの専門家）がテスト設計する（独立性が高い）,,, ,,,,,, ,,,　独立したテストチームが設計するテストでは、開発担当者の先入観は排除することができます。開発担当者,,, ,,,と組織的に独立しているため、客観的なテストが可能になります。,,, ,,,,,, ,,◆,開発担当者とは別の会社の人がテスト設計する（すなわち、外部のテスト会社へ委託や、外部団体の認証を,,, ,,,受ける）（独立性が最も高い）,,, ,,,,,, ,,,　もっとも独立性が高いテストで、第三者的な立場でプロダクトをテストできる場合が多くなります。法令や業界,,, ,,,標準および規格に準拠していることを証明するために、外部団体の認証を受けることもあるでしょう。,,, ,,,,,, ,■１．５．３　テストの目的の明確さ,,,,, ,,,,,, ,,　「欠陥を見つける＝テスト」と考えている方も多いのではないでしょうか。実際に、テストを実施したのに検出した,,,, ,,欠陥が少ないとクレームを受けることもあるでしょう。しかし、テストの大半は「ソフトウェアが目的を果たしている」,,,, ,,ことを確認することの方が多いでしょう。テストの目的を明確にすることで、目的に沿ったテストの計画を立案でき,,,, ,,、単に納期など、プロジェクトの都合に合わせてしまうことなく作業を進める事ができます。,,,, ,,,,,, ,■１．５．４　欠陥のフィードバックとコミュニケーション,,,,, ,,,,,, ,,　テストの担当者と開発担当者とでは、どちらも品質を確保した開発を行うという目的において、どちらの立場が,,,, ,,有効かどうかといった優位性に差はありません。それぞれの立場で有効な手段を打たなくてはなりません。,,,, ,,,,,, ,,　テストでは、要求された仕様の動作を様々な視点で確認していきます。中には、システムが破壊に至るような過,,,, ,,激なテストが含まれていることもあります。,,,, ,,,,,, ,,　故障を見つけたのに、開発者から非難と受け取られる場合もあります。その結果、プロダクトリスクのマネジメン,,,, ,,トの観点からは建設的ながら、破壊的な活動とみられることもあります。,,,, ,,,,,, ,,　見つけたエラー、欠陥、故障を建設的（前向き）にとらえることができれば、テストの担当者からの非難と受け取,,,, ,,られることがなく、開発担当者と敵対関係に陥ることは避けられます。これらは、レビュー時に発見される欠陥でも,,,, ,,同様です。,,,, ,,,,,, ,,　テストの目的を達成するために、あらゆる可能性を導き出し、一つ一つ蓄積していきます。テストの実施中に発,,,, ,,見した欠陥や故障は、システムの品質を改善させる要素です。テスト担当者がインシデントを報告するだけでは,,,, ,,品質は改善されません。インシデントが引き起こす利用者などへの影響度、インシデントが再現する手順などを,,,, ,,正確に開発担当者に伝えなければいけません。これらの情報が正確に開発担当者に伝わり、欠陥が修正される,,,, ,,などの適切な処理が施されることで、初めて品質が改善されたことになります。,,,, ,,,,,, ,,　このときにテスト担当者と開発担当者のコミュニケーションに問題があると正常な処理が実施されなくなります。,,,, ,,このためテスト担当者やテストリーダは、欠陥、テストの進捗、リスクの情報をやり取りする場合、建設的に作業,,,, ,,が進むよう優れたコミュニケーションスキルが必要となります。,,,, ,,,,,, ,■１．５．５　テスト担当者と開発担当者の心理の違い,,,,, ,,,,,, ,,　ソフトウェアの開発に従事するすべての人（開発を担当する人やテストを担当する人）は、ユーザに求められる,,,, ,,品質を満たすことをゴールにしなくてはいけません。テスト担当者が発見したインシデントの報告は、正しく開発担,,,, ,,当者に伝達され、欠陥修正などの適切な処置が実施されることで品質が確保できます。,,,, ,,,,,, ,,　テスト担当者と開発担当者が敵対的な関係になると、円滑なコミュニケーションが望めなくなります。テスト担当,,,, ,,者や開発担当者の置かれている環境が異なると心理的な温度差さえ生じます。そのことを良く理解して、良好な,,,, ,,関係を保ちつつコミュニケーションをとらなければいけません。次にコミュニケーションや関係を改善する方法を説,,,, ,,明します。,,,, ,,,,,, ,,,・,テスト担当者と開発担当者は敵対者ではなく、同じ品質のゴールを掲げたシステムの開発に携わるチーム,, ,,,,であることを再認識します。,, ,,,・,プロダクトに対する指摘は、中立で、事実を中心にして実施し、欠陥を作り込んだ担当者を非難する方向に,, ,,,,行かないようにします。例えば、客観的かつ事実に基づいたインシデントレポートを書いたり、見つけたこと,, ,,,,をレビューしたりします。,, ,,,・,他人の気持ちや反応を理解するように努力します。テスト担当者と、開発担当者の置かれている状況を相,, ,,,,互に理解して、協調して問題に対応するよう努力する必要があります。具体的には、テスト担当者の立場,, ,,,,なら開発担当者の欠陥の対応が円滑に進むように、インシデントが故障かどうかの切り分け、故障の再現,, ,,,,性の確認、故障発生環境の提供などの状況を判断しながら行っていくことが該当します。,, ,,,・,自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを円滑なコミュニケーション,, ,,,,を通じて確認します。,, ,,,,,, ,,　インシデントの報告は、ソフトウェアの開発担当者への中傷ではありません。インシデントを発見したテスト担当,,,, ,,者は、開発担当者に適切な情報を提供しなければなりません。次のような情報は、開発担当者に欠陥の処置を,,,, ,,促す動機付けになります。,,,, ,,,,,, ,,,・,故障が与える影響度（影響の範囲や重要度）が明確になっている,, ,,,・,故障の再現手順が正しく報告されている,, ,,,・,故障の内容が理解しやすい適切な表現を用いた報告が行われている,, ,,,,,, ■１．６　行動規範,,,,,, ,,,,,, ,　この節では、ソフトウェアテストに関与する際の行動規範について解説します。,,,,, ,,,,,, ,■１．６．１　行動規範,,,,, ,,,,,, ,,　本書の読者がどのような立場であれ、ソフトウェアテストに関与することで、重要な機密情報を知る機会に遭遇,,,, ,,します。例えば、市場で発売される前の最新家電製品のテストに携われば、そこでテストする対象のすべてが機,,,, ,,密情報です。ISTQBでは、ACMおよびIEEEが制定したエンジニアのための行動規範を基に８つの行動規範を示し,,,, ,,ています。次から８つの行動規範についてそれぞれ解説していきたいと思います。,,,, ,,,,,, ,,◆,公人-認定されたソフトウェアテスト担当者は、常に公人として行動しなければならない,,, ,,,,,, ,,,　公人とは、大辞泉によると「公職にある人。公務員・議員など。また、社会的な立場にある場合の個人」と書,,, ,,,かれています。ソフトウェアテストに携わる人が公人であるという意義は、テスト結果が製品の品質を判断す,,, ,,,る最も重要な材料であることからくるのだと考えられます。,,, ,,,,,, ,,,　たとえば、テスト中に重大な不具合を見つけた際に、修正によるプロジェクトの納期遅延や予算超過を意識,,, ,,,するよりも、公共の利益（つまり、ソフトウェアに関与することになる多くの人たちにとって最適な対応）を第一に,,, ,,,考えた行動を求められるということです。,,, ,,,,,, ,,◆,顧客と雇用主-認定されたソフトウェアテスト担当者は、常に公人として行動しつつ、顧客や雇用主に最大限,,, ,,,の利益をもたらさなければならない,,, ,,,,,, ,,,　上記の「公人」についての解説にて、プロジェクトの納期や予算を厳守するよりも公共の利益を中心に考えな,,, ,,,ければならないと書きましたが、公共の利益があれば、なんでも良いとはなりません。自身のテストがビジネス,,, ,,,として対価を得ているからには、対価にふさわしい情報提供を顧客や雇用主に行わなければならないからで,,, ,,,す。,,, ,,,,,, ,,,　また、顧客や雇用主に不利になるような情報が漏洩することを防ぐことも大事なことです。発売前の製品の,,, ,,,情報が市場に漏れることや、その製品の不具合が誤って一般公開されてしまわないように厳重な注意のもと,,, ,,,で仕事をしていかないといけません。,,, ,,,,,, ,,◆,プロダクト-認定されたソフトウェアテスト担当者による成果物（自身がテストしたプロダクトやシステムに関す,,, ,,,るもの）は、プロフェッショナルとして高いレベルのものでなければならない,,, ,,,,,, ,,,　テストにかかわる私たちは、品質という一見目に見えないものを扱っています。品質を扱うもののアウトプット,,, ,,,が読みづらいものであったり一貫性がないものであると、ソフトウェアの品質を説明できず、対価にふさわしい,,, ,,,情報提供ができているとは言えません。「テストレポートが読みづらかったら恥ずかしい」という自覚が必要で,,, ,,,す。,,, ,,,,,, ,,◆,判断-認定されたソフトウェアテスト担当者によるプロフェッショナルとしての判断は、誠実なものであり、かつ,,, ,,,自身でなしたものでなければならない,,, ,,,,,, ,,,　誠実な判断とは、公人であることと、顧客と雇用主に最大限の利益をもたらしていることのバランスに基づい,,, ,,,た判断を指します。テスト結果を基にした品質判断は、方程式のような確実な正解が導けるものとは違います,,, ,,,。自分自身がその判断に納得していないと、関係者にもその判断の説明ができなくなります。,,, ,,,,,, ,,◆,マネジメント-認定されたソフトウェアテストマネ-ジャおよびリーダは、ソフトウェアテストのマネジメントに対,,, ,,,する倫理的なアプローチに同意した上で、これを推進しなければならない,,, ,,,,,, ,,,　倫理的なアプローチとは、公人として顧客と雇用主に最大限の利益をもたらすためのテストの方法を指すこ,,, ,,,とになります。具体的には、「倫理的なアプローチ」がプロジェクトごとに異なることかもしれないため、各プロジ,,, ,,,ェクトで同意が必要になります。たとえば、納品間際に不具合が見つかり、修正することによって納期遅延を起,,, ,,,こしかねないときには公人として不具合をより正しく報告することが大事です。これは１つ目の規範にて触れま,,, ,,,した。,,, ,,,,,, ,,,　ただ、２つ目の規範で触れた顧客と雇用主に最大限の利益をもたらすにはどうすればよいでしょうか。不具,,, ,,,合の報告はより開発者が欠陥の修正が容易になるようにレポートすべきですし、修正後の再テストの時間が,,, ,,,より少なくなるための準備（影響箇所の把握や自動テストの準備など）が求められます。これらを合わせてどう,,, ,,,ふるまうべきかといったことがアプローチの中に含まれるでしょう。,,, ,,,,,, ,,◆,専門職としての地位-認定されたソフトウェアテスト担当者は、公共の利益に寄与することで、専門職としての,,, ,,,地位向上に努めなければならない,,, ,,,,,, ,,,　ISTQBの試験に合格し、資格を認証された一人一人が専門家として看板を背負っています。一人一人が公,,, ,,,人として公共の利益に寄与することが、専門家としての地位向上につながります。自身がかかわるソフトウェ,,, ,,,ア開発において、ソフトウェアの品質が適正になるよう誠意をつくすことが公共の利益につながります。,,, ,,,,,, ,,◆,同僚-認定されたソフトウェア担当者は、同僚に対し公正かつ協力的でなければならず、ソフトウェア開発者と,,, ,,,協調しなければならない,,, ,,,,,, ,,,　同僚やソフトウェア開発者などの仲間たちとの協調は非常に重要です。ソフトウェアの品質を良くしていくの,,, ,,,は一人の力ではなくプロジェクト全員の協調の結果だからです。たとえばインシデントレポートの書き方一つ,,, ,,,をとっても、協調的であれば、より読みやすく、開発者が現象を理解しやすいように記述することにつながりま,,, ,,,す。,,, ,,,,,, ,,,　複数のテストレベルでテスト内容の無駄な重複を減らし、効率的にテストを進めるには、各テストレベルでの,,, ,,,テスト内容が相互に理解できるようにフォーマットや記載粒度をルール化したり、テスト状況がリアルタイムに,,, ,,,相互確認できるようなリポジトリを導入したりといった可視化に向けた努力が必要ですが、これらも、協調的で,,, ,,,あるからこそできることになります。,,, ,,,,,, ,,◆,自身-認定されたソフトウェアテスト担当者は、生涯その専門性を磨くための学習を続けるとともに、実践の場,,, ,,,でも倫理的なアプローチを広めなければならない,,, ,,,,,, ,,,　ソフトウェアテストの技術やソフトウェア関連の技術は時代とともに変化し、増え続けています。ソフトウェアテ,,, ,,,ストの専門家として、その技術を学び、自分たちの技術として身に付けて実践していかなければなりません。,,, ,,,技術はその活用のための倫理的な視点も重要になります。,,, ,,,,,, ,,,　技術は、倫理的な視点がないと、本来の目的と異なったことを効率化するためにも使えてしまうからです。テ,,, ,,,スト技術者とは、生涯をかけて学習し、倫理観を持って実践していくことが必要な職業ともいえるでしょう。,,, ★★第1章_問 １．１　練習問題,,,,, ,,,,, ,■問題１,,,, ,,,,, ,,ソフトウェアが意図したとおりに正しく動作しないことにより起こる問題の一つとして経済的な損失がある。経済的,,, ,,な損失と考えられるものとして正しいものはどれか。,,, ,,,,, ,,→,ソフトウェアサポートにかかるコスト,, ,,,,, ,,・,サポート業務の中でも、特にクレーム受付や製品回収にかかるコストは、ソフトウェアが意図したとおりに正し,, ,,,く動作しないことにより生じる経済的な損失にあたります。ソフトウェア設計、ソフトウェアテスト設計は開発コス,, ,,,トです。構成管理は開発コストであり、保守にかかるコストでもあります。これらのコストは、ソフトウェアが正し,, ,,,く動作するしないに関わらず発生するため、経済的な損失ではありません。,, ,,,,, ,■問題２,,,, ,,,,, ,,ソフトウェア欠陥を引き起こす原因として考えられるものはどれか。,,, ,,,,, ,,→,納期のプレッシャー,, ,,,,, ,,・,本問題は欠陥の原因であるエラー（誤り）の具体例に対するものです。具体例としては、納期のプレッシャー、,, ,,,コードの複雑さ、内部構造の複雑さ、技術の変更、他システムとの通信ミスが考えられます。,, ,,,,, ,,,・,正しい結果が８であるときに、システムが１２という計算結果を返す, ,,,,→,故障 ,,,・,テスト環境の設定ミス, ,,,,→,インシデント ,,,・,正しくないデータ定義, ,,,,→,欠陥 ,,,,, ,■問題３,,,, ,,,,, ,,テストと品質の関係において正しいもの。,,, ,,,,, ,,→,テストで欠陥が見つかった場合、その欠陥を修正すればシステムの品質を確保できる。,, ,,→,テストで品質を計測できる。,, ,,→,他プロジェクトの欠陥の根本原因を理解することでプロセスを改善できる。,, ,,,,, ,,・,テストと品質の関係としては、「品質確保につながる」こと、「品質の計測ができる」こと、「プロセス改善に結び,, ,,,付けることができる」ことの３つが挙げられます。,, ,,,欠陥数を予測できるようになると工数見積もりの精度を向上させることにつながりますが、欠陥を多く見つける,, ,,,だけでは、工数見積もりの精度には何も影響を与えません。,, ,,,,, ,■問題４,,,, ,,,,, ,,ソフトウェアの開発、保守、運用におけるテストの役割として間違っているものはどれか。,,, ,,,,, ,,,→,ソフトウェア性能をチューニングする。, ,,,,, ,,・,ソフトウェア性能を計測し、期待と一致しない場合にインシデントとして報告するのはテストの役割ですが、性,, ,,,能をチューニングし、期待する性能に近づけるのは開発の役割です。以下は全てテストの役割です。,, ,,,,, ,,,・,品質を上げるために故障を発見する。, ,,,・,実行環境で問題が発生するリスクを減らす。, ,,,・,各業界の標準に合致していることを証明する。, ,,,,, ,■問題５,,,, ,,,,, ,,「フォールト」の説明として正しいものはどれか。次の選択肢から１つ選びなさい。,,, ,,,,, ,,,→,要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の, ,,,,不備, ,,,,, ,,,・,欠陥のあるプログラムを実行したときに、実行すべきこと（あるいは実行してはならないこと）を正しく実行で, ,,,,きないこと, ,,,,→故障, ,,,・,間違った結果を生み出す人間の行為, ,,,,→エラー, ,,,・,ソフトウェアシステムを実際に使うユーザやテスト担当者が期待する動きと、実際の動きが一致しない事象, ,,,,→インシデント, ,,,,, ,■問題６,,,, ,,,,, ,,テストの十分性を決めるために考慮すべきリスクはどのようなものがあるか。下記の選択肢の中から最も適切な,,, ,,組み合わせを１つ選びなさい。,,, ,,,,, ,,,・,リリース後に技術の課題が残ってしまうリスク, ,,,・,リリース後に安全性に問題が残るリスク, ,,,・,リリース後にソフトウェアを使っていてビジネスに支障が出てしまうリスク, ,,,,, ,■問題７,,,, ,,,,, ,,テストは品質保証活動の一部であるため、プロジェクト終了後に今回のプロジェクトで修正した欠陥の根本原因,,, ,,分析を行うことにした。根本原因分析の結果の利用方法としてふさわしいものはどれか。次の選択肢の中から１,,, ,,つ選びなさい。,,, ,,,,, ,,,→,今後始まる他の開発プロジェクトへ情報をインプットし、同じ原因の欠陥の作り込みを予防する。, ,,,,, ,■問題８,,,, ,,,,, ,,故障が発生する原因にはどのようなものがあるか。下記の選択肢の中から最も適切な組み合わせを１つ選びな,,, ,,さい。,,, ,,,,, ,,,・,要件定義書の欠陥, ,,,・,ソフトウェアの欠陥, ,,,・,磁気、電界などによるファームウェアの誤動作, ,,,・,ハードウェアの構成変更, ,,,・,システム間のインターフェースの欠陥, ,,,,, １．２　練習問題,,,,, ,,,,, ,■問題１,,,, ,,,,, ,,テストの活動についての説明として間違っているものは次のうちどれか,,, ,,,,, ,,,→,デバッグ, ,,,,, ,,,　テストの活動は、テストの実行前後に存在する作業（計画、テストケースの設計と実行、テストプロセスやテ,, ,,,スト対象システムに関する報告など）を含みます。,, ,,,　デバッグは開発作業であり、テストではありません。,, ,,,,, ,■問題２,,,, ,,,,, ,,テストの種類と目的の組み合わせで間違っているのは次のうちどれか。,,, ,,,,, ,,,→,受入テストは、テストで発見された欠陥が正しく修正されたかを確認することを主目的としている。, ,,,,, ,,,,・,受入テストの主な目的は、システムが期待通りに動作し、要件に合致することを確認することです。 ,,,,,欠陥の修正は主目的とされていません。 ,,,,, ,,,,・,開発でのテストは、なるべく多くの故障をたたき出し、ソフトウェアの欠陥を特定して修正することを主目 ,,,,,的としている。 ,,,,・,保守テストは、ソフトウェアの変更時に、新たに欠陥が混入していないかチェックするテストも実施するこ ,,,,,とが多い。 ,,,,・,運用テストは、信頼性や可用性などのシステム特性を確認することを主目的としている。 ,,,,, ,■問題３,,,, ,,,,, ,,次の（）に入る語句の組み合わせとして正しいものは次のうちどれか。,,, ,,,,, ,,,テストには以下のような目的がある。,, ,,,,, ,,,,・,（欠陥）を摘出する。 ,,,,・,対象ソフトウェアの品質レベルが十分であることを確認する。 ,,,,・,意志決定のための情報を示す。 ,,,,・,（欠陥）の作り込みを防ぐ。 ,,,,, ,,,・,人間のエラーによって、ソースコードに組み込まれるのが欠陥です。欠陥が実行されると、故障が起きます, ,,,,。テストは、欠陥の摘出および作り込みを防ぐことを目的としています。, ,,,,, ■１．３　練習問題,,,,, ,,,,, ,■問題１,,,, ,,,,, ,,テストの７原則として間違っているものは次のうちどれか。１つ選びなさい。,,, ,,,,, ,,,→,ソフトウェアの欠陥はシステムのすべてのモジュールに均等に存在する。, ,,,,, ,,,・,ソフトウェアの欠陥は一般的に偏在することが知られている。, ,,,,, ,■問題２,,,, ,,,,, ,,テストの７原則として、正しいものは次のうちどれか。１つ選びなさい。,,, ,,,,, ,,,→,テストは開発の初期から開始する。, ,,,,, ,,,・,ソフトウェアの欠陥の検出は、ソフトウェア開発ライフサイクルの初期であればあるほど、影響範囲が少なく, ,,,,、修正も容易である。, ,,,・,同じテストを繰り返しているだけでは、そのテストで見つけられるもの以外の欠陥を見つけ出すことが出来, ,,,,なくなる。, ,,,・,ソフトウェアに欠陥があることを示すのがテストである。, ,,,・,テストはソフトウェアの使われる条件、要求事項などによって変えていくべきである。, ,,,,, ,■問題３,,,, ,,,,, ,,テストを行うにあたり、以下の活動を計画した。テストの７原則にあてはまらないものは次のうちどれか。１つ選び,,, ,,なさい。,,, ,,,,, ,,,→,分岐網羅カバレッジを１００％実施し、対象ソフトウェアに欠陥がないことを報告した。, ,,,,, ,,,・,ソフトウェアはコードのテストをすべて行い、論理的な欠陥をなくしたとしても使用性、機能性、性能などさま, ,,,,ざまな観点に欠陥は存在します。完全な動作を行えたとしても、たとえば肝心な機能が１つ実現できていな, ,,,,かったとしたら、または、１つの操作に耐えられないほどの時間がかかるとしたら、使ってもらうことはできな, ,,,,い。, ,,,・,以下はテストの7原則にあてはまる。, ,,,,, ,,,,・,テスト実施率70％を超えたところでバグの傾向分析を行い欠陥の多いモジュールを特定し、テスト計画 ,,,,,を変更した。 ,,,,・,テスト計画を行う際にユーザにヒアリングを行い、対象ソフトウェアに求められる品質特性を決定し、そ ,,,,,れに従ったテスト項目を作成した。 ,,,,・,回帰テストは複数セット用意し、毎回テスト内容を変更している。 ,,,,, ■１．４　練習問題,,,,, ,,,,, ,■問題１,,,, ,,,,, ,,テストプロセスの主要な作業として不適切なものを次の選択肢から１つ選びなさい。,,, ,,,,, ,,,→,リソースの割り当て, ,,,,, ,,,・,テストプロセス理解のポイントは、アクティビティとタスクの関係を理解しておくことです。リソースの割り, ,,,,当てはテスト計画策定におけるタスクの一つです。, ,,,,, ,■問題２,,,, ,,,,, ,,システムテストにおいてテストの終了基準として不適切なものを次の選択肢から１つ選びなさい。,,, ,,,,, ,,,→,組織で決めたステートメントカバレッジを満たしていること, ,,,,, ,,,・,ステートメントカバレッジは、ホワイトボックステストにおいて、コードカバレッジを見るためには有効ですが、, ,,,,ブラックボックステストが主眼となるシステムテストではふさわしい基準とは言えません。, ,,,,, ,■問題３,,,, ,,,,, ,,「テストの実装と実行」の活動における作業として、適切なものを次の選択肢から１つ選びなさい。,,, ,,,,, ,,,→,テストケースを決定し、実装し、優先順位を付ける。, ,,,,, ■１．５　練習問題,,,,, ,,,,, ,■問題１,,,, ,,,,, ,,低レベルから高レベルまでの独立性の度合いに関して、正しいものは次のうちどれか。,,, ,,,,, ,,,→,外部団体が認証するために実施するテストが、最も独立性が高い。, ,,,,, ,,,・,独立性のレベルが低いほど、ソフトウェアの内部を熟知しているため、コードに含まれる欠陥を発見しやす, ,,,,くなりますが、先入観やテスト以外の要因の影響を受けやすくなります。独立性のレベルが高いほど、重要, ,,,,度の高い故障を発見しやすくなりますが、テストの専門的な知識や視点を備えている必要があります。, ,,,,, ,■問題２,,,, ,,,,, ,,テスト担当者と開発担当者とのコミュニケーションを改善する方法で、正しいものは次のうちどれか。,,, ,,,,, ,,,→,常に中立を意識して、事実を報告する。, ,,,,, ,,,・,故障の報告は、プログラムを作成した開発担当者への非難や中傷ではありません。テスト担当者と開発, ,,,,担当者が同じ高品質なシステムのゴールを迎えるためのチームであることを再認識します。つまり、事実を, ,,,,正確に具体的に報告することで、故障の報告者は常に中立の立場を維持します。, ,,,,, ,■問題３,,,, ,,,,, ,,テスト担当者やリーダは、建設的に作業が進むよう優れたコミュニケーションスキルが求められる。開発担当者と,,, ,,建設的に作業を進めるための情報で、適切でないものは次のどれか。,,, ,,,,, ,,,→,開発者のスキルの情報, ,,,,, ,,,・,テストで故障を見つけ報告することは、開発者への非難と受け取られることがあります。しかし、リリース後, ,,,,に欠陥が発見されるよりテストで見つけて修正する方が、時間とコストの節約になります。また、リスクの低, ,,,,減や、ソフトウェアやドキュメントの作成者のスキルを向上させることにつながります。建設的に作業が進む, ,,,,ようにテスト担当者やテストリーダは、常に中立的な立場で、かつ客観的な事実に基づいて良好なコミュニ, ,,,,ケーションを取る努力をします。, ★★第１章_用語 第１章_理解しておきたい重要用語の定義,,,, ,,,, ,■１．１　テストの必要性,,, ,,,, ,,用語,英語,説明 ,,バグ,bug,→欠陥（defect）参照 ,,欠陥,defect,要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備。たとえば、不正な命令又はデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。 ,,エラー,error,間違った結果を生み出す人間の行為。 ,,故障,failure,コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと。 ,,フォールト,fault,→欠陥（defect）参照 ,,誤り,mistake,→エラー参照 ,,品質,quality,コンポーネント、システム、プロセスが、指定された要求、ユーザ、顧客のニーズ、期待を満たす度合い。 ,,リスク,risk,将来、否定的な結果を生む要素。通常、影響度と発生可能性として表現する。 ,,,, ,■１．２　テストとは何か,,, ,,,, ,,用語,英語,説明 ,,デバッグ,debugging,ソフトウェアの故障の原因を見つけて、分析して、取り除くプロセス。 ,,要件,requirement,ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満たすために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。 ,,レビュー,review,製品やプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。 ,,テストケース,test case,入力値、実行事前条件、期待結果、そして、実行事後条件の組み合わせで、特定のプログラムパスを用いることや指定された要件の遵守を検証することのような、特定の目的またはテスト条件のために開発されたもの。 ,,テスト,test case,一つ以上のテストケースの組み合わせ。 ,,テストの目的,test objective,テストを設計、実行する理由や目的。 ,,,, ,■１．３　テストの７原則,,, ,,,, ,,用語,英語,説明 ,,全数テスト,exhaustive testing,テストアプローチの１つ。テストスイートにより、入力値と事前条件の全組合せをテストすること。 ,,,, ,■１．４　基本的なテストプロセス,,, ,,,, ,,用語,英語,説明 ,,確認テスト,confirmation testing,→再テスト参照 ,,再テスト,re-testing,修正を行った結果が正しいことを証明するために、前回不合格に終わったテストケースを再実行するテスト。 ,,終了基準,exit criteria,あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件。終了条件の目的は、未完了部分のあるタスクが、完了と見なされるのを防ぐことにある。終了基準は、テスト完了の報告や、計画で利用する。 ,,インシデント,incident,発生した事象の中で、調査が必要なもの。 ,,回帰テスト,regression testing,変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、既にテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わるたびに実施する。 ,,テストベース,test basis,コンポーネント要件やシステム要件を推測できるすべてのドキュメント。これらのドキュメントがテストケースのベースとなる。公式な改訂手順を経ないとドキュメントの改訂ができない場合、そのテストベースを「凍結テストベース」と呼ぶ。 ,,テスト条件,test condition,コンポーネントやシステムのアイテムやイベントで、テストケースにより検証できるもの。たとえば、機能、トランザクション、品質特性、構造要素など。 ,,カバレッジ,coverage,指定の網羅条件をテストスイートが実行した度合い。パーセンテージで表す。 ,,テストカバレッジ,test coverage,→カバレッジ参照 ,,テストデータ,test data,テスト実行前に実在する（例えば、データベースの中）データであり、テスト対象のコンポーネントやシステムに影響を与えたり、影響を受けたりするもの。 ,,テスト実行,test execution,テスト対象のコンポーネントやシステムでテストを実行し、実際の結果を出力するプロセス。 ,,テスト結果記録,test log,テスト実行の詳細を時系列的に記録したもの。 ,,テスト計画,test plan,計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、使われるテスト設計技法と開始・終了基準、それらの選択の論理的根拠、それに代替計画を必要とするあらゆるリスクを特定する。これはテスト計画プロセスの記録である。 ,,テスト手順仕様,test procedure specification,テストの実行のために、一連の手順を指定するドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。 ,,テストポリシー,test policy,組織にとってのテストにかかわる原理原則、アプローチ、主要な目的を記述するハイレベルのドキュメント。 ,,テストスイート,test suite,テスト対象のコンポーネントまたはシステムのためにテストケースをまとめたもの。ひとつのテストの事後条件は、次のテストの事前条件として利用される。 ,,テストサマリレポート,test summary report,テスト作業と結果を要約した報告用ドキュメント。実行したテストケースがテスト終了基準を満足しているかの評価も含む。 ,,,, ,■１．５　テストの心理学,,, ,,,, ,,用語,英語,説明 ,,エラー推測,error guessing,テスト設計技法の１つ。テスト担当者の経験を駆使し、エラーが起きた場合にどんな欠陥が被試験のコンポーネントやシステムの中に存在するかを予測して、その欠陥を検出するテストケースを設計すること。 ,,独立性,independence of testing,責任を分離すること。これにより、客観的なテストを促進できる。