部品構造
- 大部品: ソフトウェア開発工程 RD:23 評価値:7
- 大部品: 上流工程（ソフトウェア開発） RD:10 評価値:5
- 大部品: RFP・要件定義 RD:9 評価値:5
- 部品: RFP・提案書
- 部品: 要求仕様書・要件定義書
- 部品: ドメイン知識
- 部品: システム導入の目的
- 部品: 制約条件
- 部品: 機能要件・非機能要件
- 大部品: 変更管理 RD:3 評価値:3
- 部品: 変更管理とは
- 部品: 要件管理ツール
- 部品: 仕様変更率
- 大部品: 外部設計・内部設計 RD:1 評価値:1
- 大部品: 下流工程（ソフトウェア開発） RD:13 評価値:6
- 大部品: コーディング（ソフトウェア開発） RD:1 評価値:1
- 大部品: ソフトウェア・テスト RD:12 評価値:6
- 部品: ソフトウェア・テストとは
- 部品: テストの分類
- 部品: テスト計画書
- 部品: レビュー
- 部品: 非機能テスト
- 部品: ホワイトボックステスト
- 部品: ブラックボックステスト
- 部品: 探索的テスト
- 部品: 単体テスト・結合テスト
- 大部品: メタテスト RD:3 評価値:3
- 部品: メタテストとは
- 部品: ドッグフードテスト
- 部品: 獲得時間
部品定義
部品: RFP・提案書
RFPとは、Request For Proposalの略で、提案依頼書のこと。
提案依頼書とは、情報システムの導入・構築や業務委託をおこなうにあたり、開発を依頼する発注元(発注者)が具体的な提案を依頼するために、発注先候補の事業者に交付する文書のことである。
業種・業態・組織・提供する製品やサービスといった発注元の基本情報、なぜシステムやサービスを導入するのかといった導入の背景、システム開発やサービス導入にどのような便益を期待しているかといった目的、どのような部門のどのような業務の者がだいたい何名ぐらい使用するのか、各機能やサービスはそれぞれいつまでにどのようなスケジュール・どれくらいの予算で完成させたいかといった調達条件などといったことがRFPに書かれている。
RFPの目的は、提案内容と見積もりから最も適した発注先(受注者)を選ぶことである。
RFPは、発注元が発注先の事情や技術上の制約を気にせずに自身の要望を書いているため、開発を請け負う側はRFPから本当に欲しいものはなんなのかを見抜くことが重要である。
／＊／
システム提案書とは、RFPに対する回答として、発注先から発注元に提出される資料のこと。
RFPに対する回答は、特に訂正・削除がない場合、そのまま要件として扱われる場合もある。
そのため、RFPに記載された、発注元の誤った認識による不適切な実現方法に対し、発注先は妥当な代替手段を検討する必要がある。
そのうえで、どこまでの範囲の業務を開発するシステムで対応するか、発注元と発注先で開発の役割や責任をどのように分担するか、開発に関する報告や会議の頻度・スケジュール、利用者にシステムの使い方を教育する必要があるかなどといったことを発注先は記載する。
発注元の責任で仕事が遅れたり、仕様が変更になったりした場合、開発方法やスケジュールの変更を提案・相談できるよう、発注先はシステム提案書に注意書きをしておいたほうがよい。
システム提案書は単に提案書とも呼ばれる。
部品: 要求仕様書・要件定義書
要求仕様書とは、発注元(発注者)が何をしたいのかという希望を、システム開発として実現して欲しい機能に落とし込んで書いたものである。
RFPとは異なり、要求仕様書には調達条件は書かれていない。
／＊／
要件定義書は、要求仕様書に書かれた要望を実現するためにはどのようなシステムが必要か、機能要件・非機能要件などを発注先(受注者)が書いたものである。
ここでいう要件とは、必要な条件のことである。
要件定義書は、オペレーティングシステムやミドルウェアの選定を含まれ、提案書よりも具体的である。
要件は、そのシステムを作る背景や機能など、その時点でできる限り定量的に記述することが望ましい。
ただし、根拠のない数値は危険なため、書くべきでない。
また、要件は、その機能の及ぶ範囲が把握できるよう、適切に表現することが望ましい。
たとえば、「計測データが正常でなければ知らせる」と「計測データを表示中、重要な変化があった場合、画面に警告を表示する」のふたつの表現では、書き手が同じことを考えて書いたとしても、読み手の印象は大きく異なる。
同様に「印刷できない状況になった場合、担当者に知らせる」と「印刷途中で用紙やインクが不足するとわかった時点で、登録されている担当者に電子メールで知らせる」のふたつの表現でも、前者より後者のほうが、その機能がどのように動作してほしいか、その機能の及ぶ範囲がどこまでかが分かりやすい。
要件が複雑であったり、範囲が広い場合、ふたつの階層に分けて表現する。
たとえば、一階層目を「印刷途中で用紙やインクが不足するとわかった時点で、登録されている担当者に電子メールで知らせる」と簡潔に表現して要件の範囲を把握する。
そして、二階層目を「印刷中に用紙とインクの残量の情報を得る」「用紙の使用予定量と残量を比較し、用紙が不足しないか確かめる」「インクの使用予定量と残量を比較し、インクが不足しないか確かめる」「定型文からメール本文を作成する」「データベースから担当者のメールアドレスを得る」「電子メールを送信する」などとすれば、どのような機能を実装しなければならないかが具体的に分かるようになる。
ひとつの要件を階層化する際、三階層以上にしなければ分かりにくい場合、要件そのものの範囲が広すぎるため、ふたつ以上の要件に分割したほうがよい。
要件定義書に記載がない場合、しないことなのか、するかどうか決まっていないことなのか、あいまいとなるため、しないと決めたことについても明記するべきである。
要件を不採用にすることが妥当か確認できるようにするため、不採用にした根拠や理由も明記したほうがよい。
要件定義書の内容と直接関係ないが、文章の読みやすさも品質のひとつであるため、使用する文体や表記、用字・用語は統一したほうが良い。
また、表現にも気をつけたほうがよい。
たとえば「処理を1秒以内に終えるべき」という表現だと「処理を1秒以内に終えること」が要件なのか、努力目標なのか解釈が分かれ、問題になる恐れがある。
上記のように、要件定義書の内容で考慮すべき点は多岐にわたるため、要件の抜け・漏れなどの不備がないよう、確認・検証が必要である。
概算の相見積もりの際、発注元は当初予定していたが要求が過不足なく満たされているか、要求仕様書と要件定義書を見比べ、吟味することが重要である。
必要以上に高度な機能で無駄な費用が要求されていたり、必要な機能が盛り込まれていなかったりした場合、発注元は発注先に要件定義書の記載内容を改めるよう求めることが望ましい。
なお、相見積もりとは、複数の事業者から見積書を提出してもらい、品質・価格・納期などを比較・検討することである。
／＊／
余談だが、要求と要件は英語ではどちらもrequirementと表記する。
要求と要件を混同する場合は「顧客の」「システムの」を前につけるとよい。
「顧客の要求」という表現はあるが、「システムの要求」という表現は適切ではない。
同様に「システムの要件」という表現はあるが、「顧客の要件」という表現は適切ではない。
なお、ソフトウェア開発における要求・要件であることを明確にするため、ソフトウェア要求(software requirements)、ソフトウェア要件と表記する場合もある。
部品: ドメイン知識
ドメイン(domain)とは、分野や領域を指す。
ドメイン知識(domain knowledge)とは、ある分野の専門家がもつその分野固有の知識である。
ドメイン知識を得る方法には、その分野・領域の実務者やアナリストに尋ねたり、実際に対象の業務に参加するなどがある。
ドメイン知識はシステムやソフトウェアの開発において重要である。
たとえば、流通を管理するソフトウェアを作成する場合、流通の専門知識が必要になる。
また、カーナビゲーションシステムを開発する場合、GPS(Global Positioning System)やGIS(Geographic Information System)、およびそれらに関連する規格・方式などの知識が必要になる。
素粒子分野と核物理分野で、核子のアイソスピンの定義が符号が逆になっているように、業界や業種によって同じ内容を異なる表現を用いている場合もある。
そのため、要件定義書を作成する際、発注元と発注先の間で要件の理解に齟齬がないよう、用語の意味を定義した辞書を作成することが望ましい。
また、システムやソフトウェアの開発で用語を使用する際、その用語の定義や表現が適切か、その妥当性を検証することも重要である。
ドメイン知識は、領域知識や領域固有知識とも呼ばれる。
部品: システム導入の目的
システム導入の目的とは、発注元がRFPや要求仕様書に記載する内容のひとつである。
たとえば、「生産性向上」「コスト削減」「顧客満足度向上」など、組織の経営に役立つか、利用者の便益に寄与するものがシステム導入の目的として挙げられる。
どの要件から実装するかは、システム導入の目的から実装の優先順位を考える。
また、開発中に要件が変更・追加される場合は、システム導入の目的を軸に妥当性を考える。
システム導入の目的にその要件変更・要件追加が必要か、すでにある要件で充分目的を達成できるかを考え、変更・追加が妥当でない場合、発注先はその要件の変更・追加を受け入れないほうが望ましい。
妥当でない要件を受け入れた結果、開発の進捗が順調でなくなったり、開発されたシステムやサービスが不調となったりした場合、その非は受け入れた発注先にある。
部品: 制約条件
制約条件とは、システムを開発する際、考慮しなければならない前提や制約のことである。
たとえば、「システムの操作担当者はカマキリのため、人知類用の入力機器が使用できない」「来年に税制が改正されるので、それまでにシステムが運用できるようにしてほしい」などである。
要件定義書を作成する際、発注先はどのような制約条件があるか網羅するよう、システムを使用する藩国の憲法や法令・規則・条例、利用者の操作技術・業務時間・使用環境など、様々な観点から発注元に聞き出す必要がある。
部品: 機能要件・非機能要件
機能要件(functional requirement)とは、システムが持たなければならない機能を定義したものである。
システムに何ができるのか・何ができないのかをできる限り、正確に網羅する必要がある。
具体的には「各機能ごとにどのような入出力があり、どのような処理がなされるか」「誰がいつどこでこの機能を利用し、どのような結果が得られるか」「なぜこの機能が必要か」などが機能要件として挙げられる。
それぞれの要件間で整合性がとれているか、他の資料と内容に矛盾はないか、読み手によって解釈が異なるようなあいまいな表現はないかなど、充分に注意しなければならない。
／＊／
非機能要件(non-functional requirement)とは、使いやすさやセキュリティなど、システムが持たなければならない性質を定義したものである。
非機能要件を多面的に検討するためには、そのシステムに関連する者は誰かを考えるとよい。
たとえば、システムを操作・運用する者、保守作業をする者、システムを改修・機能追加する者、システムに不正にアクセスしデータを盗む者などである。
それらの者がそれぞれどの程度の技術があり、いつどのような操作をするか、システムに問題が発生した場合、どのような行動をするかなどを考え、そこから求められる非機能を明確にする。
非機能要件は機能要件よりも検討すべき範囲が広いため、様々な立場のなるべく多くの者と話し合って、できるだけ多く洗い出すことが望ましい。
／＊／
性能要件(performance requirement)とは非機能要件のひとつで、システムが持つべき処理速度や取り扱えるデータ容量、センサーの精度など、性能に関することである。
性能要件は「業務に支障のない範囲」「既存システムと同等」といったあいまいな表現ではなく、「操作完了後、一秒以内に次の画面に移動する」「二十三時に処理を開始し、翌日の七時半までに処理を終了する」など、具体的な数値で表すことが望ましい。
発注元が用意した機械でも「処理速度はどの程度か」「取り扱えるデータ容量はどのくらいか」といった点を、発注先は確認しておき、必要に応じて機械の買い替えを提案することが望ましい。
性能面で実際に動作してみないとわからない点については、「システムにアクセスする者が一名の場合」といった前提条件をつけて性能要件を表現する。
その性能が充分でない場合、業務に重大な影響を与える危険性が高く、机上の計算では不安なものについては、妥当な実現方法を検討するため、類似環境やテストデータを用意し、実験で確認する必要がある。
／＊／
セキュリティ要件(security requirement)とは非機能要件のひとつで、システムの機密性に関するものである。
たとえば「データをどのような暗号形式で保存するのか」「不正なアクセスを防ぐためにどのような認証方式を採用するのか」「障害が発生した場合、速やかに復旧するためにどのような対策を講じるのか」などが挙げられる。
発注先は発注元よりもセキュリティの知見を有するため、発注元から要望がなくても発注先は積極的にセキュリティについて調査し、その見積もりを提出するほうが望ましい。
そこまでしたうえで、発注元がセキュリティ対策は不要だと判断した場合、セキュリティ上の問題が発生した際の非は発注元にある。
部品: 変更管理とは
要件定義において変更管理とは、いったん確定した要件・仕様・設計に対して発生した変更の管理である。
変更管理は窓口を一本化し、変更管理担当者が一元的に管理することが望ましい。
変更を要求する場合、業務上および技術上、その変更をおこなうべき妥当な根拠があるか確認したうえで、変更管理担当者に報告する。
変更管理担当者は、その変更で影響を受ける開発担当者に調査を依頼する。
変更は必要か、実現できるか、実現する場合どのような方法か、変更による作業やスケジュールへの影響はどの程度か、変更にどの程度の時間・費用が必要か、誰がその変更を実施するのか、優先順位はどの程度かなどを調査したうえで、計画に基づいて変更を実施する。
実施した変更は、進捗・状況を定期的に確認し、必要に応じて是正する。
発注先は変更管理の工数もプロジェクト管理費用に含め、発注元に認めてもらうことが重要である。
部品: 要件管理ツール
要件管理ツール(requirements management tool)、または要求管理ツールとは、要件や要求を管理するためのツールの総称である。
要件・要求の管理とは、顧客や利用者からシステムに対する要望を引き出すこと、要件・要求を文書化し体系づけて整理すること、期間内・予算内に開発を終えるため発注元(発注者)と発注先(受注者)の間で要件・要求の範囲について合意を形成することなどである。
一般に要件管理ツールは、システムやソフトウェアの開発チームが一元的に要件・要求を登録・編集・参照できる機能を有する。
そのため、要件管理ツールを用いることで、最新の要件を開発チームのメンバー全員が知ることができる。
また、要件のトレーサビリティを管理するため、要件管理ツールはトレーサビリティ・マトリクスを登録・編集・参照できる機能を有する。
要件管理ツールを正しく使いこなすためには、どのように要件や要求を管理しているかが重要となってくる。
／＊／
ソフトウェア開発において、トレーサビリティ(traceability)とは、仕様書やプログラムなど、各工程や各作業で作られた成果物がどの成果物に影響を与えているか、追跡できることを指す。
たとえば「要件定義書のA010の要件を変更した場合、整合性を保つため、外部設計書BのB010と外部設計書CのC030も変更する必要がある」「外部設計書BのB010を変更した場合、内部設計書DのD050と結合テスト仕様書XのX320も変更する必要がある」「内部設計書DのD050を変更すると、プログラムEのE120と単体テスト計画書YのY090を修正する必要がある」などである。
上記の例に出てくるA010やB010などは、追跡を容易にするため、要件や仕様に割り当てられた固有の番号である。
ソースコード上にコメントとして上記の番号を記載することで、要件や仕様が変更になった際、プログラムの修正が容易になる。
トレーサビリティを管理することで、インパクト分析やカバレッジ分析をおこなえるようになる。
トレーサビリティは、追跡可能性とも呼ばれる。
／＊／
トレーサビリティ・マトリクス(traceability matrix)とは、それぞれの成果物の間の追跡可能性を確保するために考え出された表である。
たとえば要件と外部設計のトレーサビリティ・マトリクスなら、縦に要件、横に外部設計の固有の番号がそれぞれ記述される。
A010の要件を変更した際、整合性を保つため、B010の外部設計が変更しなければならない場合、A010の要件の行と、B010の外部設計の列の、交点の升目に印をする。
このように、印をした升目から要件の行と外部設計の列を確認することで、一方を変更した際、他方の修正の必要な箇所がすぐに分かる。
トレーサビリティ・マトリクスは、一般的な表計算ソフト(spreadsheet)でも作成できるが、作成と保守に必要な労力が大きい。
そのため、規模の大きいプロジェクトでは、要件管理ツールのような専門のソフトウェアを用いることが多い。
トレーサビリティ・マトリクスは、追跡可能マトリクスとも呼ばれる。
／＊／
要件や要求の管理において、インパクト分析(impact analysis)とは、要件や仕様を変更した際、仕様書やプログラムに与える影響を評価することである。
影響の大きさを知ることで、要件の変更や追加を受け入れるか否かを決める際の判断材料になる。
インパクト分析は、変更波及解析(change impact analysis)、影響波及解析とも呼ばれる。
／＊／
要件や要求の管理において、カバレッジ分析(coverage analysis)とは、不要・余分な仕様がないか、あるいは足りない仕様がないかを評価することである。
不要・余分な仕様とは、要件定義書に対応する要件がない仕様である。
また、足りない仕様とは、要件定義書に記載されている要件に対応する仕様がないことである。
仕様の過不足を知ることで、不要な機能を作ったり、必要な機能が足りなかったりすることを防ぐことができる。
部品: 仕様変更率
ソフトウェア開発において、仕様変更率とは、変更された仕様の件数をすべての仕様の件数で割った割合である。
仕様変更率は、要件定義書や仕様書の出来栄えを判断する指標となる。
仕様変更率が高い場合、要件定義書や仕様書の様式や内容にあいまいなところがあると考えられる。
たとえば、入力値の検証に関する仕様変更があったとき、そもそも入力値の検証を想定せずに仕様書を作成していた場合、その仕様変更をプログラムのどの箇所でおこなうのが妥当なのかというところから検討しなければならなくなる。
適切な仕様書がある場合、どこで仕様変更に対応するかがおのずと決まるため、仕様変更の影響範囲を小さく抑えることができる。
仕様変更率が高いプロジェクトと低いプロジェクトを比較すると、どこに改善の余地があるかがわかりやすい。
たとえば、仕様変更率が高いプロジェクトは顧客にいわれた仕様変更をそのまま受け入れているのに対し、仕様変更率が低いプロジェクトはその仕様変更がどのような要求から出てきたのかを確認していることが多い。
具体的に例を挙げると、「監視カメラの首振り角度を30度から45度に変更してほしい」と依頼があった場合、首振り角度を広げる理由を確認する。
ひとつの監視カメラが撮影する範囲を広げることで、監視カメラの設置台数を減らし、導入費用を下げることが目的なら、首振り角度の変更で死角ができないよう、カメラの首振り速度を変更するといった対応も必要になってくる。
このように、なぜその仕様変更が必要なのかを確認することで、合わせて対応が必要な箇所に気づくことができる。
また、要求によっては仕様を変更せず、既存の機能で対応できる場合もある。
部品: 外部設計・内部設計とは
ソフトウェア開発において、外部設計(external design)とは、開発するシステムが利用者や外部のシステムに対し、機能やインターフェイスをどのように提供するかを設計することである。
外部設計は、基本設計(basic design)や概要設計(outline design)と呼ばれることもある。
外部設計を文書にまとめたものを外部設計書や外部仕様書などと呼ぶ。
外部設計書に記載される内容は、要件定義に基づいて作成される。
具体的には、システムの目的や方針、機能、ユーザインタフェース、ソフトウェア構成、ハードウェア構成、ネットワーク構成、システムインタフェースなどが外部設計書に記載される。
外部設計書を作成する際、現行の業務の流れを知ることが重要である。
業務のどの部分をソフトウェアが担当するか、どの業務を変更するか、ソフトウェアの導入前後の業務の流れをそれぞれ図表で表現することで、システムの規模が明確になり、開発の日程や予算が試算できるようになる。
確定していない仕様については顧客と交渉している状態を記載する。
たとえば、画像ファイルの保存形式に「未定」と記載されていると、必要な工数や費用を見積もることができないが、「対応する画像ファイルの保存形式は下記のいずれかを予定」という仕様の下に、保存形式の候補が記載してあれば、開発に必要な日程や費用を推測できる。
候補の中で特に有力なものがあるなら、そのことも明示するとよい。
データベースの設計については、ER図やCRUD図などが記載される。
ER図(entity-relationship diagram)とは、データベースの各テーブルが互いにどのように参照しているかを表した図である。
また、CRUD図とは、どの権限を持つ利用者やシステムに対し、生成(create)・読み取り(read)・更新(update)・削除(delete)を許可するかを表した図表である。
外部設計は、顧客や利用者の目に触れる部分を決めるため、顧客の仕事の結果に直接影響することもある。
そのため、外部設計の内容については顧客の了承を得ることが望ましい。
／＊／
ソフトウェア開発において、内部設計(internal design)とは、外部設計に基づいてプログラムやシステムの内部における具体的な処理の手順や実装方法について設計することである。
内部設計は、詳細設計(detail design)と呼ばれることもある。
内部設計を文書にまとめたものを内部設計書や内部仕様書などと呼ぶ。
内部設計書に記載される内容は、要件定義と外部設計に基づいて作成される。
具体的には、入出力情報のデータ構造、変数の初期値、定数の値、例外処理・エラー処理・異常処理の定義と設計、メモリ使用量の見積もり、割り込みや多重起動の対策、排他制御のロック・アンロックのタイミングなどが内部設計書に記載される。
内部設計は、外部設計と異なり、顧客や利用者の目に触れない部分である。そのため、顧客の了承を得る必要はほとんどなく、ソフトウェア開発の担当者が理解できる内容になっていればよい。
部品: コーディングとは
ソフトウェア開発において、コーディング(coding)とは、コンピュータ言語を用いて、ソースコードを記述することである。
コーディングの対象となるコンピュータ言語には、プログラミング言語やデータ記述言語、スタイルシート言語などがあるが、プログラミング言語による記述をコーディングと呼ぶ場合が多い。
なお、文章構造を記述するための形式言語であるマークアップ言語は、データ記述言語の一種である。
プログラミング言語によるコーディングとは、課題の解決策をプログラムが実行できるよう、プログラミング言語に置き換え、ソースコードで記述することである。
コーディングをおこなう者をコーダー(coder)と呼ぶ。
プログラミング言語によるコーディングをプログラミング(programming)と呼ぶ場合もあるが、プログラミングにはプログラムの設計も含まれる。
プログラミングをする者をプログラマ(programmer)と呼ぶ。
プログラミング言語ごとに、それぞれシンタックスとセマンティクスが異なるため、コーダーがある言語のコーディングができても、別の言語のコーディングができるとは限らない。
なお、シンタックス(syntax)とは、構文や構文規則、文法とも呼ばれ、データの形式や構造、枠組みを指す。
セマンティクス(semantics)とは、データの意味や中身である。
コーディングする際は、シンタックスに応じて文字が色分けして表示するソースコードエディタ(source code editor)を用いると、ソースコードの書き間違いに気づきやすく便利である。
ソースコードエディタによっては、対応しているプログラミング言語の文法上の不備を警告で知らせる機能もある。
また、数字の0と英字大文字のOのような紛らわしい文字を判別できるよう、コーディングに適したフォントを用いると、ソースコードの書き間違いに気づきやすく便利である。
／＊／
ソフトウェア開発において、コーディング規約(coding conventions)とは、プログラミング言語やデータ記述言語などでコーディングする際のルールやガイドラインである。
複数名でコーディングをおこなう場合、コーダーによって記述方法が異なる場合、他のコーダーが記述したソースコードを読んだり直したりすることに時間がかかり、ミスも増える。
コーディング規約を遵守すると、ソースコードを読みやすくなるため、プログラムの保守性を上げ、ソフトウェアの品質向上につながる。
コーディング規約が遵守されているかは、レビューや静的解析によって確認・検証する。
コーディング規約としては、変数・定数・関数などの命名規則、オフサイドルールなど、様々な規則がある。
命名規則(naming convention)とは、どのような名前をつけるかという規則である。
オフサイドルール(off-side rule)とは、レイアウトルール(layout rule)とも呼ばれ、字下げによって文や関数のかたまりの範囲を示す規則である。
どのようなコーディングが読みやすいかは、コーダーがどのようなコーディングに慣れ親しんできたかが影響するため、明確に決めることは難しい。
そのため、コーダー同士でどのようなコーディングにすべきか論争とならないよう、妥当なコーディング規約を定めることが望ましい。
ソフトウェアを開発する組織やプログラミング言語のコミュニティですでに普及しているコーディング規約があり、不適切でない場合、そのコーディング規約を採用することが望ましい。
また、レビューやテストで見つかったソフトウェアの不備が、コーディング規約の追加・修正で防げる場合、コーディング規約を更新することが望ましい。
コーディング規約は、コーディング規則(coding rules)、コーディング基準(coding standards)とも呼ばれる。
部品: ソフトウェア・テストとは
ソフトウェアの欠陥・不良・不具合・障害などの問題によって、ソフトウェア本来の機能が制限され、そのソフトウェアに期待される機能や価値を顧客や利用者に提供できない状態を、そのソフトウェアの品質が悪いと表現する。
こうしたソフトウェアの品質を改善するため、ソフトウェアの問題を見つけ出す行為を総じて、ソフトウェア・テスト(software testing)、あるいはソフトウェアV&V(software verification and validation)と呼ぶ。
ソフトウェア・テストには、問題が起きる操作を発見するために行われるテストや、問題が再現する条件を調べるためのテスト、問題を起こしているソースコードを特定するためのテストなど、いくつかの種類に分かれている。
ソフトウェア・テストは、ソフトウェアの品質を改善するために重要なものであるが、ソフトウェアのすべての問題を発見できるわけではない。
たとえば、それぞれ0から99までの数値が入力できる二つの入力欄があり、入力した二つの数値を積を表示するという単純なプログラムの場合でも、正常系のみをすべて試すだけで100通り×100通り＝1万通りのテストが必要になる。
英字や記号などを入力した場合や未入力の場合など、異常系のテストも含めると、テストケースはより多くなる。
さらに、このソフトウェアが対応すべき動作環境が10通りの中央演算処理装置、10通りのメモリ容量、10通りのドライブ容量とすると10通り×10通り×10通り＝1000種類のハードウェア構成でテストする必要がある。
実際には、オペレーション・システムの種類やバージョン、ドライバ、様々な周辺機器の組み合わせ、同時に実行するプログラム、テストを実行する順番や入力タイミングなども影響するため、テストケースは膨大となる。
以上のように、ソフトウェア・テストですべてのテストケースを実行することは不可能であるため、ソフトウェア開発に関係する者は「テストによってすべての問題を発見することは不可能だ」と心得るべきである。
実際におこなわれるソフトウェア・テストは、妥当な費用・時間・資源で、関心のある範囲をなるべく網羅できるよう、様々な種類のテストを組み合わせて問題を発見している。
ここで「関心のある範囲」とは、たとえば、ソフトウェアを出荷するべきか、出荷するならいつが妥当か、プロジェクトを中止するか、プロジェクトを継続するなら開発要員を増やす必要があるか、ソフトウェアが担う役割の範囲を変えるか、ソフトウェアの価格を変えるかなどを判断するための情報である。
なぜ様々な種類のテストを組み合わせるのかといえば、学生の学力試験にたとえると、国語の試験だけを行い、その成績がよければ他の教科の成績もよいだろうと判断せず、なるべく出題範囲全体を網羅するような設問の各教科ごとに試験したほうが、その学生の学力を正確に知ることができるからである。
むろん、学力試験で山を張った一夜漬けの勉強がたまたま出題されて好成績になったり、カンニングをしたりして正しい学力を測定できないことがあるように、ソフトウェア・テストでも不適切なテストや虚偽のテスト結果などでソフトウェアの品質を正しく測定できない場合があるため、そのようなことがないよう、対策を講じる必要がある。
もし、テストによって収集された情報を使う予定がないのなら、費用や時間の無駄となるため、そのテストをするべきではない。
なお、ソフトウェア・テストによって発見された問題はすべて修正されるわけではなく、納期や経営戦略などから重要ではない問題をあえて修正せずにソフトウェアを出荷する場合もある。
なぜなら、問題を修正する過程で新たな問題が作られることもあり、納期が迫っていると修正ミスの頻度も多くなるため、重要ではないなら修正しないほうが妥当と考えられるからである。
どの問題が重要かは顧客や利用者の価値観による。
修正が容易か困難かは基本的に問題の重要性とは関係ない。
部品: テストの分類
ソフトウェア・テストの分類はいくつか種類がある。
開発工程によるテストの分類では、単体テストや結合テスト、総合テスト、受け入れテストなどに分類される。
また、どういった品質を検証するかという観点でテストを分類した場合、機能テスト(functional testing、functional requirement testing)と非機能テストに分けられる。
非機能テストには、性能テスト、負荷テスト、ユーザビリティテスト、セキュリティテスト、保守性テスト、信頼性テスト、移植性テストなどがある。
どのようにテストを実行するかという観点では、動的テストと静的テストに分けられる。
動的テストとは、実際にプログラムを動作させることで問題を見つけるテストである。
それに対し、静的テストとはソフトウェアを構成するソースコードを検証することで問題を見つけるテストである。
知類が要件や設計、ソースコードを目視確認するソフトウェア・レビューは、静的テストである。
また、静的コード解析(static code analysis)や静的プログラム解析(static program analysis)、静的解析などと呼ばれる、機械的にソースコードやオブジェクトコードを解析することも静的テストである。
単にソフトウェア・テストと言った場合、動的テストを指すことが多い。
テストケースを作成する技法で分類した場合、テスト対象を中が見える箱と考えるホワイトボックステストと、テスト対象を中が見えない箱と考えるブラックボックステストに分けられる。
技法による分類では、ホワイトボックステストとブラックボックステスト以外に、プログラムの仕様と内部構造の両方に着目したグレーボックステスト(gray box testing)という分類を追加する場合もある。
グレーボックステストは、ホワイトボックステストとブラックボックステストを組み合わせたテストである。
部品: テスト計画書
ソフトウェア・テストにおいてテスト計画書とは、ひとつひとつのテストに対し、どのようにテストするかを記載した仕様書である。
時間がないプロジェクトマネージャでも概要を理解できるよう、テスト計画書の最初は「なぜこのテスト計画を記載する必要があるのか」「今後はどのような方針でテストを進めていくのか」「どのような品質の製品を出したいのか」など、テスト計画の要約を記載する。
それ以外にテスト計画書に記載すべき内容は、テスト計画に関連する他の仕様書、テスト対象のソフトウェアとそのバージョン、テストするべき機能とテストする必要がない機能、テスト方法、合否の判断基準、テスト要員、スケジュール、承認、テストの終了基準などである。
／＊／
テスト計画に関連する他の仕様書を列挙することで、どのような資料を参考にして立てられた計画なのかが分かる。
／＊／
テストする必要がない機能は重要である。
なぜなら、たとえば、ある既存のライブラリをテストせずに問題が起きた場合、誰に責任があるかを明確になるからである。
そのため、テストする必要がない機能は、ソフトウェア開発プロジェクトの責任者に承認を得る必要がある。
もし、既存のライブラリもテストする場合は、そのための要員や時間・予算を確保しなければならない。
／＊／
テスト方法とは、ホワイトボックステストかブラックボックステストなど、テストの方法を記載する。
文言や動作などのどのような観点・切り口でテストするのか、具体的なテストの操作手順と期待される結果は、テスト設計仕様書と呼ばれる別の仕様書に記載する。
／＊／
テスト計画書に記載するテスト要員とは、誰がテスト計画を管理するか、誰がテストケースを作りテストを実施するか、テストで見つかった問題の原因を誰が特定するかなど、その要員計画を記載する。
テスト担当者に適切な技術がない場合は、テストの技術を身に着けるためのトレーニング計画も記載する。
遅れが出ているソフトウェア開発プロジェクトに要員を追加すると、新入りが新しい環境に慣れたり、資料にまとめられていない暗黙のルールを新入りに教育したりする必要があるため、さらに遅れることになる。
そのため、テスト担当者の要員計画はよく考える必要がある。
／＊／
テストのスケジュールは開発スケジュールに依存する。
そのため、計画を立てた後も定期的にスケジュールを見直す必要がある。
スケジュールを見直す頻度は、たとえば二週間おきなどである。
テストのスケジュールを見直す際、テスト対象のソフトウェアからあとどれぐらいの不具合が見つかりそうか推定できると、妥当性の高いスケジュールを作ることができる。
残存する不具合を推定する方法としては、二チームにテストしてもらう方法がある。
たとえば、XチームとYチームという二つのチームがあり、どちらのチームも同じテストをした場合、Xチームが見つけた不具合がa個、Xチームが見つけた不具合がb個、XとYのどちらも見つけた不具合がc個とすると、そのソフトウェアで見つけられるすべての不具合はa×b÷cと推定することができる。
あるいは、百のテストケースの中から十を試した結果、不具合が五つ見つかったら、百のテストケースで五十見つかるだろうと推定できる。
ただし、推定方法によっては、実際に見つかる不具合よりもかなり低く見積もる場合もあるため、推定方法の特性について理解する必要がある。
／＊／
テスト計画書は承認を得る必要がある。
承認を誰に得るかは組織によって異なる。
正式な承認会議を開く場合もあるが、時間の節約のため、チャットや電子メールで不備や要望がないか関係者に確認をとるだけの場合もある。
／＊／
テストの終了基準は、何によってテストを終えたと判断するかである。
たとえば、重要度「高」の不具合が残っていないこと、重要度「高」の不具合が48時間以内に見つかっていないこと、すべてのテストケースの98パーセントが合格となっていることなどである。
出荷を急ぐ開発責任者が不具合の残ったソフトウェアを詭弁で出荷したりしないようにするため、終了基準には測定できる数値を記載するべきである。
たとえば、「24時間ソフトウェアを稼働させても充分安定していること」という終了基準の場合、何度かハングアップするソフトウェアでも「ハングアップしてもすぐに復旧できる」「24時間中23時間50分は問題なく動作する」と主張して製品を出荷する恐れがある。
製品に不具合があった場合、営業やユーザサポートから非難されるのはテスト担当者であるため、自衛のためにも終了基準の記載には注意すべきである。
部品: レビュー
ソフトウェア・レビュー(software review)とは、静的テストのひとつで、単にレビューとも呼ばれる。
ソフトウェア・レビューは、仕様書や設計書、ソースコードなど、ソフトウェア開発の工程で作成された成果物の内容を確認・検証し、不具合や欠陥などの問題点を発見する作業である。
ソフトウェアの不具合や欠陥は、一般に開発工程の初期に発見したほうが修正に費やす費用や時間が少ないとされている。
ソフトウェア・レビューは、ソースコードを記述する前から実施することができるものもあるため、問題を早く気づくために有用である。
レビューで見つかった不具合や欠陥は、修正し忘れることがないよう、どこにどのような指摘があったか記録される。
不具合や欠陥が修正されているか確認する目的で、すでにレビューした仕様書やソースコードを再度レビューすることもある。
誰がソフトウェア・レビューをおこなうのかという観点から分類すると、机上チェック、ピアレビュー、IV&Vに分けられる。
また、何をレビューするかという観点から分類すると、外部設計書や内部設計書などをレビューするデザインレビュー(design review)と、プログラムのソースコードをレビューするソースコードレビューに分けられる。
デザインレビューでは要件定義書や仕様書などで、要件や仕様の不備・不足に気づきやすい構成になっているかどうかも検証の対象である。
／＊／
机上チェック(desk checking)とは、ソフトウェア・レビューのひとつで、知類が仕様書やソースコードなどを目視確認する検証方法である。
基本的に仕様書やソースコードの作成者本人が確認する。
作成者本人が確認しているため、ピアレビューと比べ、検証の精度は劣るとされている。
机上チェックは、机上検査とも呼ばれる。
／＊／
ソフトウェア開発において、ピアレビュー(peer review)とは、ソフトウェア・レビューのひとつで、作成者の同僚やチームの仲間が成果物を確認する検証方法である。
また、ピアレビューにはチーム内で知識を共有したり、他社の技術を学ぶ側面もある。
ピアレビューには、ソフトウェアを開発する組織内の公式な活動か否か、参加者の人数などによって、コード・レビュー(code review)やソフトウェア・インスペクション(software inspection)など、いくつかの種類に分類される。
余談だが、ソフトウェア開発以外の分野でピアレビューとは、学会誌に学術論文を掲載する際、発表に値する内容か否かを判断するため、同じ分野の研修者にその論文を読んでもらうことである。
／＊／
IV&V(independent verification and validation)とは、第三者による検証のこと、または検証する第三者のこと。
ここでいう第三者とは、ソフトウェアを開発する組織とも、ソフトウェアの開発を委託した組織とも、管理面や財政面で独立した組織のことである。
第三者が静的テストや動的テストをおこなうことで、検証の客観性を保証する。
／＊／
要件のレビューでは、要件定義書に記述された内容に不備や不足がないか、チェックリストを使って検証し、記述されるべき内容が含まれているかを確認することが重要である。
要件はできるだけ緻密かつ精確に検討することが理想である。
一般に、要件は他の開発工程と同様に、荒いものから徐々に完成度を高めていくという工程を経る。
開発の初期段階では、開発に必要な水準まで要件が定まっていなかったり、必要な要件が出し切れていない恐れがあったり、時間不足で検討できずに保留となっているものがあったりすることがある。
このような限界を前提として共有することで、要件を円滑にレビューすることができる。
また、顧客や利用者の業務内容や業務で使う用語について、充分に理解できなかったり、完全には確認できなかったりという限界もある。
そのため、顧客の各業務の担当者を代表として集め、要件定義書の完了レビューをおこなうことが望ましい。
顧客から要件の内容に不備がないことを確認してもらったら、承認を得たことを署名捺印など法的効力がある形で記録に残すとよい。
／＊／
外部設計のレビューでは、外部設計書に記述された内容が要件定義書の記述と矛盾していないか、整合性がとれているかを検証する。
矛盾がある場合はなぜ矛盾しているのか、その理由が明記されていること、および関係者から了解を得ていることを確認する。
また、外部設計として記述すべき入出力や外部インターフェースが不備なく規定されており、論理関係が矛盾していないことも検証する。
内部設計のレビューも同様に、内部設計書の記述内容が要件定義書や外部設計書の記述と矛盾がないことを確認する。
内部設計では、どのようにプログラムを実装するのか、具体的なアルゴリズムが充分に明記されていることもレビューで確認する。
処理すべきデータがない場合はどのような処理になるのか、各種データの初期値なども、内部設計のレビューで確認すべき項目である。
／＊／
ソースコードレビューでは、コーディング規約に沿って記述されているか、内部設計書に記述された機能やデータ形式がプログラム上で正しく実現しているか、保守や再利用が容易なコードとなっているかを確認する。
また、ソースコードにコメントが記載されている場合、そのコメントが有意義か否か、コメント内容の正確さも確認する。
ソースコードを理解できないとレビューできないため、レビューに参加する者はプログラミングの基本的な知識に加え、使用するプログラミング言語の知識も有する必要がある。
ソースコードレビューで問題が見つかった箇所を記録し、分析することで問題が起こりやすい箇所が明らかになる。
分析結果をプログラミング時の注意点やコーディング規約に反映することで、ソフトウェアの品質向上につながる。
／＊／
ソフトウェア開発の関係者で「レビューができない」「レビューをするべきでない」と主張する場合、その者の思考様式や開発組織の文化に問題があると考えられるため、メタテストとしてその主張の理由を確認し、妥当でない場合は正したほうがよい。
たとえば「プログラマ以外が設計書を見ても問題を見つけられない」という主張には「プログラマ以外でも誤字脱字や論理的な誤りは指摘できる」と反論できる。
／＊／
前工程で見つかるべき不備や不具合が後工程で見つかった場合、レビューやテストに不備があったと考えられる。
たとえば、要件のレビューで見つかるべき不備が、外部設計や内部設計のレビューで見つかった場合である。
このようにレビューが正しく機能していない場合、レビューのチェックリストに確認項目を追加・修正したほうがよい。
このチェックリストはソフトウェア開発をおこなう組織にとって知的財産であり、他のソフトウェアやシステムを開発する際も継承することが望ましい。
ただし、案件によって妥当でない確認項目については、責任者の承認を得て確認を省略してもよい。
また項目数が膨大になると確認が形骸化する恐れがあるため、定期的にチェックリストを見直し、不要な確認項目は削除することも検討したほうがよい。
部品: 非機能テスト
非機能テスト(non-functional testing)とは、ソフトウェアの非機能要件に関するテストのことである。
非機能テストには、ドキュメンテーションテスト、性能テスト、負荷テスト、ユーザビリティテスト、セキュリティテスト、保守性テスト、信頼性テスト、移植性テストなどがある。
非機能テストは、非機能要件テスト(non-functional requirement testing)とも呼ばれる。
／＊／
ドキュメンテーションテストとは、非機能テストのひとつで、ソフトウェアのマニュアルに不備がないか検証するテストである。
マニュアルとは、取り扱い説明書のことである。
マニュアルに記載されている操作手順に誤字脱字や順番の入れ違いがないか、記載された操作手順の通りに操作して意図した通りに動作するか、マニュアルの構成やレイアウトなどに問題がないかをドキュメンテーションテストで確認する。
／＊／
性能テストとは、非機能テストのひとつで、想定された状況でソフトウェアの性能が期待された通りに出ているか検証するテストである。
性能が期待通りとは、ソフトウェアを企画もしくは設計する段階で設定した性能を満たしているかということである。
性能の定義は具体的な数値におこなう。
たとえば「10分以内に300メガバイトのデータを処理する」や「決定ボタンを押して3秒以内に処理が終わる」などである。
性能要件が「300メガバイトのデータを10分以内に処理する」でも、1メガバイトのデータを処理するのに10分近くかかったり、301メガバイトのデータを処理するのに30分かかったりする場合は性能の問題として扱うべきである。
性能テストで見つかる不具合は最悪の場合、最初の設計からやり直すことになる。
そのため、ある程度プログラムが動くようになった時点で、定期的に性能テストを実行することが望ましい。
性能テストはパフォーマンステスト(performance test)とも呼ばれている。
／＊／
負荷テストとは、非機能テストのひとつで、負荷を与えた場合の動作を検証するテストである。
ライブやコンサートのチケットの予約システムのように複数名が同時にアクセスするシステムでは、何かの契機に利用が集中する恐れがある。
そのため、システムに負荷がかかっている状態での動作を確認しておく必要がある。
負荷テストをおこなうには実際に複数名が同時にアクセスするという方法もあるが、テストに必要な負荷が大きい場合、実施するテスト担当者やテスト用端末の確保が難しくなる。
そのため、一連の操作を自動でおこなうシミュレータを用意して負荷テストする場合もある。
一連の操作とは、コンサートのチケットの予約システムなら、コンサートを検索し、予約を入れ、決済するという操作である。
負荷テストの分類にはロードテストやストレステストなどに分けられる。
ロードテスト(load testing)とは、通常時やピーク時に想定される負荷をかけた場合の負荷テストである。
特にピーク時に想定される負荷をかけた場合の負荷テストをピークロードテスト(peak load testing)と呼ぶ。
ストレステスト(stress testing)とは、想定の上限を超えた場合の動作を検証するテストである。
たとえばコンサートのチケットの予約システムで高負荷をかけた場合、決済は済んでいるが予約が保存されていない場合、チケットを入手できなかった利用者から損害賠償を請求される恐れがある。
このような事態を防ぐため、高負荷で正常にシステムが正常に動作しない場合の動作を確認しておく必要がある。
／＊／
ユーザビリティテストとは、非機能テストのひとつで、開発した製品を実際に利用者に使ってもらうことで使い勝手や好みなどを確認するテストである。
種族や年齢層、職業、性別など、利用者によって使い方が異なる場合、それぞれの利用者に使ってもらうことが望ましい。
たとえば、大人と子供で使い方が異なると予想され、ユーザビリティテストに十名テストもらうなら、大人の利用者と子供の利用者を五名ずつにテストしてもらうなどである。
／＊／
セキュリティテストとは、非機能テストのひとつで、ソフトウェアが悪意ある者の攻撃に耐えうるかを検証するテストである。
個人情報が保存されているシステムから情報が流出したり、課金要素のあるゲームでプレイヤーのデータが復旧できないよう削除されたりした場合、企業の信用を失う事態になる。
そのため、ソフトウェアのセキュリティは非常に重要である。
セキュリティの問題は年々進歩し、高度となっているため、セキュリティテストをおこなうテスト担当者は日々、新しいセキュリティ技術を学び、新しいセキュリティ攻撃の手法を迅速に理解する必要がある。
部品: ホワイトボックステスト
ホワイトボックステスト(white-box testing)とは、プログラムの論理構造が正しいか否かを解析するためのテストである。
そのため、プログラムの内部構造がわかっていることがテストの前提である。
ホワイトボックステストは主に単体試験で採用されているテストである。
ホワイトボックステストは、クリアボックステスト(clear box testing)、グラスボックステスト(glass box testing)、透明ボックステスト(transparent box testing)、構造テスト(structural testing)などとも呼ばれる。
／＊／
制御パステストとはホワイトボックステストの主要な技法のひとつで、プログラムがどのような振る舞いをし、どのように制御され、どのように実行していくかをテストするものである。
制御パスとは命令や条件分岐などの組み合わせのことである。
プログラムの規模が大きくなると、制御パスは天文学的な数となるため、いくつかの網羅基準でテストする量を限定して実施される。
／＊／
網羅基準(coverage criteria)とは、テスト・カバレッジを算出する際、どれくらい細かくテストするかという基準である。
網羅基準はカバレッジ基準とも呼ばれる。
／＊／
テスト・カバレッジ(test coverage)とは、テスト対象となるソフトウェア全体のうち、テストを終えた、あるいはテストしようとしている箇所の割合のことである。
テスト・カバレッジは通常、パーセントの単位で数値によって表現される。
自動車や飛行機のような事故があった際、命に関わるようなものに使われるソフトウェアに関しては、限りなく100パーセントに近いテスト・カバレッジを要求される。
そうではない一般的なソフトウェアの場合、テスト・カバレッジはソフトウェアの対象によって異なるが、だいたい60パーセントから90パーセントまでが妥当とされている。
テスト・カバレッジには、プログラムのソースコードをどれだけテストしたかを示すコード・カバレッジや、仕様書や要件に対するどれだけテストしたかを示す仕様カバレッジ(要件カバレッジ)など、いくつか種類がある。
テスト・カバレッジは網羅率や被覆率とも呼ばれる。
／＊／
コード・カバレッジ(code coverage)とは、テストの対象となるプログラムのソースコード全体の中で、テストを終えた、あるいはテストしようとしている箇所の割合のことである。
コード・カバレッジはコード網羅率やコード被覆率とも呼ばれる。
コード・カバレッジはテスト・カバレッジの中で最も代表的なテスト指標である。
／＊／
行カバレッジ(line coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべてのコード行を少なくとも一回実行するよう、テストケースを用意するものである。
言い換えると、すべてのコード行を少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準が行カバレッジである。
／＊／
関数カバレッジ(function coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての関数を少なくとも一回実行するよう、テストケースを用意するものである。
言い換えると、すべての関数を少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準が関数カバレッジである。
／＊／
コール・カバレッジ(call coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての関数呼び出しを少なくとも一回実行するよう、テストケースを用意するものである。
言い換えると、すべての関数呼び出しを少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準がコール・カバレッジである。
／＊／
ステートメント・カバレッジ(statement coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのコード内の命令文(statement)を少なくとも一回実行するよう、テストケースを用意するものである。
ステートメント・カバレッジは、命令網羅や命令文網羅、C0カバレッジとも呼ばれる。
一般にプログラムは命令よりも分岐による問題が多いため、テスト手法としてステートメント・カバレッジはあまり有用ではない。
／＊／
ブランチ・カバレッジ(branch coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての分岐においてすべての分岐の方向を少なくとも一回実行するよう、テストケースを用意するものである。
たとえるなら「水曜日に女性客は割引」という条件に対し、割引になる場合と割引にならない場合の両方の結果を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。
プログラム上の分岐個所をソースコードから目視で確認するのは大変であるため、通常、フローチャートやフローグラフと呼ばれる図法で図示して分岐箇所や条件を確認することが多い。
ブランチ・カバレッジはステートメント・カバレッジと比べ、多くの問題を発見することができるが、テストケースの数が膨大となるため、構造が複雑で多くの問題が見つかりそうな箇所に限定してテストすると費用・時間の面で効率がよい。
ブランチ・カバレッジは、分岐網羅や判定条件網羅、ディシジョン・カバレッジ(decision coverage)、C1カバレッジとも呼ばれる。
／＊／
コンディション・カバレッジ(condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての開始と終了、および条件文の可能なすべての結果を少なくとも一回実行するよう、テストケースを用意するものである。
たとえるなら「水曜日に女性客は割引」という条件に対し、水曜の場合と水曜以外の場合、および女性の場合と女性以外の場合を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。
ステートメント・カバレッジやブランチ・カバレッジよりもテストケースが多くなりやすいカバレッジ基準である。
ただし、コンディション・カバレッジは分岐の方向を考慮しないため、コンディション・カバレッジでテスト・カバレッジが100パーセントになるテストケースでも、ステートメント・カバレッジやブランチ・カバレッジではテスト・カバレッジが100パーセント未満になる場合もある。
コンディション・カバレッジは、条件網羅や条件カバレッジ、C2カバレッジとも呼ばれる。
／＊／
ディシジョン/コンディション・カバレッジ(decision/condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、ブランチ・カバレッジとコンディション・カバレッジを合わせたものである。
たとえるなら「水曜日に女性客は割引」という条件に対し、水曜の場合と水曜以外の場合、女性の場合と女性以外の場合、および割引になる場合と割引にならない場合を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。
ディシジョン/コンディション・カバレッジは、判定条件/条件カバレッジや判定条件/条件網羅とも呼ばれる。
／＊／
複合条件網羅(multiple condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての判定において、あり得るすべての結果の組み合せが少なくとも一回実行するよう、テストケースを用意するものである。
たとえるなら「水曜日に女性客は割引」という条件に対し、水曜かつ女性の場合、水曜以外かつ女性の場合、水曜かつ女性以外の場合、水曜以外かつ女性以外の場合の四パターンを確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。
／＊／
パス・カバレッジ(path coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムにあり得るすべての制御パス少なくとも確認するよう、テストケースを用意するものである。
一般的な規模のソフトウェアでもテストケースが膨大となるため、そのすべてをテストすることは現実的ではない。
パス・カバレッジは、経路組み合わせカバレッジや経路組み合わせ網羅、C∞カバレッジとも呼ばれる。
／＊／
ループ・カバレッジ(loop coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムにあるすべてのループで、一度もループしない場合、一度ループした場合、複数回ループした場合をそれぞれ少なくとも一回ずつ実行するよう、テストケースを用意するものである。
ループとは繰り返し処理のことである。
ループによるソフトウェアの問題を見つけるためには、複数回ループした場合をより細かく場合分けするテスト戦略もある。
たとえば、もっとも典型的な回数ループした場合、想定する最大回数より一回少なくループした場合、想定する最大回数ループした場合、想定する最大回数より一回多くループした場合などに場合分けするテスト戦略である。
／＊／
制御パステストは、要求仕様あるいは開発者の意図通りにプログラムが実装されているかを検証するものである。
そのため、要求仕様や開発者の意図が誤っていた場合、制御パステストで問題を発見することはできない。
ここで開発者の意図とは、開発者が要求仕様をどのように解釈したかであり、要求仕様そのものではない。
また、本来あるべき機能がまるごとない場合も制御パステストで発見することは難しい。
マルチヤスクや割り込みによる問題も制御パステストでは発見困難である。
テスト・カバレッジを100パーセントに近づけるほど、テストにかかる費用や時間が等比級数的に増加するという問題もある。
ホワイトボックステストは数あるテスト技法のひとつであり、苦手な問題もあるため、そのソフトウェアにとって妥当なテスト・カバレッジを目標として設定することが重要である。
部品: ブラックボックステスト
ブラックボックステスト(black-box testing)とは、プログラムの入出力の対応関係だけを注目し、プログラムが仕様通りに動作しているか否かを検証する手法である。
そのため、プログラムの満たすべき品質が仕様となっていることが前提である。
仕様があいまいな場合、ブラックボックステストをする前に、プログラムがどのような振る舞いをするべきか、仕様を明確にする必要がある。
なお、ブラックボックステストをするうえで、プログラムの内部構造がわかっている必要はない。
ブラックボックステストには、同値分割や境界値分析などがある。
／＊／
同値分割(equivalence partitioning、equivalence class partitioning)とは、ブラックボックステストのひとつである。
同値分割とは、入力値を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす技法である。
たとえば、それぞれ1から99までの数値が入力できる二つの入力欄XとYがある場合、有効同値クラスと無効同値クラスの二つの部分集合に分ける。
有効同値とはプログラムが期待する入力値のことである。
上記の例では、XとYはどちらも1から99までの数値を入力することを期待しているため、有効同値は1から99までである。
無効同値はそれ以外のすべての値である。
XとYをそれぞれ1未満の場合、1以上99以下の場合、99を超過する場合の三つに分けると3通り×3通りで9通りのテストケースができる。
さらに0はゼロ除算(division by zero)や無限ループなどエラーの原因となりやすいため、XとYの両方が0のテストケースも追加すると、計10通りのテストケースとなる。
十通りのテストケースの具体的な値を例示すると、(X=-1,Y=-1)、(X=-1,Y=50)、(X=-1,Y=100)、(X=50,Y=-1)、(X=50,Y=50)、(X=50,Y=100)、(X=100,Y=-1)、(X=100,Y=50)、(X=100,Y=100)、(X=0,Y=0)である。
有効同値は1から99までであるため、(X=50,Y=50)を(X=1,Y=1)や(X=99,Y=99)にしてもよい。
同様に(X=-1,Y=-1)を(X=-100,Y=-100)にしたり、(X=100,Y=100)を(X=999,Y=999)にしてもよい。
上記の例では、有効同値一つに対し、無効同値が九つではテストケースが膨大となる。
そのため、実際のテストでは、なるべく不具合を見逃さないように無効同値のテストケースを減らす必要がある。
たとえば、(X=-1,Y=-1)、(X=-1,Y=50)、(X=-1,Y=100)の三つのテストケースはいずれもXが1未満の場合のテストであるため、一つに減らす。
同様に、(X=-1,Y=100)、(X=50,Y=100)、(X=100,Y=100)の三つのテストケースはいずれもYが99を超過する場合のテストであるため、一つに減らす。
このように、他のテストケースでテストしていないもののみを残して、テストケースを減らすことで、不具合を見逃す恐れを減らしつつ、テストの時間と費用を節約できる。
／＊／
境界値分析(boundary value analysis)とは、ブラックボックステストのひとつで、境界値近くを詳しくテストする技法である。
境界値とは、無効同値と有効同値の間の値や、ある有効同値と別の有効同値の間の値などである。
プログラムの不具合は、境界値付近に潜んでいることが多い。
たとえば、仕様では「1以上」となっているところを誤って「1より大きい」と設定してしまったり、「99以下」とするべきところを「99未満」と設定してしまったりすることがありうる。
そのため、たとえば有効な値が「10以上20以下」なら、有効な値の上限(20)と下限(10)に加え、有効な値の上限に近い無効な値(21)、有効な値の下限に近い無効な値(9)をテストする。
さらに、有効な値の中央(15)と、エラーの原因となりやすい0を加えるとテストケースは6通りとなる。
上記はプログラムが単純な場合の例であったが、実際のプログラムではデータが複雑に絡み合い、テストケースを網羅することが時間的制約やテスト担当者のスキルの面で難しいケースがある。
その場合、良いデータと悪いデータを必ずテストするようにする。
ここでいう良いデータとは、利用者がよく使いそうな値、有効な値の上限と下限である。
また、悪いデータとは、-999999や0.0000001のような極端に小さいデータ、999999のような極端に大きいデータ、abcdefghijklmnopqrstuのような非常に長いデータ、無効な値などである。
0は良いデータであるか、悪いデータであるかに関わらず、入力できる場合、必ずテストしたほうがよい。
境界値分析は、限界値分析とも呼ばれる。
／＊／
原因結果グラフとは、プログラムに対する入力条件と、入力に対応するプログラムの動作を図示したグラフのことである。
原因結果グラフは、原因効果グラフ、CEG(cause-effect graph)とも呼ばれる。
／＊／
デシジョンテーブル(decision table)とは、テスト対象プログラムの入力条件や入力データと、その結果の動作や処理を表にまとめたものである。
表形式になっているため、文章で羅列されているよりも分かりやすく、どのテストをおこなったかも記録しやすい。
デシジョンテーブルは、決定表とも呼ばれる。
／＊／
原因結果グラフ技法(cause-effect graphing technique)とは、原因結果グラフとデシジョンテーブルを使って、有効なテストケースを抽出する方法である。
仕様から原因結果グラフを作成し、完成したグラフをディシジョンテーブルに変換する。
原因結果グラフをディシジョンテーブルに変換することは難しいため、自動変換ツールで変換することが多い。
／＊／
状態遷移テスト(state transition testing)とは、ブラックボックステストのひとつで、テスト対象プログラムがどのような状態を持ち、どのような条件やイベントで、他の状態に遷移するかを検証するテストである。
たとえば、入力待ちの状態で入力された場合、処理中の状態に遷移するかを検証するものが状態遷移テストである。
状態遷移テストにより、期待しない状態に遷移する不具合や、遷移自体が起こらない不具合を見つけることができる。
状態遷移の図表で表現する方法として、ステートマシン図(state machine diagram)などの状態遷移図(state diagram、state transition diagram)や、状態遷移表(state transition table)などがある。
ステートマシン図は状態マシン図とも呼ばれる。
／＊／
ランダムテスト(random testing)とは、事前にテストケースを考えず、行き当たりばったりに入力や操作をおこなうテスト手法である。
ランダムテストは、事前に同値を分割したり、境界値を分析したりする必要がない、荒っぽい方法であるが、このテスト方法でもかなりの数の不具合を見つけられる場合がある。
セキュリティテストでは、ファズテスト(fuzz testing)やファジング(fuzzing)と呼ばれるランダムテストが用いられている。
ファズ(fuzz)とは、予測が困難な入力データのことである。
ただし、同値分割や境界値分析などの方法でなければ、見つけにくい不具合もあるため、セキュリティテスト以外ではランダムテストは推奨されていない。
ランダムテストは、アドホックテスト(ad hoc testing)、ゲリラテスト(guerrilla testing)、モンキーテスト(monkey testing)などとも呼ばれる。
／＊／
エラー推測(error guessing)とは、ブラックボックステストのひとつで、経験から知られている不具合が起こりやすいパターンからテストケースを作る方法である。
たとえば、0やnull、ヌル文字、空文字列などはエラーが起きやすいデータのため、テストしたほうがよい。
数値を入力する箇所では小数や指数もエラーが起きやすいデータである。
エラー推測は、テスト担当者の知識や経験、想像力、洞察力に左右されるが、同値分割や境界値分析などで見つけられない不具合を検出することもある。
そのため、エラー推測は、同値分割や境界値分析など併用が有効である。
部品: 探索的テスト
探索的テスト(exploratory testing)とは、ソフトウェア・テストの方法のひとつ。
記述的テストと呼ばれる伝統的なソフトウェア・テストでは、事前に文書で定義したテストケースを順番にテストする。
そのため、テストケースを記述することに時間がかかり、テストを実行する時間が削られるという問題があった。
探索的テストではテストケースを書くことを重視せず、テスト対象となるソフトウェアについて学習し、事前・直前のテスト結果やテスト時のソフトウェアの振る舞いから臨機応変にテストするものである。
ここでいう学習とはソフトウェアを実際に動かして学ぶだけではなく、仕様書やソースコードを読んだり、既存のテスト結果を確認したり、ソフトウェアの開発者と対話することも含まれる。
探索的テストの具体的な手順としては、まず何がテストの合否を決めるか、その判断基準を決める。
次にテスト対象となるソフトウェアからテストすべき機能を列挙する。
テストすべき機能のリストアップが終わったら、危なそうな機能や操作などを列挙する。
こうしてリストアップされた機能や操作に対し、臨機応変にテストし、判断基準に照らし合わせ、不具合か否かを確認する。
上記のような探索的テストを複数回おこなう場合、工夫を加えることでさらに不具合の発見を増やすことができる。
たとえば、テスト担当者が複数いるならお互いのテスト担当範囲を交換したり、複数の環境で動作するソフトウェアなら環境を変えてテストするなどである。
ただし、ユーザビリティテスト以外の非機能テスト、たとえば性能テストや負荷テスト、セキュリティテストなどでは、探索的テストはテストケースを記述するテストと比べ、あまり不具合を見つけられないという欠点がある。
テスト対象となるソフトウェアについてよく知っているテスト担当者が利用者の視点でテストをすることが探索的テストといえるため、ユーザビリティテストでは記述テストと比べ、多くの不具合を見つけやすい。
探索的テストは、もともとアドホックテストと呼ばれていたが、アドホックテストがランダムテストを意味するようになったため、探索的テスト、あるいは探索型テストと呼ばれるようになった。
部品: 単体テスト・結合テスト
単体テストとは、関数や手続きなどの最小単位(モジュール)でプログラムを動作して内部設計通りに動作するか検証する工程である。
ソフトウェアは規模が大きくなると、指数関数的に複雑になるため、問題が起きている箇所を特定することが難しくなる。
そのため、できるだけ狭い範囲に絞って検証することで必要な労力を抑えることができる。
単体テストはこの原理に沿ったテストである。
単体テストは、ユニットテスト(unit testing)、モジュールテスト(module testing)、単体試験とも呼ばれる。
／＊／
結合テスト(integration testing)とは、複数のモジュールを結合して動作を検証する工程である。
結合テストの主な目的は、モジュールとモジュールの間でインターフェイスやデータの受け渡しが、外部設計通りに動作しているか検証することである。
単体テストがひとつひとつのモジュールが正常に動作しているかコンポーネントの細部を検証しているのに対し、結合テストはコンポーネント間の細部を検証している。
何をテストしているかが異なるため、単体テストと結合テストのどちらか一方を省略することはできない。
建築にたとえるなら、単体テストは建築材料の品質を検証しているのに対し、結合テストは建築材料で作られた壁や床を検証している。
建築材料の強度が基準に満たない場合も、水平になるよう設計された床が斜めに傾いている場合も、どちらも建築物として適切ではない。
ただし、ソフトウェア開発において、単体テストの範囲が広い場合、単体テストと結合テストの区別が難しいこともある。
結合テストはI 、結合試験とも呼ばれる。
また、粒度や目的に応じて、モジュール結合テスト、機能結合テスト、サブシステム結合テストなどと呼び分けられることもある。
／＊／
総合テストとは、定められた環境で要件定義や外部設計の内容を実現できているか否かを総合的に検証するテストである。
結合テストで外部設計の内容を満たしていることを確認したプログラムを、そのプログラムするハードウェアやネットワーク、利用者端末など、本番と同じ環境を用いて検証する。
本番と同じ環境を用意できない場合、本番に近い環境で総合テストを行う場合もある。
総合テストで検証する項目は大きく機能要件と非機能要件に分けられる。
また、総合テストでは仕様で想定していない状況や利用者の誤操作などを踏まえてシステムの不備を検証することもある。
総合テストは、システムテスト(system testing)とも呼ばれる。
／＊／
受け入れテストとは、作られたプログラムが業務に使えるかを検証するためのテストである。
単体テストや結合テスト、総合テストなどが開発者側がおこなうテストであるのに対し、受け入れテストは利用者や購入者が主体となって検証する。
また、下請けから納品された成果物を元請けが検収することを受け入れテストと呼ぶ場合もある。
受け入れテストは、受け入れ試験、検収テスト、承認テスト、OAT(operational acceptance testing)、ORT(operational readiness testing)、OR&A(operations readiness and assurance testing)などとも呼ばれる。
また、業務部門の利用者やシステム管理者など、誰が承認にするのかによって、ユーザー受け入れテスト、運用受け入れテストなどに分類される。
部品: メタテストとは
メタテストとは、テストをテストすることである。
メタテストはコンピュータでソフトウェアを実行したり、ソースコードを見直したりしなくても実行できる。
たとえば、仕様書のような重要な書類がどこにあるか分からず、いつ仕様書を見つけられるか見通しも立たない場合、その組織の開発工程に問題があることは容易に想像できる。
また、進捗の遅れているコードほどテストしないような開発工程は、綿密にテストすべきコードほどテストしていないため、開発工程に問題があると考えられる。
あるいは、プログラムに不具合があると担当した開発者に罰則を与えたり、不具合を見つけたテスト担当者や不具合をすぐに修正した開発者に恩賞を与えたりすると、罰則を恐れて不具合を隠蔽したり、恩賞を得るためテスト担当者と開発者が結託して意図的に不具合を作ったり、不具合の発見した時期を偽ったりするなどの弊害が考えられる。
上司や顧客に対し、進捗が実際よりも良いよう見せるため、発見した不具合の数や重要度の記録を改ざんすることが常態化している場合、その開発組織の文化に問題があると考えられる。
このように「ソフトウェア開発で取り扱っている情報の質」に関する情報を知り、適切に使うことで、開発やテストの効率を大幅に改善し、費用や時間を節約することができる。
そのため、テスト結果の報告書に重要な情報がすべて記載されていると思わず、どのようにテストが実施され、その裏で何があるか直接観察して検証することが望ましい。
なぜなら、テストの手順を文書に明記してあったとしても、必ずしもテスト担当者がその内容を守っているとは限らないからである。
特にテスト結果の報告書に記載されているデータが整いすぎている場合、虚偽のテスト結果ではないか疑ったほうがよい。
ただし、開発者やテスト担当者を過度にテストすることは開発工程に悪影響を及ぼす恐れがあるため、適切な範囲でおこなうことが望ましい。
部品: ドッグフードテスト
ドッグフードテストとは、開発した製品を開発者自身が実際に使用するテストである。
ドッグフードテストは、ドッグフーディング(dogfooding)とも呼ばれている。
ドッグフードテストの目的は、開発した製品に対し、開発者がどの程度自身があるかを確かめるためである。
たとえば、自動車のステアリングとブレーキ制御に関する組込みソフトを作った場合、その製品を搭載した車両に開発者を運転手として乗せ、テストコースで実際に走行してもらう。
もし、開発した製品に自信がないのなら、あまり速度を出さなかったり、すぐに運転をやめたりするはずである。
開発者によっては向こう見ずだったり、臆病だったりするため、ドッグフードテストのみで製品の良否を確かめるのは不適切だが、メタテストの出発点としては有用である。
なお、ドッグフードテストの名前は、一説によると「人知類が犬知類の食糧を作るなら、まず作った本人が食べろ」という故事に由来するとされている。
部品: 獲得時間
ソフトウェア開発において、獲得時間とは、要件定義書や仕様書のレビューによって見つかった不備・欠陥・不具合などの数から算出した、失わずに済んだ時間である。
たとえば、仕様書をレビューし、50個の欠陥が見つかったとする。
もしプログラムを実装後に欠陥を直した場合、ひとつの欠陥を直すのに平均で4時間かかるとすると、すべての欠陥を修正するのにおよそ200時間かかる。
仮にレビューが40時間で終わったのなら、差し引き160時間を失わずに済んだことになる。
このように獲得時間という数値で計測することで、レビューの効果を目に見える形にすることができる。
なお、獲得時間を計算する際、レビューによって仕様書が適切な体裁や内容になることにより、ソースコードから仕様を確認する手間が省ける時間は考慮しない。
提出書式
大部品: ソフトウェア開発工程 RD:23 評価値:7
-大部品: 上流工程（ソフトウェア開発） RD:10 評価値:5
--大部品: RFP・要件定義 RD:9 評価値:5
---部品: RFP・提案書
---部品: 要求仕様書・要件定義書
---部品: ドメイン知識
---部品: システム導入の目的
---部品: 制約条件
---部品: 機能要件・非機能要件
---大部品: 変更管理 RD:3 評価値:3
----部品: 変更管理とは
----部品: 要件管理ツール
----部品: 仕様変更率
--大部品: 外部設計・内部設計 RD:1 評価値:1
---部品: 外部設計・内部設計とは
-大部品: 下流工程（ソフトウェア開発） RD:13 評価値:6
--大部品: コーディング（ソフトウェア開発） RD:1 評価値:1
---部品: コーディングとは
--大部品: ソフトウェア・テスト RD:12 評価値:6
---部品: ソフトウェア・テストとは
---部品: テストの分類
---部品: テスト計画書
---部品: レビュー
---部品: 非機能テスト
---部品: ホワイトボックステスト
---部品: ブラックボックステスト
---部品: 探索的テスト
---部品: 単体テスト・結合テスト
---大部品: メタテスト RD:3 評価値:3
----部品: メタテストとは
----部品: ドッグフードテスト
----部品: 獲得時間
部品: RFP・提案書
RFPとは、Request For Proposalの略で、提案依頼書のこと。
提案依頼書とは、情報システムの導入・構築や業務委託をおこなうにあたり、開発を依頼する発注元(発注者)が具体的な提案を依頼するために、発注先候補の事業者に交付する文書のことである。
業種・業態・組織・提供する製品やサービスといった発注元の基本情報、なぜシステムやサービスを導入するのかといった導入の背景、システム開発やサービス導入にどのような便益を期待しているかといった目的、どのような部門のどのような業務の者がだいたい何名ぐらい使用するのか、各機能やサービスはそれぞれいつまでにどのようなスケジュール・どれくらいの予算で完成させたいかといった調達条件などといったことがRFPに書かれている。
RFPの目的は、提案内容と見積もりから最も適した発注先(受注者)を選ぶことである。
RFPは、発注元が発注先の事情や技術上の制約を気にせずに自身の要望を書いているため、開発を請け負う側はRFPから本当に欲しいものはなんなのかを見抜くことが重要である。
／＊／
システム提案書とは、RFPに対する回答として、発注先から発注元に提出される資料のこと。
RFPに対する回答は、特に訂正・削除がない場合、そのまま要件として扱われる場合もある。
そのため、RFPに記載された、発注元の誤った認識による不適切な実現方法に対し、発注先は妥当な代替手段を検討する必要がある。
そのうえで、どこまでの範囲の業務を開発するシステムで対応するか、発注元と発注先で開発の役割や責任をどのように分担するか、開発に関する報告や会議の頻度・スケジュール、利用者にシステムの使い方を教育する必要があるかなどといったことを発注先は記載する。
発注元の責任で仕事が遅れたり、仕様が変更になったりした場合、開発方法やスケジュールの変更を提案・相談できるよう、発注先はシステム提案書に注意書きをしておいたほうがよい。
システム提案書は単に提案書とも呼ばれる。
部品: 要求仕様書・要件定義書
要求仕様書とは、発注元(発注者)が何をしたいのかという希望を、システム開発として実現して欲しい機能に落とし込んで書いたものである。
RFPとは異なり、要求仕様書には調達条件は書かれていない。
／＊／
要件定義書は、要求仕様書に書かれた要望を実現するためにはどのようなシステムが必要か、機能要件・非機能要件などを発注先(受注者)が書いたものである。
ここでいう要件とは、必要な条件のことである。
要件定義書は、オペレーティングシステムやミドルウェアの選定を含まれ、提案書よりも具体的である。
要件は、そのシステムを作る背景や機能など、その時点でできる限り定量的に記述することが望ましい。
ただし、根拠のない数値は危険なため、書くべきでない。
また、要件は、その機能の及ぶ範囲が把握できるよう、適切に表現することが望ましい。
たとえば、「計測データが正常でなければ知らせる」と「計測データを表示中、重要な変化があった場合、画面に警告を表示する」のふたつの表現では、書き手が同じことを考えて書いたとしても、読み手の印象は大きく異なる。
同様に「印刷できない状況になった場合、担当者に知らせる」と「印刷途中で用紙やインクが不足するとわかった時点で、登録されている担当者に電子メールで知らせる」のふたつの表現でも、前者より後者のほうが、その機能がどのように動作してほしいか、その機能の及ぶ範囲がどこまでかが分かりやすい。
要件が複雑であったり、範囲が広い場合、ふたつの階層に分けて表現する。
たとえば、一階層目を「印刷途中で用紙やインクが不足するとわかった時点で、登録されている担当者に電子メールで知らせる」と簡潔に表現して要件の範囲を把握する。
そして、二階層目を「印刷中に用紙とインクの残量の情報を得る」「用紙の使用予定量と残量を比較し、用紙が不足しないか確かめる」「インクの使用予定量と残量を比較し、インクが不足しないか確かめる」「定型文からメール本文を作成する」「データベースから担当者のメールアドレスを得る」「電子メールを送信する」などとすれば、どのような機能を実装しなければならないかが具体的に分かるようになる。
ひとつの要件を階層化する際、三階層以上にしなければ分かりにくい場合、要件そのものの範囲が広すぎるため、ふたつ以上の要件に分割したほうがよい。
要件定義書に記載がない場合、しないことなのか、するかどうか決まっていないことなのか、あいまいとなるため、しないと決めたことについても明記するべきである。
要件を不採用にすることが妥当か確認できるようにするため、不採用にした根拠や理由も明記したほうがよい。
要件定義書の内容と直接関係ないが、文章の読みやすさも品質のひとつであるため、使用する文体や表記、用字・用語は統一したほうが良い。
また、表現にも気をつけたほうがよい。
たとえば「処理を1秒以内に終えるべき」という表現だと「処理を1秒以内に終えること」が要件なのか、努力目標なのか解釈が分かれ、問題になる恐れがある。
上記のように、要件定義書の内容で考慮すべき点は多岐にわたるため、要件の抜け・漏れなどの不備がないよう、確認・検証が必要である。
概算の相見積もりの際、発注元は当初予定していたが要求が過不足なく満たされているか、要求仕様書と要件定義書を見比べ、吟味することが重要である。
必要以上に高度な機能で無駄な費用が要求されていたり、必要な機能が盛り込まれていなかったりした場合、発注元は発注先に要件定義書の記載内容を改めるよう求めることが望ましい。
なお、相見積もりとは、複数の事業者から見積書を提出してもらい、品質・価格・納期などを比較・検討することである。
／＊／
余談だが、要求と要件は英語ではどちらもrequirementと表記する。
要求と要件を混同する場合は「顧客の」「システムの」を前につけるとよい。
「顧客の要求」という表現はあるが、「システムの要求」という表現は適切ではない。
同様に「システムの要件」という表現はあるが、「顧客の要件」という表現は適切ではない。
なお、ソフトウェア開発における要求・要件であることを明確にするため、ソフトウェア要求(software requirements)、ソフトウェア要件と表記する場合もある。
部品: ドメイン知識
ドメイン(domain)とは、分野や領域を指す。
ドメイン知識(domain knowledge)とは、ある分野の専門家がもつその分野固有の知識である。
ドメイン知識を得る方法には、その分野・領域の実務者やアナリストに尋ねたり、実際に対象の業務に参加するなどがある。
ドメイン知識はシステムやソフトウェアの開発において重要である。
たとえば、流通を管理するソフトウェアを作成する場合、流通の専門知識が必要になる。
また、カーナビゲーションシステムを開発する場合、GPS(Global Positioning System)やGIS(Geographic Information System)、およびそれらに関連する規格・方式などの知識が必要になる。
素粒子分野と核物理分野で、核子のアイソスピンの定義が符号が逆になっているように、業界や業種によって同じ内容を異なる表現を用いている場合もある。
そのため、要件定義書を作成する際、発注元と発注先の間で要件の理解に齟齬がないよう、用語の意味を定義した辞書を作成することが望ましい。
また、システムやソフトウェアの開発で用語を使用する際、その用語の定義や表現が適切か、その妥当性を検証することも重要である。
ドメイン知識は、領域知識や領域固有知識とも呼ばれる。
部品: システム導入の目的
システム導入の目的とは、発注元がRFPや要求仕様書に記載する内容のひとつである。
たとえば、「生産性向上」「コスト削減」「顧客満足度向上」など、組織の経営に役立つか、利用者の便益に寄与するものがシステム導入の目的として挙げられる。
どの要件から実装するかは、システム導入の目的から実装の優先順位を考える。
また、開発中に要件が変更・追加される場合は、システム導入の目的を軸に妥当性を考える。
システム導入の目的にその要件変更・要件追加が必要か、すでにある要件で充分目的を達成できるかを考え、変更・追加が妥当でない場合、発注先はその要件の変更・追加を受け入れないほうが望ましい。
妥当でない要件を受け入れた結果、開発の進捗が順調でなくなったり、開発されたシステムやサービスが不調となったりした場合、その非は受け入れた発注先にある。
部品: 制約条件
制約条件とは、システムを開発する際、考慮しなければならない前提や制約のことである。
たとえば、「システムの操作担当者はカマキリのため、人知類用の入力機器が使用できない」「来年に税制が改正されるので、それまでにシステムが運用できるようにしてほしい」などである。
要件定義書を作成する際、発注先はどのような制約条件があるか網羅するよう、システムを使用する藩国の憲法や法令・規則・条例、利用者の操作技術・業務時間・使用環境など、様々な観点から発注元に聞き出す必要がある。
部品: 機能要件・非機能要件
機能要件(functional requirement)とは、システムが持たなければならない機能を定義したものである。
システムに何ができるのか・何ができないのかをできる限り、正確に網羅する必要がある。
具体的には「各機能ごとにどのような入出力があり、どのような処理がなされるか」「誰がいつどこでこの機能を利用し、どのような結果が得られるか」「なぜこの機能が必要か」などが機能要件として挙げられる。
それぞれの要件間で整合性がとれているか、他の資料と内容に矛盾はないか、読み手によって解釈が異なるようなあいまいな表現はないかなど、充分に注意しなければならない。
／＊／
非機能要件(non-functional requirement)とは、使いやすさやセキュリティなど、システムが持たなければならない性質を定義したものである。
非機能要件を多面的に検討するためには、そのシステムに関連する者は誰かを考えるとよい。
たとえば、システムを操作・運用する者、保守作業をする者、システムを改修・機能追加する者、システムに不正にアクセスしデータを盗む者などである。
それらの者がそれぞれどの程度の技術があり、いつどのような操作をするか、システムに問題が発生した場合、どのような行動をするかなどを考え、そこから求められる非機能を明確にする。
非機能要件は機能要件よりも検討すべき範囲が広いため、様々な立場のなるべく多くの者と話し合って、できるだけ多く洗い出すことが望ましい。
／＊／
性能要件(performance requirement)とは非機能要件のひとつで、システムが持つべき処理速度や取り扱えるデータ容量、センサーの精度など、性能に関することである。
性能要件は「業務に支障のない範囲」「既存システムと同等」といったあいまいな表現ではなく、「操作完了後、一秒以内に次の画面に移動する」「二十三時に処理を開始し、翌日の七時半までに処理を終了する」など、具体的な数値で表すことが望ましい。
発注元が用意した機械でも「処理速度はどの程度か」「取り扱えるデータ容量はどのくらいか」といった点を、発注先は確認しておき、必要に応じて機械の買い替えを提案することが望ましい。
性能面で実際に動作してみないとわからない点については、「システムにアクセスする者が一名の場合」といった前提条件をつけて性能要件を表現する。
その性能が充分でない場合、業務に重大な影響を与える危険性が高く、机上の計算では不安なものについては、妥当な実現方法を検討するため、類似環境やテストデータを用意し、実験で確認する必要がある。
／＊／
セキュリティ要件(security requirement)とは非機能要件のひとつで、システムの機密性に関するものである。
たとえば「データをどのような暗号形式で保存するのか」「不正なアクセスを防ぐためにどのような認証方式を採用するのか」「障害が発生した場合、速やかに復旧するためにどのような対策を講じるのか」などが挙げられる。
発注先は発注元よりもセキュリティの知見を有するため、発注元から要望がなくても発注先は積極的にセキュリティについて調査し、その見積もりを提出するほうが望ましい。
そこまでしたうえで、発注元がセキュリティ対策は不要だと判断した場合、セキュリティ上の問題が発生した際の非は発注元にある。
部品: 変更管理とは
要件定義において変更管理とは、いったん確定した要件・仕様・設計に対して発生した変更の管理である。
変更管理は窓口を一本化し、変更管理担当者が一元的に管理することが望ましい。
変更を要求する場合、業務上および技術上、その変更をおこなうべき妥当な根拠があるか確認したうえで、変更管理担当者に報告する。
変更管理担当者は、その変更で影響を受ける開発担当者に調査を依頼する。
変更は必要か、実現できるか、実現する場合どのような方法か、変更による作業やスケジュールへの影響はどの程度か、変更にどの程度の時間・費用が必要か、誰がその変更を実施するのか、優先順位はどの程度かなどを調査したうえで、計画に基づいて変更を実施する。
実施した変更は、進捗・状況を定期的に確認し、必要に応じて是正する。
発注先は変更管理の工数もプロジェクト管理費用に含め、発注元に認めてもらうことが重要である。
部品: 要件管理ツール
要件管理ツール(requirements management tool)、または要求管理ツールとは、要件や要求を管理するためのツールの総称である。
要件・要求の管理とは、顧客や利用者からシステムに対する要望を引き出すこと、要件・要求を文書化し体系づけて整理すること、期間内・予算内に開発を終えるため発注元(発注者)と発注先(受注者)の間で要件・要求の範囲について合意を形成することなどである。
一般に要件管理ツールは、システムやソフトウェアの開発チームが一元的に要件・要求を登録・編集・参照できる機能を有する。
そのため、要件管理ツールを用いることで、最新の要件を開発チームのメンバー全員が知ることができる。
また、要件のトレーサビリティを管理するため、要件管理ツールはトレーサビリティ・マトリクスを登録・編集・参照できる機能を有する。
要件管理ツールを正しく使いこなすためには、どのように要件や要求を管理しているかが重要となってくる。
／＊／
ソフトウェア開発において、トレーサビリティ(traceability)とは、仕様書やプログラムなど、各工程や各作業で作られた成果物がどの成果物に影響を与えているか、追跡できることを指す。
たとえば「要件定義書のA010の要件を変更した場合、整合性を保つため、外部設計書BのB010と外部設計書CのC030も変更する必要がある」「外部設計書BのB010を変更した場合、内部設計書DのD050と結合テスト仕様書XのX320も変更する必要がある」「内部設計書DのD050を変更すると、プログラムEのE120と単体テスト計画書YのY090を修正する必要がある」などである。
上記の例に出てくるA010やB010などは、追跡を容易にするため、要件や仕様に割り当てられた固有の番号である。
ソースコード上にコメントとして上記の番号を記載することで、要件や仕様が変更になった際、プログラムの修正が容易になる。
トレーサビリティを管理することで、インパクト分析やカバレッジ分析をおこなえるようになる。
トレーサビリティは、追跡可能性とも呼ばれる。
／＊／
トレーサビリティ・マトリクス(traceability matrix)とは、それぞれの成果物の間の追跡可能性を確保するために考え出された表である。
たとえば要件と外部設計のトレーサビリティ・マトリクスなら、縦に要件、横に外部設計の固有の番号がそれぞれ記述される。
A010の要件を変更した際、整合性を保つため、B010の外部設計が変更しなければならない場合、A010の要件の行と、B010の外部設計の列の、交点の升目に印をする。
このように、印をした升目から要件の行と外部設計の列を確認することで、一方を変更した際、他方の修正の必要な箇所がすぐに分かる。
トレーサビリティ・マトリクスは、一般的な表計算ソフト(spreadsheet)でも作成できるが、作成と保守に必要な労力が大きい。
そのため、規模の大きいプロジェクトでは、要件管理ツールのような専門のソフトウェアを用いることが多い。
トレーサビリティ・マトリクスは、追跡可能マトリクスとも呼ばれる。
／＊／
要件や要求の管理において、インパクト分析(impact analysis)とは、要件や仕様を変更した際、仕様書やプログラムに与える影響を評価することである。
影響の大きさを知ることで、要件の変更や追加を受け入れるか否かを決める際の判断材料になる。
インパクト分析は、変更波及解析(change impact analysis)、影響波及解析とも呼ばれる。
／＊／
要件や要求の管理において、カバレッジ分析(coverage analysis)とは、不要・余分な仕様がないか、あるいは足りない仕様がないかを評価することである。
不要・余分な仕様とは、要件定義書に対応する要件がない仕様である。
また、足りない仕様とは、要件定義書に記載されている要件に対応する仕様がないことである。
仕様の過不足を知ることで、不要な機能を作ったり、必要な機能が足りなかったりすることを防ぐことができる。
部品: 仕様変更率
ソフトウェア開発において、仕様変更率とは、変更された仕様の件数をすべての仕様の件数で割った割合である。
仕様変更率は、要件定義書や仕様書の出来栄えを判断する指標となる。
仕様変更率が高い場合、要件定義書や仕様書の様式や内容にあいまいなところがあると考えられる。
たとえば、入力値の検証に関する仕様変更があったとき、そもそも入力値の検証を想定せずに仕様書を作成していた場合、その仕様変更をプログラムのどの箇所でおこなうのが妥当なのかというところから検討しなければならなくなる。
適切な仕様書がある場合、どこで仕様変更に対応するかがおのずと決まるため、仕様変更の影響範囲を小さく抑えることができる。
仕様変更率が高いプロジェクトと低いプロジェクトを比較すると、どこに改善の余地があるかがわかりやすい。
たとえば、仕様変更率が高いプロジェクトは顧客にいわれた仕様変更をそのまま受け入れているのに対し、仕様変更率が低いプロジェクトはその仕様変更がどのような要求から出てきたのかを確認していることが多い。
具体的に例を挙げると、「監視カメラの首振り角度を30度から45度に変更してほしい」と依頼があった場合、首振り角度を広げる理由を確認する。
ひとつの監視カメラが撮影する範囲を広げることで、監視カメラの設置台数を減らし、導入費用を下げることが目的なら、首振り角度の変更で死角ができないよう、カメラの首振り速度を変更するといった対応も必要になってくる。
このように、なぜその仕様変更が必要なのかを確認することで、合わせて対応が必要な箇所に気づくことができる。
また、要求によっては仕様を変更せず、既存の機能で対応できる場合もある。
部品: 外部設計・内部設計とは
ソフトウェア開発において、外部設計(external design)とは、開発するシステムが利用者や外部のシステムに対し、機能やインターフェイスをどのように提供するかを設計することである。
外部設計は、基本設計(basic design)や概要設計(outline design)と呼ばれることもある。
外部設計を文書にまとめたものを外部設計書や外部仕様書などと呼ぶ。
外部設計書に記載される内容は、要件定義に基づいて作成される。
具体的には、システムの目的や方針、機能、ユーザインタフェース、ソフトウェア構成、ハードウェア構成、ネットワーク構成、システムインタフェースなどが外部設計書に記載される。
外部設計書を作成する際、現行の業務の流れを知ることが重要である。
業務のどの部分をソフトウェアが担当するか、どの業務を変更するか、ソフトウェアの導入前後の業務の流れをそれぞれ図表で表現することで、システムの規模が明確になり、開発の日程や予算が試算できるようになる。
確定していない仕様については顧客と交渉している状態を記載する。
たとえば、画像ファイルの保存形式に「未定」と記載されていると、必要な工数や費用を見積もることができないが、「対応する画像ファイルの保存形式は下記のいずれかを予定」という仕様の下に、保存形式の候補が記載してあれば、開発に必要な日程や費用を推測できる。
候補の中で特に有力なものがあるなら、そのことも明示するとよい。
データベースの設計については、ER図やCRUD図などが記載される。
ER図(entity-relationship diagram)とは、データベースの各テーブルが互いにどのように参照しているかを表した図である。
また、CRUD図とは、どの権限を持つ利用者やシステムに対し、生成(create)・読み取り(read)・更新(update)・削除(delete)を許可するかを表した図表である。
外部設計は、顧客や利用者の目に触れる部分を決めるため、顧客の仕事の結果に直接影響することもある。
そのため、外部設計の内容については顧客の了承を得ることが望ましい。
／＊／
ソフトウェア開発において、内部設計(internal design)とは、外部設計に基づいてプログラムやシステムの内部における具体的な処理の手順や実装方法について設計することである。
内部設計は、詳細設計(detail design)と呼ばれることもある。
内部設計を文書にまとめたものを内部設計書や内部仕様書などと呼ぶ。
内部設計書に記載される内容は、要件定義と外部設計に基づいて作成される。
具体的には、入出力情報のデータ構造、変数の初期値、定数の値、例外処理・エラー処理・異常処理の定義と設計、メモリ使用量の見積もり、割り込みや多重起動の対策、排他制御のロック・アンロックのタイミングなどが内部設計書に記載される。
内部設計は、外部設計と異なり、顧客や利用者の目に触れない部分である。そのため、顧客の了承を得る必要はほとんどなく、ソフトウェア開発の担当者が理解できる内容になっていればよい。
部品: コーディングとは
ソフトウェア開発において、コーディング(coding)とは、コンピュータ言語を用いて、ソースコードを記述することである。
コーディングの対象となるコンピュータ言語には、プログラミング言語やデータ記述言語、スタイルシート言語などがあるが、プログラミング言語による記述をコーディングと呼ぶ場合が多い。
なお、文章構造を記述するための形式言語であるマークアップ言語は、データ記述言語の一種である。
プログラミング言語によるコーディングとは、課題の解決策をプログラムが実行できるよう、プログラミング言語に置き換え、ソースコードで記述することである。
コーディングをおこなう者をコーダー(coder)と呼ぶ。
プログラミング言語によるコーディングをプログラミング(programming)と呼ぶ場合もあるが、プログラミングにはプログラムの設計も含まれる。
プログラミングをする者をプログラマ(programmer)と呼ぶ。
プログラミング言語ごとに、それぞれシンタックスとセマンティクスが異なるため、コーダーがある言語のコーディングができても、別の言語のコーディングができるとは限らない。
なお、シンタックス(syntax)とは、構文や構文規則、文法とも呼ばれ、データの形式や構造、枠組みを指す。
セマンティクス(semantics)とは、データの意味や中身である。
コーディングする際は、シンタックスに応じて文字が色分けして表示するソースコードエディタ(source code editor)を用いると、ソースコードの書き間違いに気づきやすく便利である。
ソースコードエディタによっては、対応しているプログラミング言語の文法上の不備を警告で知らせる機能もある。
また、数字の0と英字大文字のOのような紛らわしい文字を判別できるよう、コーディングに適したフォントを用いると、ソースコードの書き間違いに気づきやすく便利である。
／＊／
ソフトウェア開発において、コーディング規約(coding conventions)とは、プログラミング言語やデータ記述言語などでコーディングする際のルールやガイドラインである。
複数名でコーディングをおこなう場合、コーダーによって記述方法が異なる場合、他のコーダーが記述したソースコードを読んだり直したりすることに時間がかかり、ミスも増える。
コーディング規約を遵守すると、ソースコードを読みやすくなるため、プログラムの保守性を上げ、ソフトウェアの品質向上につながる。
コーディング規約が遵守されているかは、レビューや静的解析によって確認・検証する。
コーディング規約としては、変数・定数・関数などの命名規則、オフサイドルールなど、様々な規則がある。
命名規則(naming convention)とは、どのような名前をつけるかという規則である。
オフサイドルール(off-side rule)とは、レイアウトルール(layout rule)とも呼ばれ、字下げによって文や関数のかたまりの範囲を示す規則である。
どのようなコーディングが読みやすいかは、コーダーがどのようなコーディングに慣れ親しんできたかが影響するため、明確に決めることは難しい。
そのため、コーダー同士でどのようなコーディングにすべきか論争とならないよう、妥当なコーディング規約を定めることが望ましい。
ソフトウェアを開発する組織やプログラミング言語のコミュニティですでに普及しているコーディング規約があり、不適切でない場合、そのコーディング規約を採用することが望ましい。
また、レビューやテストで見つかったソフトウェアの不備が、コーディング規約の追加・修正で防げる場合、コーディング規約を更新することが望ましい。
コーディング規約は、コーディング規則(coding rules)、コーディング基準(coding standards)とも呼ばれる。
部品: ソフトウェア・テストとは
ソフトウェアの欠陥・不良・不具合・障害などの問題によって、ソフトウェア本来の機能が制限され、そのソフトウェアに期待される機能や価値を顧客や利用者に提供できない状態を、そのソフトウェアの品質が悪いと表現する。
こうしたソフトウェアの品質を改善するため、ソフトウェアの問題を見つけ出す行為を総じて、ソフトウェア・テスト(software testing)、あるいはソフトウェアV&V(software verification and validation)と呼ぶ。
ソフトウェア・テストには、問題が起きる操作を発見するために行われるテストや、問題が再現する条件を調べるためのテスト、問題を起こしているソースコードを特定するためのテストなど、いくつかの種類に分かれている。
ソフトウェア・テストは、ソフトウェアの品質を改善するために重要なものであるが、ソフトウェアのすべての問題を発見できるわけではない。
たとえば、それぞれ0から99までの数値が入力できる二つの入力欄があり、入力した二つの数値を積を表示するという単純なプログラムの場合でも、正常系のみをすべて試すだけで100通り×100通り＝1万通りのテストが必要になる。
英字や記号などを入力した場合や未入力の場合など、異常系のテストも含めると、テストケースはより多くなる。
さらに、このソフトウェアが対応すべき動作環境が10通りの中央演算処理装置、10通りのメモリ容量、10通りのドライブ容量とすると10通り×10通り×10通り＝1000種類のハードウェア構成でテストする必要がある。
実際には、オペレーション・システムの種類やバージョン、ドライバ、様々な周辺機器の組み合わせ、同時に実行するプログラム、テストを実行する順番や入力タイミングなども影響するため、テストケースは膨大となる。
以上のように、ソフトウェア・テストですべてのテストケースを実行することは不可能であるため、ソフトウェア開発に関係する者は「テストによってすべての問題を発見することは不可能だ」と心得るべきである。
実際におこなわれるソフトウェア・テストは、妥当な費用・時間・資源で、関心のある範囲をなるべく網羅できるよう、様々な種類のテストを組み合わせて問題を発見している。
ここで「関心のある範囲」とは、たとえば、ソフトウェアを出荷するべきか、出荷するならいつが妥当か、プロジェクトを中止するか、プロジェクトを継続するなら開発要員を増やす必要があるか、ソフトウェアが担う役割の範囲を変えるか、ソフトウェアの価格を変えるかなどを判断するための情報である。
なぜ様々な種類のテストを組み合わせるのかといえば、学生の学力試験にたとえると、国語の試験だけを行い、その成績がよければ他の教科の成績もよいだろうと判断せず、なるべく出題範囲全体を網羅するような設問の各教科ごとに試験したほうが、その学生の学力を正確に知ることができるからである。
むろん、学力試験で山を張った一夜漬けの勉強がたまたま出題されて好成績になったり、カンニングをしたりして正しい学力を測定できないことがあるように、ソフトウェア・テストでも不適切なテストや虚偽のテスト結果などでソフトウェアの品質を正しく測定できない場合があるため、そのようなことがないよう、対策を講じる必要がある。
もし、テストによって収集された情報を使う予定がないのなら、費用や時間の無駄となるため、そのテストをするべきではない。
なお、ソフトウェア・テストによって発見された問題はすべて修正されるわけではなく、納期や経営戦略などから重要ではない問題をあえて修正せずにソフトウェアを出荷する場合もある。
なぜなら、問題を修正する過程で新たな問題が作られることもあり、納期が迫っていると修正ミスの頻度も多くなるため、重要ではないなら修正しないほうが妥当と考えられるからである。
どの問題が重要かは顧客や利用者の価値観による。
修正が容易か困難かは基本的に問題の重要性とは関係ない。
部品: テストの分類
ソフトウェア・テストの分類はいくつか種類がある。
開発工程によるテストの分類では、単体テストや結合テスト、総合テスト、受け入れテストなどに分類される。
また、どういった品質を検証するかという観点でテストを分類した場合、機能テスト(functional testing、functional requirement testing)と非機能テストに分けられる。
非機能テストには、性能テスト、負荷テスト、ユーザビリティテスト、セキュリティテスト、保守性テスト、信頼性テスト、移植性テストなどがある。
どのようにテストを実行するかという観点では、動的テストと静的テストに分けられる。
動的テストとは、実際にプログラムを動作させることで問題を見つけるテストである。
それに対し、静的テストとはソフトウェアを構成するソースコードを検証することで問題を見つけるテストである。
知類が要件や設計、ソースコードを目視確認するソフトウェア・レビューは、静的テストである。
また、静的コード解析(static code analysis)や静的プログラム解析(static program analysis)、静的解析などと呼ばれる、機械的にソースコードやオブジェクトコードを解析することも静的テストである。
単にソフトウェア・テストと言った場合、動的テストを指すことが多い。
テストケースを作成する技法で分類した場合、テスト対象を中が見える箱と考えるホワイトボックステストと、テスト対象を中が見えない箱と考えるブラックボックステストに分けられる。
技法による分類では、ホワイトボックステストとブラックボックステスト以外に、プログラムの仕様と内部構造の両方に着目したグレーボックステスト(gray box testing)という分類を追加する場合もある。
グレーボックステストは、ホワイトボックステストとブラックボックステストを組み合わせたテストである。
部品: テスト計画書
ソフトウェア・テストにおいてテスト計画書とは、ひとつひとつのテストに対し、どのようにテストするかを記載した仕様書である。
時間がないプロジェクトマネージャでも概要を理解できるよう、テスト計画書の最初は「なぜこのテスト計画を記載する必要があるのか」「今後はどのような方針でテストを進めていくのか」「どのような品質の製品を出したいのか」など、テスト計画の要約を記載する。
それ以外にテスト計画書に記載すべき内容は、テスト計画に関連する他の仕様書、テスト対象のソフトウェアとそのバージョン、テストするべき機能とテストする必要がない機能、テスト方法、合否の判断基準、テスト要員、スケジュール、承認、テストの終了基準などである。
／＊／
テスト計画に関連する他の仕様書を列挙することで、どのような資料を参考にして立てられた計画なのかが分かる。
／＊／
テストする必要がない機能は重要である。
なぜなら、たとえば、ある既存のライブラリをテストせずに問題が起きた場合、誰に責任があるかを明確になるからである。
そのため、テストする必要がない機能は、ソフトウェア開発プロジェクトの責任者に承認を得る必要がある。
もし、既存のライブラリもテストする場合は、そのための要員や時間・予算を確保しなければならない。
／＊／
テスト方法とは、ホワイトボックステストかブラックボックステストなど、テストの方法を記載する。
文言や動作などのどのような観点・切り口でテストするのか、具体的なテストの操作手順と期待される結果は、テスト設計仕様書と呼ばれる別の仕様書に記載する。
／＊／
テスト計画書に記載するテスト要員とは、誰がテスト計画を管理するか、誰がテストケースを作りテストを実施するか、テストで見つかった問題の原因を誰が特定するかなど、その要員計画を記載する。
テスト担当者に適切な技術がない場合は、テストの技術を身に着けるためのトレーニング計画も記載する。
遅れが出ているソフトウェア開発プロジェクトに要員を追加すると、新入りが新しい環境に慣れたり、資料にまとめられていない暗黙のルールを新入りに教育したりする必要があるため、さらに遅れることになる。
そのため、テスト担当者の要員計画はよく考える必要がある。
／＊／
テストのスケジュールは開発スケジュールに依存する。
そのため、計画を立てた後も定期的にスケジュールを見直す必要がある。
スケジュールを見直す頻度は、たとえば二週間おきなどである。
テストのスケジュールを見直す際、テスト対象のソフトウェアからあとどれぐらいの不具合が見つかりそうか推定できると、妥当性の高いスケジュールを作ることができる。
残存する不具合を推定する方法としては、二チームにテストしてもらう方法がある。
たとえば、XチームとYチームという二つのチームがあり、どちらのチームも同じテストをした場合、Xチームが見つけた不具合がa個、Xチームが見つけた不具合がb個、XとYのどちらも見つけた不具合がc個とすると、そのソフトウェアで見つけられるすべての不具合はa×b÷cと推定することができる。
あるいは、百のテストケースの中から十を試した結果、不具合が五つ見つかったら、百のテストケースで五十見つかるだろうと推定できる。
ただし、推定方法によっては、実際に見つかる不具合よりもかなり低く見積もる場合もあるため、推定方法の特性について理解する必要がある。
／＊／
テスト計画書は承認を得る必要がある。
承認を誰に得るかは組織によって異なる。
正式な承認会議を開く場合もあるが、時間の節約のため、チャットや電子メールで不備や要望がないか関係者に確認をとるだけの場合もある。
／＊／
テストの終了基準は、何によってテストを終えたと判断するかである。
たとえば、重要度「高」の不具合が残っていないこと、重要度「高」の不具合が48時間以内に見つかっていないこと、すべてのテストケースの98パーセントが合格となっていることなどである。
出荷を急ぐ開発責任者が不具合の残ったソフトウェアを詭弁で出荷したりしないようにするため、終了基準には測定できる数値を記載するべきである。
たとえば、「24時間ソフトウェアを稼働させても充分安定していること」という終了基準の場合、何度かハングアップするソフトウェアでも「ハングアップしてもすぐに復旧できる」「24時間中23時間50分は問題なく動作する」と主張して製品を出荷する恐れがある。
製品に不具合があった場合、営業やユーザサポートから非難されるのはテスト担当者であるため、自衛のためにも終了基準の記載には注意すべきである。
部品: レビュー
ソフトウェア・レビュー(software review)とは、静的テストのひとつで、単にレビューとも呼ばれる。
ソフトウェア・レビューは、仕様書や設計書、ソースコードなど、ソフトウェア開発の工程で作成された成果物の内容を確認・検証し、不具合や欠陥などの問題点を発見する作業である。
ソフトウェアの不具合や欠陥は、一般に開発工程の初期に発見したほうが修正に費やす費用や時間が少ないとされている。
ソフトウェア・レビューは、ソースコードを記述する前から実施することができるものもあるため、問題を早く気づくために有用である。
レビューで見つかった不具合や欠陥は、修正し忘れることがないよう、どこにどのような指摘があったか記録される。
不具合や欠陥が修正されているか確認する目的で、すでにレビューした仕様書やソースコードを再度レビューすることもある。
誰がソフトウェア・レビューをおこなうのかという観点から分類すると、机上チェック、ピアレビュー、IV&Vに分けられる。
また、何をレビューするかという観点から分類すると、外部設計書や内部設計書などをレビューするデザインレビュー(design review)と、プログラムのソースコードをレビューするソースコードレビューに分けられる。
デザインレビューでは要件定義書や仕様書などで、要件や仕様の不備・不足に気づきやすい構成になっているかどうかも検証の対象である。
／＊／
机上チェック(desk checking)とは、ソフトウェア・レビューのひとつで、知類が仕様書やソースコードなどを目視確認する検証方法である。
基本的に仕様書やソースコードの作成者本人が確認する。
作成者本人が確認しているため、ピアレビューと比べ、検証の精度は劣るとされている。
机上チェックは、机上検査とも呼ばれる。
／＊／
ソフトウェア開発において、ピアレビュー(peer review)とは、ソフトウェア・レビューのひとつで、作成者の同僚やチームの仲間が成果物を確認する検証方法である。
また、ピアレビューにはチーム内で知識を共有したり、他社の技術を学ぶ側面もある。
ピアレビューには、ソフトウェアを開発する組織内の公式な活動か否か、参加者の人数などによって、コード・レビュー(code review)やソフトウェア・インスペクション(software inspection)など、いくつかの種類に分類される。
余談だが、ソフトウェア開発以外の分野でピアレビューとは、学会誌に学術論文を掲載する際、発表に値する内容か否かを判断するため、同じ分野の研修者にその論文を読んでもらうことである。
／＊／
IV&V(independent verification and validation)とは、第三者による検証のこと、または検証する第三者のこと。
ここでいう第三者とは、ソフトウェアを開発する組織とも、ソフトウェアの開発を委託した組織とも、管理面や財政面で独立した組織のことである。
第三者が静的テストや動的テストをおこなうことで、検証の客観性を保証する。
／＊／
要件のレビューでは、要件定義書に記述された内容に不備や不足がないか、チェックリストを使って検証し、記述されるべき内容が含まれているかを確認することが重要である。
要件はできるだけ緻密かつ精確に検討することが理想である。
一般に、要件は他の開発工程と同様に、荒いものから徐々に完成度を高めていくという工程を経る。
開発の初期段階では、開発に必要な水準まで要件が定まっていなかったり、必要な要件が出し切れていない恐れがあったり、時間不足で検討できずに保留となっているものがあったりすることがある。
このような限界を前提として共有することで、要件を円滑にレビューすることができる。
また、顧客や利用者の業務内容や業務で使う用語について、充分に理解できなかったり、完全には確認できなかったりという限界もある。
そのため、顧客の各業務の担当者を代表として集め、要件定義書の完了レビューをおこなうことが望ましい。
顧客から要件の内容に不備がないことを確認してもらったら、承認を得たことを署名捺印など法的効力がある形で記録に残すとよい。
／＊／
外部設計のレビューでは、外部設計書に記述された内容が要件定義書の記述と矛盾していないか、整合性がとれているかを検証する。
矛盾がある場合はなぜ矛盾しているのか、その理由が明記されていること、および関係者から了解を得ていることを確認する。
また、外部設計として記述すべき入出力や外部インターフェースが不備なく規定されており、論理関係が矛盾していないことも検証する。
内部設計のレビューも同様に、内部設計書の記述内容が要件定義書や外部設計書の記述と矛盾がないことを確認する。
内部設計では、どのようにプログラムを実装するのか、具体的なアルゴリズムが充分に明記されていることもレビューで確認する。
処理すべきデータがない場合はどのような処理になるのか、各種データの初期値なども、内部設計のレビューで確認すべき項目である。
／＊／
ソースコードレビューでは、コーディング規約に沿って記述されているか、内部設計書に記述された機能やデータ形式がプログラム上で正しく実現しているか、保守や再利用が容易なコードとなっているかを確認する。
また、ソースコードにコメントが記載されている場合、そのコメントが有意義か否か、コメント内容の正確さも確認する。
ソースコードを理解できないとレビューできないため、レビューに参加する者はプログラミングの基本的な知識に加え、使用するプログラミング言語の知識も有する必要がある。
ソースコードレビューで問題が見つかった箇所を記録し、分析することで問題が起こりやすい箇所が明らかになる。
分析結果をプログラミング時の注意点やコーディング規約に反映することで、ソフトウェアの品質向上につながる。
／＊／
ソフトウェア開発の関係者で「レビューができない」「レビューをするべきでない」と主張する場合、その者の思考様式や開発組織の文化に問題があると考えられるため、メタテストとしてその主張の理由を確認し、妥当でない場合は正したほうがよい。
たとえば「プログラマ以外が設計書を見ても問題を見つけられない」という主張には「プログラマ以外でも誤字脱字や論理的な誤りは指摘できる」と反論できる。
／＊／
前工程で見つかるべき不備や不具合が後工程で見つかった場合、レビューやテストに不備があったと考えられる。
たとえば、要件のレビューで見つかるべき不備が、外部設計や内部設計のレビューで見つかった場合である。
このようにレビューが正しく機能していない場合、レビューのチェックリストに確認項目を追加・修正したほうがよい。
このチェックリストはソフトウェア開発をおこなう組織にとって知的財産であり、他のソフトウェアやシステムを開発する際も継承することが望ましい。
ただし、案件によって妥当でない確認項目については、責任者の承認を得て確認を省略してもよい。
また項目数が膨大になると確認が形骸化する恐れがあるため、定期的にチェックリストを見直し、不要な確認項目は削除することも検討したほうがよい。
部品: 非機能テスト
非機能テスト(non-functional testing)とは、ソフトウェアの非機能要件に関するテストのことである。
非機能テストには、ドキュメンテーションテスト、性能テスト、負荷テスト、ユーザビリティテスト、セキュリティテスト、保守性テスト、信頼性テスト、移植性テストなどがある。
非機能テストは、非機能要件テスト(non-functional requirement testing)とも呼ばれる。
／＊／
ドキュメンテーションテストとは、非機能テストのひとつで、ソフトウェアのマニュアルに不備がないか検証するテストである。
マニュアルとは、取り扱い説明書のことである。
マニュアルに記載されている操作手順に誤字脱字や順番の入れ違いがないか、記載された操作手順の通りに操作して意図した通りに動作するか、マニュアルの構成やレイアウトなどに問題がないかをドキュメンテーションテストで確認する。
／＊／
性能テストとは、非機能テストのひとつで、想定された状況でソフトウェアの性能が期待された通りに出ているか検証するテストである。
性能が期待通りとは、ソフトウェアを企画もしくは設計する段階で設定した性能を満たしているかということである。
性能の定義は具体的な数値におこなう。
たとえば「10分以内に300メガバイトのデータを処理する」や「決定ボタンを押して3秒以内に処理が終わる」などである。
性能要件が「300メガバイトのデータを10分以内に処理する」でも、1メガバイトのデータを処理するのに10分近くかかったり、301メガバイトのデータを処理するのに30分かかったりする場合は性能の問題として扱うべきである。
性能テストで見つかる不具合は最悪の場合、最初の設計からやり直すことになる。
そのため、ある程度プログラムが動くようになった時点で、定期的に性能テストを実行することが望ましい。
性能テストはパフォーマンステスト(performance test)とも呼ばれている。
／＊／
負荷テストとは、非機能テストのひとつで、負荷を与えた場合の動作を検証するテストである。
ライブやコンサートのチケットの予約システムのように複数名が同時にアクセスするシステムでは、何かの契機に利用が集中する恐れがある。
そのため、システムに負荷がかかっている状態での動作を確認しておく必要がある。
負荷テストをおこなうには実際に複数名が同時にアクセスするという方法もあるが、テストに必要な負荷が大きい場合、実施するテスト担当者やテスト用端末の確保が難しくなる。
そのため、一連の操作を自動でおこなうシミュレータを用意して負荷テストする場合もある。
一連の操作とは、コンサートのチケットの予約システムなら、コンサートを検索し、予約を入れ、決済するという操作である。
負荷テストの分類にはロードテストやストレステストなどに分けられる。
ロードテスト(load testing)とは、通常時やピーク時に想定される負荷をかけた場合の負荷テストである。
特にピーク時に想定される負荷をかけた場合の負荷テストをピークロードテスト(peak load testing)と呼ぶ。
ストレステスト(stress testing)とは、想定の上限を超えた場合の動作を検証するテストである。
たとえばコンサートのチケットの予約システムで高負荷をかけた場合、決済は済んでいるが予約が保存されていない場合、チケットを入手できなかった利用者から損害賠償を請求される恐れがある。
このような事態を防ぐため、高負荷で正常にシステムが正常に動作しない場合の動作を確認しておく必要がある。
／＊／
ユーザビリティテストとは、非機能テストのひとつで、開発した製品を実際に利用者に使ってもらうことで使い勝手や好みなどを確認するテストである。
種族や年齢層、職業、性別など、利用者によって使い方が異なる場合、それぞれの利用者に使ってもらうことが望ましい。
たとえば、大人と子供で使い方が異なると予想され、ユーザビリティテストに十名テストもらうなら、大人の利用者と子供の利用者を五名ずつにテストしてもらうなどである。
／＊／
セキュリティテストとは、非機能テストのひとつで、ソフトウェアが悪意ある者の攻撃に耐えうるかを検証するテストである。
個人情報が保存されているシステムから情報が流出したり、課金要素のあるゲームでプレイヤーのデータが復旧できないよう削除されたりした場合、企業の信用を失う事態になる。
そのため、ソフトウェアのセキュリティは非常に重要である。
セキュリティの問題は年々進歩し、高度となっているため、セキュリティテストをおこなうテスト担当者は日々、新しいセキュリティ技術を学び、新しいセキュリティ攻撃の手法を迅速に理解する必要がある。
部品: ホワイトボックステスト
ホワイトボックステスト(white-box testing)とは、プログラムの論理構造が正しいか否かを解析するためのテストである。
そのため、プログラムの内部構造がわかっていることがテストの前提である。
ホワイトボックステストは主に単体試験で採用されているテストである。
ホワイトボックステストは、クリアボックステスト(clear box testing)、グラスボックステスト(glass box testing)、透明ボックステスト(transparent box testing)、構造テスト(structural testing)などとも呼ばれる。
／＊／
制御パステストとはホワイトボックステストの主要な技法のひとつで、プログラムがどのような振る舞いをし、どのように制御され、どのように実行していくかをテストするものである。
制御パスとは命令や条件分岐などの組み合わせのことである。
プログラムの規模が大きくなると、制御パスは天文学的な数となるため、いくつかの網羅基準でテストする量を限定して実施される。
／＊／
網羅基準(coverage criteria)とは、テスト・カバレッジを算出する際、どれくらい細かくテストするかという基準である。
網羅基準はカバレッジ基準とも呼ばれる。
／＊／
テスト・カバレッジ(test coverage)とは、テスト対象となるソフトウェア全体のうち、テストを終えた、あるいはテストしようとしている箇所の割合のことである。
テスト・カバレッジは通常、パーセントの単位で数値によって表現される。
自動車や飛行機のような事故があった際、命に関わるようなものに使われるソフトウェアに関しては、限りなく100パーセントに近いテスト・カバレッジを要求される。
そうではない一般的なソフトウェアの場合、テスト・カバレッジはソフトウェアの対象によって異なるが、だいたい60パーセントから90パーセントまでが妥当とされている。
テスト・カバレッジには、プログラムのソースコードをどれだけテストしたかを示すコード・カバレッジや、仕様書や要件に対するどれだけテストしたかを示す仕様カバレッジ(要件カバレッジ)など、いくつか種類がある。
テスト・カバレッジは網羅率や被覆率とも呼ばれる。
／＊／
コード・カバレッジ(code coverage)とは、テストの対象となるプログラムのソースコード全体の中で、テストを終えた、あるいはテストしようとしている箇所の割合のことである。
コード・カバレッジはコード網羅率やコード被覆率とも呼ばれる。
コード・カバレッジはテスト・カバレッジの中で最も代表的なテスト指標である。
／＊／
行カバレッジ(line coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべてのコード行を少なくとも一回実行するよう、テストケースを用意するものである。
言い換えると、すべてのコード行を少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準が行カバレッジである。
／＊／
関数カバレッジ(function coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての関数を少なくとも一回実行するよう、テストケースを用意するものである。
言い換えると、すべての関数を少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準が関数カバレッジである。
／＊／
コール・カバレッジ(call coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての関数呼び出しを少なくとも一回実行するよう、テストケースを用意するものである。
言い換えると、すべての関数呼び出しを少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準がコール・カバレッジである。
／＊／
ステートメント・カバレッジ(statement coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのコード内の命令文(statement)を少なくとも一回実行するよう、テストケースを用意するものである。
ステートメント・カバレッジは、命令網羅や命令文網羅、C0カバレッジとも呼ばれる。
一般にプログラムは命令よりも分岐による問題が多いため、テスト手法としてステートメント・カバレッジはあまり有用ではない。
／＊／
ブランチ・カバレッジ(branch coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての分岐においてすべての分岐の方向を少なくとも一回実行するよう、テストケースを用意するものである。
たとえるなら「水曜日に女性客は割引」という条件に対し、割引になる場合と割引にならない場合の両方の結果を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。
プログラム上の分岐個所をソースコードから目視で確認するのは大変であるため、通常、フローチャートやフローグラフと呼ばれる図法で図示して分岐箇所や条件を確認することが多い。
ブランチ・カバレッジはステートメント・カバレッジと比べ、多くの問題を発見することができるが、テストケースの数が膨大となるため、構造が複雑で多くの問題が見つかりそうな箇所に限定してテストすると費用・時間の面で効率がよい。
ブランチ・カバレッジは、分岐網羅や判定条件網羅、ディシジョン・カバレッジ(decision coverage)、C1カバレッジとも呼ばれる。
／＊／
コンディション・カバレッジ(condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての開始と終了、および条件文の可能なすべての結果を少なくとも一回実行するよう、テストケースを用意するものである。
たとえるなら「水曜日に女性客は割引」という条件に対し、水曜の場合と水曜以外の場合、および女性の場合と女性以外の場合を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。
ステートメント・カバレッジやブランチ・カバレッジよりもテストケースが多くなりやすいカバレッジ基準である。
ただし、コンディション・カバレッジは分岐の方向を考慮しないため、コンディション・カバレッジでテスト・カバレッジが100パーセントになるテストケースでも、ステートメント・カバレッジやブランチ・カバレッジではテスト・カバレッジが100パーセント未満になる場合もある。
コンディション・カバレッジは、条件網羅や条件カバレッジ、C2カバレッジとも呼ばれる。
／＊／
ディシジョン/コンディション・カバレッジ(decision/condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、ブランチ・カバレッジとコンディション・カバレッジを合わせたものである。
たとえるなら「水曜日に女性客は割引」という条件に対し、水曜の場合と水曜以外の場合、女性の場合と女性以外の場合、および割引になる場合と割引にならない場合を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。
ディシジョン/コンディション・カバレッジは、判定条件/条件カバレッジや判定条件/条件網羅とも呼ばれる。
／＊／
複合条件網羅(multiple condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての判定において、あり得るすべての結果の組み合せが少なくとも一回実行するよう、テストケースを用意するものである。
たとえるなら「水曜日に女性客は割引」という条件に対し、水曜かつ女性の場合、水曜以外かつ女性の場合、水曜かつ女性以外の場合、水曜以外かつ女性以外の場合の四パターンを確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。
／＊／
パス・カバレッジ(path coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムにあり得るすべての制御パス少なくとも確認するよう、テストケースを用意するものである。
一般的な規模のソフトウェアでもテストケースが膨大となるため、そのすべてをテストすることは現実的ではない。
パス・カバレッジは、経路組み合わせカバレッジや経路組み合わせ網羅、C∞カバレッジとも呼ばれる。
／＊／
ループ・カバレッジ(loop coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムにあるすべてのループで、一度もループしない場合、一度ループした場合、複数回ループした場合をそれぞれ少なくとも一回ずつ実行するよう、テストケースを用意するものである。
ループとは繰り返し処理のことである。
ループによるソフトウェアの問題を見つけるためには、複数回ループした場合をより細かく場合分けするテスト戦略もある。
たとえば、もっとも典型的な回数ループした場合、想定する最大回数より一回少なくループした場合、想定する最大回数ループした場合、想定する最大回数より一回多くループした場合などに場合分けするテスト戦略である。
／＊／
制御パステストは、要求仕様あるいは開発者の意図通りにプログラムが実装されているかを検証するものである。
そのため、要求仕様や開発者の意図が誤っていた場合、制御パステストで問題を発見することはできない。
ここで開発者の意図とは、開発者が要求仕様をどのように解釈したかであり、要求仕様そのものではない。
また、本来あるべき機能がまるごとない場合も制御パステストで発見することは難しい。
マルチヤスクや割り込みによる問題も制御パステストでは発見困難である。
テスト・カバレッジを100パーセントに近づけるほど、テストにかかる費用や時間が等比級数的に増加するという問題もある。
ホワイトボックステストは数あるテスト技法のひとつであり、苦手な問題もあるため、そのソフトウェアにとって妥当なテスト・カバレッジを目標として設定することが重要である。
部品: ブラックボックステスト
ブラックボックステスト(black-box testing)とは、プログラムの入出力の対応関係だけを注目し、プログラムが仕様通りに動作しているか否かを検証する手法である。
そのため、プログラムの満たすべき品質が仕様となっていることが前提である。
仕様があいまいな場合、ブラックボックステストをする前に、プログラムがどのような振る舞いをするべきか、仕様を明確にする必要がある。
なお、ブラックボックステストをするうえで、プログラムの内部構造がわかっている必要はない。
ブラックボックステストには、同値分割や境界値分析などがある。
／＊／
同値分割(equivalence partitioning、equivalence class partitioning)とは、ブラックボックステストのひとつである。
同値分割とは、入力値を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす技法である。
たとえば、それぞれ1から99までの数値が入力できる二つの入力欄XとYがある場合、有効同値クラスと無効同値クラスの二つの部分集合に分ける。
有効同値とはプログラムが期待する入力値のことである。
上記の例では、XとYはどちらも1から99までの数値を入力することを期待しているため、有効同値は1から99までである。
無効同値はそれ以外のすべての値である。
XとYをそれぞれ1未満の場合、1以上99以下の場合、99を超過する場合の三つに分けると3通り×3通りで9通りのテストケースができる。
さらに0はゼロ除算(division by zero)や無限ループなどエラーの原因となりやすいため、XとYの両方が0のテストケースも追加すると、計10通りのテストケースとなる。
十通りのテストケースの具体的な値を例示すると、(X=-1,Y=-1)、(X=-1,Y=50)、(X=-1,Y=100)、(X=50,Y=-1)、(X=50,Y=50)、(X=50,Y=100)、(X=100,Y=-1)、(X=100,Y=50)、(X=100,Y=100)、(X=0,Y=0)である。
有効同値は1から99までであるため、(X=50,Y=50)を(X=1,Y=1)や(X=99,Y=99)にしてもよい。
同様に(X=-1,Y=-1)を(X=-100,Y=-100)にしたり、(X=100,Y=100)を(X=999,Y=999)にしてもよい。
上記の例では、有効同値一つに対し、無効同値が九つではテストケースが膨大となる。
そのため、実際のテストでは、なるべく不具合を見逃さないように無効同値のテストケースを減らす必要がある。
たとえば、(X=-1,Y=-1)、(X=-1,Y=50)、(X=-1,Y=100)の三つのテストケースはいずれもXが1未満の場合のテストであるため、一つに減らす。
同様に、(X=-1,Y=100)、(X=50,Y=100)、(X=100,Y=100)の三つのテストケースはいずれもYが99を超過する場合のテストであるため、一つに減らす。
このように、他のテストケースでテストしていないもののみを残して、テストケースを減らすことで、不具合を見逃す恐れを減らしつつ、テストの時間と費用を節約できる。
／＊／
境界値分析(boundary value analysis)とは、ブラックボックステストのひとつで、境界値近くを詳しくテストする技法である。
境界値とは、無効同値と有効同値の間の値や、ある有効同値と別の有効同値の間の値などである。
プログラムの不具合は、境界値付近に潜んでいることが多い。
たとえば、仕様では「1以上」となっているところを誤って「1より大きい」と設定してしまったり、「99以下」とするべきところを「99未満」と設定してしまったりすることがありうる。
そのため、たとえば有効な値が「10以上20以下」なら、有効な値の上限(20)と下限(10)に加え、有効な値の上限に近い無効な値(21)、有効な値の下限に近い無効な値(9)をテストする。
さらに、有効な値の中央(15)と、エラーの原因となりやすい0を加えるとテストケースは6通りとなる。
上記はプログラムが単純な場合の例であったが、実際のプログラムではデータが複雑に絡み合い、テストケースを網羅することが時間的制約やテスト担当者のスキルの面で難しいケースがある。
その場合、良いデータと悪いデータを必ずテストするようにする。
ここでいう良いデータとは、利用者がよく使いそうな値、有効な値の上限と下限である。
また、悪いデータとは、-999999や0.0000001のような極端に小さいデータ、999999のような極端に大きいデータ、abcdefghijklmnopqrstuのような非常に長いデータ、無効な値などである。
0は良いデータであるか、悪いデータであるかに関わらず、入力できる場合、必ずテストしたほうがよい。
境界値分析は、限界値分析とも呼ばれる。
／＊／
原因結果グラフとは、プログラムに対する入力条件と、入力に対応するプログラムの動作を図示したグラフのことである。
原因結果グラフは、原因効果グラフ、CEG(cause-effect graph)とも呼ばれる。
／＊／
デシジョンテーブル(decision table)とは、テスト対象プログラムの入力条件や入力データと、その結果の動作や処理を表にまとめたものである。
表形式になっているため、文章で羅列されているよりも分かりやすく、どのテストをおこなったかも記録しやすい。
デシジョンテーブルは、決定表とも呼ばれる。
／＊／
原因結果グラフ技法(cause-effect graphing technique)とは、原因結果グラフとデシジョンテーブルを使って、有効なテストケースを抽出する方法である。
仕様から原因結果グラフを作成し、完成したグラフをディシジョンテーブルに変換する。
原因結果グラフをディシジョンテーブルに変換することは難しいため、自動変換ツールで変換することが多い。
／＊／
状態遷移テスト(state transition testing)とは、ブラックボックステストのひとつで、テスト対象プログラムがどのような状態を持ち、どのような条件やイベントで、他の状態に遷移するかを検証するテストである。
たとえば、入力待ちの状態で入力された場合、処理中の状態に遷移するかを検証するものが状態遷移テストである。
状態遷移テストにより、期待しない状態に遷移する不具合や、遷移自体が起こらない不具合を見つけることができる。
状態遷移の図表で表現する方法として、ステートマシン図(state machine diagram)などの状態遷移図(state diagram、state transition diagram)や、状態遷移表(state transition table)などがある。
ステートマシン図は状態マシン図とも呼ばれる。
／＊／
ランダムテスト(random testing)とは、事前にテストケースを考えず、行き当たりばったりに入力や操作をおこなうテスト手法である。
ランダムテストは、事前に同値を分割したり、境界値を分析したりする必要がない、荒っぽい方法であるが、このテスト方法でもかなりの数の不具合を見つけられる場合がある。
セキュリティテストでは、ファズテスト(fuzz testing)やファジング(fuzzing)と呼ばれるランダムテストが用いられている。
ファズ(fuzz)とは、予測が困難な入力データのことである。
ただし、同値分割や境界値分析などの方法でなければ、見つけにくい不具合もあるため、セキュリティテスト以外ではランダムテストは推奨されていない。
ランダムテストは、アドホックテスト(ad hoc testing)、ゲリラテスト(guerrilla testing)、モンキーテスト(monkey testing)などとも呼ばれる。
／＊／
エラー推測(error guessing)とは、ブラックボックステストのひとつで、経験から知られている不具合が起こりやすいパターンからテストケースを作る方法である。
たとえば、0やnull、ヌル文字、空文字列などはエラーが起きやすいデータのため、テストしたほうがよい。
数値を入力する箇所では小数や指数もエラーが起きやすいデータである。
エラー推測は、テスト担当者の知識や経験、想像力、洞察力に左右されるが、同値分割や境界値分析などで見つけられない不具合を検出することもある。
そのため、エラー推測は、同値分割や境界値分析など併用が有効である。
部品: 探索的テスト
探索的テスト(exploratory testing)とは、ソフトウェア・テストの方法のひとつ。
記述的テストと呼ばれる伝統的なソフトウェア・テストでは、事前に文書で定義したテストケースを順番にテストする。
そのため、テストケースを記述することに時間がかかり、テストを実行する時間が削られるという問題があった。
探索的テストではテストケースを書くことを重視せず、テスト対象となるソフトウェアについて学習し、事前・直前のテスト結果やテスト時のソフトウェアの振る舞いから臨機応変にテストするものである。
ここでいう学習とはソフトウェアを実際に動かして学ぶだけではなく、仕様書やソースコードを読んだり、既存のテスト結果を確認したり、ソフトウェアの開発者と対話することも含まれる。
探索的テストの具体的な手順としては、まず何がテストの合否を決めるか、その判断基準を決める。
次にテスト対象となるソフトウェアからテストすべき機能を列挙する。
テストすべき機能のリストアップが終わったら、危なそうな機能や操作などを列挙する。
こうしてリストアップされた機能や操作に対し、臨機応変にテストし、判断基準に照らし合わせ、不具合か否かを確認する。
上記のような探索的テストを複数回おこなう場合、工夫を加えることでさらに不具合の発見を増やすことができる。
たとえば、テスト担当者が複数いるならお互いのテスト担当範囲を交換したり、複数の環境で動作するソフトウェアなら環境を変えてテストするなどである。
ただし、ユーザビリティテスト以外の非機能テスト、たとえば性能テストや負荷テスト、セキュリティテストなどでは、探索的テストはテストケースを記述するテストと比べ、あまり不具合を見つけられないという欠点がある。
テスト対象となるソフトウェアについてよく知っているテスト担当者が利用者の視点でテストをすることが探索的テストといえるため、ユーザビリティテストでは記述テストと比べ、多くの不具合を見つけやすい。
探索的テストは、もともとアドホックテストと呼ばれていたが、アドホックテストがランダムテストを意味するようになったため、探索的テスト、あるいは探索型テストと呼ばれるようになった。
部品: 単体テスト・結合テスト
単体テストとは、関数や手続きなどの最小単位(モジュール)でプログラムを動作して内部設計通りに動作するか検証する工程である。
ソフトウェアは規模が大きくなると、指数関数的に複雑になるため、問題が起きている箇所を特定することが難しくなる。
そのため、できるだけ狭い範囲に絞って検証することで必要な労力を抑えることができる。
単体テストはこの原理に沿ったテストである。
単体テストは、ユニットテスト(unit testing)、モジュールテスト(module testing)、単体試験とも呼ばれる。
／＊／
結合テスト(integration testing)とは、複数のモジュールを結合して動作を検証する工程である。
結合テストの主な目的は、モジュールとモジュールの間でインターフェイスやデータの受け渡しが、外部設計通りに動作しているか検証することである。
単体テストがひとつひとつのモジュールが正常に動作しているかコンポーネントの細部を検証しているのに対し、結合テストはコンポーネント間の細部を検証している。
何をテストしているかが異なるため、単体テストと結合テストのどちらか一方を省略することはできない。
建築にたとえるなら、単体テストは建築材料の品質を検証しているのに対し、結合テストは建築材料で作られた壁や床を検証している。
建築材料の強度が基準に満たない場合も、水平になるよう設計された床が斜めに傾いている場合も、どちらも建築物として適切ではない。
ただし、ソフトウェア開発において、単体テストの範囲が広い場合、単体テストと結合テストの区別が難しいこともある。
結合テストはI&T(integration and testing)、結合試験とも呼ばれる。
また、粒度や目的に応じて、モジュール結合テスト、機能結合テスト、サブシステム結合テストなどと呼び分けられることもある。
／＊／
総合テストとは、定められた環境で要件定義や外部設計の内容を実現できているか否かを総合的に検証するテストである。
結合テストで外部設計の内容を満たしていることを確認したプログラムを、そのプログラムするハードウェアやネットワーク、利用者端末など、本番と同じ環境を用いて検証する。
本番と同じ環境を用意できない場合、本番に近い環境で総合テストを行う場合もある。
総合テストで検証する項目は大きく機能要件と非機能要件に分けられる。
また、総合テストでは仕様で想定していない状況や利用者の誤操作などを踏まえてシステムの不備を検証することもある。
総合テストは、システムテスト(system testing)とも呼ばれる。
／＊／
受け入れテストとは、作られたプログラムが業務に使えるかを検証するためのテストである。
単体テストや結合テスト、総合テストなどが開発者側がおこなうテストであるのに対し、受け入れテストは利用者や購入者が主体となって検証する。
また、下請けから納品された成果物を元請けが検収することを受け入れテストと呼ぶ場合もある。
受け入れテストは、受け入れ試験、検収テスト、承認テスト、OAT(operational acceptance testing)、ORT(operational readiness testing)、OR&A(operations readiness and assurance testing)などとも呼ばれる。
また、業務部門の利用者やシステム管理者など、誰が承認にするのかによって、ユーザー受け入れテスト、運用受け入れテストなどに分類される。
部品: メタテストとは
メタテストとは、テストをテストすることである。
メタテストはコンピュータでソフトウェアを実行したり、ソースコードを見直したりしなくても実行できる。
たとえば、仕様書のような重要な書類がどこにあるか分からず、いつ仕様書を見つけられるか見通しも立たない場合、その組織の開発工程に問題があることは容易に想像できる。
また、進捗の遅れているコードほどテストしないような開発工程は、綿密にテストすべきコードほどテストしていないため、開発工程に問題があると考えられる。
あるいは、プログラムに不具合があると担当した開発者に罰則を与えたり、不具合を見つけたテスト担当者や不具合をすぐに修正した開発者に恩賞を与えたりすると、罰則を恐れて不具合を隠蔽したり、恩賞を得るためテスト担当者と開発者が結託して意図的に不具合を作ったり、不具合の発見した時期を偽ったりするなどの弊害が考えられる。
上司や顧客に対し、進捗が実際よりも良いよう見せるため、発見した不具合の数や重要度の記録を改ざんすることが常態化している場合、その開発組織の文化に問題があると考えられる。
このように「ソフトウェア開発で取り扱っている情報の質」に関する情報を知り、適切に使うことで、開発やテストの効率を大幅に改善し、費用や時間を節約することができる。
そのため、テスト結果の報告書に重要な情報がすべて記載されていると思わず、どのようにテストが実施され、その裏で何があるか直接観察して検証することが望ましい。
なぜなら、テストの手順を文書に明記してあったとしても、必ずしもテスト担当者がその内容を守っているとは限らないからである。
特にテスト結果の報告書に記載されているデータが整いすぎている場合、虚偽のテスト結果ではないか疑ったほうがよい。
ただし、開発者やテスト担当者を過度にテストすることは開発工程に悪影響を及ぼす恐れがあるため、適切な範囲でおこなうことが望ましい。
部品: ドッグフードテスト
ドッグフードテストとは、開発した製品を開発者自身が実際に使用するテストである。
ドッグフードテストは、ドッグフーディング(dogfooding)とも呼ばれている。
ドッグフードテストの目的は、開発した製品に対し、開発者がどの程度自身があるかを確かめるためである。
たとえば、自動車のステアリングとブレーキ制御に関する組込みソフトを作った場合、その製品を搭載した車両に開発者を運転手として乗せ、テストコースで実際に走行してもらう。
もし、開発した製品に自信がないのなら、あまり速度を出さなかったり、すぐに運転をやめたりするはずである。
開発者によっては向こう見ずだったり、臆病だったりするため、ドッグフードテストのみで製品の良否を確かめるのは不適切だが、メタテストの出発点としては有用である。
なお、ドッグフードテストの名前は、一説によると「人知類が犬知類の食糧を作るなら、まず作った本人が食べろ」という故事に由来するとされている。
部品: 獲得時間
ソフトウェア開発において、獲得時間とは、要件定義書や仕様書のレビューによって見つかった不備・欠陥・不具合などの数から算出した、失わずに済んだ時間である。
たとえば、仕様書をレビューし、50個の欠陥が見つかったとする。
もしプログラムを実装後に欠陥を直した場合、ひとつの欠陥を直すのに平均で4時間かかるとすると、すべての欠陥を修正するのにおよそ200時間かかる。
仮にレビューが40時間で終わったのなら、差し引き160時間を失わずに済んだことになる。
このように獲得時間という数値で計測することで、レビューの効果を目に見える形にすることができる。
なお、獲得時間を計算する際、レビューによって仕様書が適切な体裁や内容になることにより、ソースコードから仕様を確認する手間が省ける時間は考慮しない。
インポート用定義データ
[
{
"title": "ソフトウェア開発工程",
"part_type": "group",
"children": [
{
"title": "上流工程（ソフトウェア開発）",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "RFP・要件定義",
"part_type": "group",
"children": [
{
"title": "RFP・提案書",
"description": "RFPとは、Request For Proposalの略で、提案依頼書のこと。\n提案依頼書とは、情報システムの導入・構築や業務委託をおこなうにあたり、開発を依頼する発注元(発注者)が具体的な提案を依頼するために、発注先候補の事業者に交付する文書のことである。\n業種・業態・組織・提供する製品やサービスといった発注元の基本情報、なぜシステムやサービスを導入するのかといった導入の背景、システム開発やサービス導入にどのような便益を期待しているかといった目的、どのような部門のどのような業務の者がだいたい何名ぐらい使用するのか、各機能やサービスはそれぞれいつまでにどのようなスケジュール・どれくらいの予算で完成させたいかといった調達条件などといったことがRFPに書かれている。\nRFPの目的は、提案内容と見積もりから最も適した発注先(受注者)を選ぶことである。\nRFPは、発注元が発注先の事情や技術上の制約を気にせずに自身の要望を書いているため、開発を請け負う側はRFPから本当に欲しいものはなんなのかを見抜くことが重要である。\n／＊／\nシステム提案書とは、RFPに対する回答として、発注先から発注元に提出される資料のこと。\nRFPに対する回答は、特に訂正・削除がない場合、そのまま要件として扱われる場合もある。\nそのため、RFPに記載された、発注元の誤った認識による不適切な実現方法に対し、発注先は妥当な代替手段を検討する必要がある。\nそのうえで、どこまでの範囲の業務を開発するシステムで対応するか、発注元と発注先で開発の役割や責任をどのように分担するか、開発に関する報告や会議の頻度・スケジュール、利用者にシステムの使い方を教育する必要があるかなどといったことを発注先は記載する。\n発注元の責任で仕事が遅れたり、仕様が変更になったりした場合、開発方法やスケジュールの変更を提案・相談できるよう、発注先はシステム提案書に注意書きをしておいたほうがよい。\nシステム提案書は単に提案書とも呼ばれる。",
"part_type": "part",
"localID": 3
},
{
"title": "要求仕様書・要件定義書",
"description": "要求仕様書とは、発注元(発注者)が何をしたいのかという希望を、システム開発として実現して欲しい機能に落とし込んで書いたものである。\nRFPとは異なり、要求仕様書には調達条件は書かれていない。\n／＊／\n要件定義書は、要求仕様書に書かれた要望を実現するためにはどのようなシステムが必要か、機能要件・非機能要件などを発注先(受注者)が書いたものである。\nここでいう要件とは、必要な条件のことである。\n要件定義書は、オペレーティングシステムやミドルウェアの選定を含まれ、提案書よりも具体的である。\n要件は、そのシステムを作る背景や機能など、その時点でできる限り定量的に記述することが望ましい。\nただし、根拠のない数値は危険なため、書くべきでない。\nまた、要件は、その機能の及ぶ範囲が把握できるよう、適切に表現することが望ましい。\nたとえば、「計測データが正常でなければ知らせる」と「計測データを表示中、重要な変化があった場合、画面に警告を表示する」のふたつの表現では、書き手が同じことを考えて書いたとしても、読み手の印象は大きく異なる。\n同様に「印刷できない状況になった場合、担当者に知らせる」と「印刷途中で用紙やインクが不足するとわかった時点で、登録されている担当者に電子メールで知らせる」のふたつの表現でも、前者より後者のほうが、その機能がどのように動作してほしいか、その機能の及ぶ範囲がどこまでかが分かりやすい。\n要件が複雑であったり、範囲が広い場合、ふたつの階層に分けて表現する。\nたとえば、一階層目を「印刷途中で用紙やインクが不足するとわかった時点で、登録されている担当者に電子メールで知らせる」と簡潔に表現して要件の範囲を把握する。\nそして、二階層目を「印刷中に用紙とインクの残量の情報を得る」「用紙の使用予定量と残量を比較し、用紙が不足しないか確かめる」「インクの使用予定量と残量を比較し、インクが不足しないか確かめる」「定型文からメール本文を作成する」「データベースから担当者のメールアドレスを得る」「電子メールを送信する」などとすれば、どのような機能を実装しなければならないかが具体的に分かるようになる。\nひとつの要件を階層化する際、三階層以上にしなければ分かりにくい場合、要件そのものの範囲が広すぎるため、ふたつ以上の要件に分割したほうがよい。\n要件定義書に記載がない場合、しないことなのか、するかどうか決まっていないことなのか、あいまいとなるため、しないと決めたことについても明記するべきである。\n要件を不採用にすることが妥当か確認できるようにするため、不採用にした根拠や理由も明記したほうがよい。\n要件定義書の内容と直接関係ないが、文章の読みやすさも品質のひとつであるため、使用する文体や表記、用字・用語は統一したほうが良い。\nまた、表現にも気をつけたほうがよい。\nたとえば「処理を1秒以内に終えるべき」という表現だと「処理を1秒以内に終えること」が要件なのか、努力目標なのか解釈が分かれ、問題になる恐れがある。\n上記のように、要件定義書の内容で考慮すべき点は多岐にわたるため、要件の抜け・漏れなどの不備がないよう、確認・検証が必要である。\n概算の相見積もりの際、発注元は当初予定していたが要求が過不足なく満たされているか、要求仕様書と要件定義書を見比べ、吟味することが重要である。\n必要以上に高度な機能で無駄な費用が要求されていたり、必要な機能が盛り込まれていなかったりした場合、発注元は発注先に要件定義書の記載内容を改めるよう求めることが望ましい。\nなお、相見積もりとは、複数の事業者から見積書を提出してもらい、品質・価格・納期などを比較・検討することである。\n／＊／\n余談だが、要求と要件は英語ではどちらもrequirementと表記する。\n要求と要件を混同する場合は「顧客の」「システムの」を前につけるとよい。\n「顧客の要求」という表現はあるが、「システムの要求」という表現は適切ではない。\n同様に「システムの要件」という表現はあるが、「顧客の要件」という表現は適切ではない。\nなお、ソフトウェア開発における要求・要件であることを明確にするため、ソフトウェア要求(software requirements)、ソフトウェア要件と表記する場合もある。",
"part_type": "part",
"localID": 4
},
{
"title": "ドメイン知識",
"description": "ドメイン(domain)とは、分野や領域を指す。\nドメイン知識(domain knowledge)とは、ある分野の専門家がもつその分野固有の知識である。\nドメイン知識を得る方法には、その分野・領域の実務者やアナリストに尋ねたり、実際に対象の業務に参加するなどがある。\nドメイン知識はシステムやソフトウェアの開発において重要である。\nたとえば、流通を管理するソフトウェアを作成する場合、流通の専門知識が必要になる。\nまた、カーナビゲーションシステムを開発する場合、GPS(Global Positioning System)やGIS(Geographic Information System)、およびそれらに関連する規格・方式などの知識が必要になる。\n素粒子分野と核物理分野で、核子のアイソスピンの定義が符号が逆になっているように、業界や業種によって同じ内容を異なる表現を用いている場合もある。\nそのため、要件定義書を作成する際、発注元と発注先の間で要件の理解に齟齬がないよう、用語の意味を定義した辞書を作成することが望ましい。\nまた、システムやソフトウェアの開発で用語を使用する際、その用語の定義や表現が適切か、その妥当性を検証することも重要である。\nドメイン知識は、領域知識や領域固有知識とも呼ばれる。",
"part_type": "part",
"localID": 5
},
{
"title": "システム導入の目的",
"description": "システム導入の目的とは、発注元がRFPや要求仕様書に記載する内容のひとつである。\nたとえば、「生産性向上」「コスト削減」「顧客満足度向上」など、組織の経営に役立つか、利用者の便益に寄与するものがシステム導入の目的として挙げられる。\nどの要件から実装するかは、システム導入の目的から実装の優先順位を考える。\nまた、開発中に要件が変更・追加される場合は、システム導入の目的を軸に妥当性を考える。\nシステム導入の目的にその要件変更・要件追加が必要か、すでにある要件で充分目的を達成できるかを考え、変更・追加が妥当でない場合、発注先はその要件の変更・追加を受け入れないほうが望ましい。\n妥当でない要件を受け入れた結果、開発の進捗が順調でなくなったり、開発されたシステムやサービスが不調となったりした場合、その非は受け入れた発注先にある。",
"part_type": "part",
"localID": 6
},
{
"title": "制約条件",
"description": "制約条件とは、システムを開発する際、考慮しなければならない前提や制約のことである。\nたとえば、「システムの操作担当者はカマキリのため、人知類用の入力機器が使用できない」「来年に税制が改正されるので、それまでにシステムが運用できるようにしてほしい」などである。\n要件定義書を作成する際、発注先はどのような制約条件があるか網羅するよう、システムを使用する藩国の憲法や法令・規則・条例、利用者の操作技術・業務時間・使用環境など、様々な観点から発注元に聞き出す必要がある。",
"part_type": "part",
"localID": 7
},
{
"title": "機能要件・非機能要件",
"description": "機能要件(functional requirement)とは、システムが持たなければならない機能を定義したものである。\nシステムに何ができるのか・何ができないのかをできる限り、正確に網羅する必要がある。\n具体的には「各機能ごとにどのような入出力があり、どのような処理がなされるか」「誰がいつどこでこの機能を利用し、どのような結果が得られるか」「なぜこの機能が必要か」などが機能要件として挙げられる。\nそれぞれの要件間で整合性がとれているか、他の資料と内容に矛盾はないか、読み手によって解釈が異なるようなあいまいな表現はないかなど、充分に注意しなければならない。\n／＊／ \n非機能要件(non-functional requirement)とは、使いやすさやセキュリティなど、システムが持たなければならない性質を定義したものである。\n非機能要件を多面的に検討するためには、そのシステムに関連する者は誰かを考えるとよい。\nたとえば、システムを操作・運用する者、保守作業をする者、システムを改修・機能追加する者、システムに不正にアクセスしデータを盗む者などである。\nそれらの者がそれぞれどの程度の技術があり、いつどのような操作をするか、システムに問題が発生した場合、どのような行動をするかなどを考え、そこから求められる非機能を明確にする。\n非機能要件は機能要件よりも検討すべき範囲が広いため、様々な立場のなるべく多くの者と話し合って、できるだけ多く洗い出すことが望ましい。\n／＊／ \n性能要件(performance requirement)とは非機能要件のひとつで、システムが持つべき処理速度や取り扱えるデータ容量、センサーの精度など、性能に関することである。\n性能要件は「業務に支障のない範囲」「既存システムと同等」といったあいまいな表現ではなく、「操作完了後、一秒以内に次の画面に移動する」「二十三時に処理を開始し、翌日の七時半までに処理を終了する」など、具体的な数値で表すことが望ましい。\n発注元が用意した機械でも「処理速度はどの程度か」「取り扱えるデータ容量はどのくらいか」といった点を、発注先は確認しておき、必要に応じて機械の買い替えを提案することが望ましい。\n性能面で実際に動作してみないとわからない点については、「システムにアクセスする者が一名の場合」といった前提条件をつけて性能要件を表現する。\nその性能が充分でない場合、業務に重大な影響を与える危険性が高く、机上の計算では不安なものについては、妥当な実現方法を検討するため、類似環境やテストデータを用意し、実験で確認する必要がある。\n／＊／ \nセキュリティ要件(security requirement)とは非機能要件のひとつで、システムの機密性に関するものである。\nたとえば「データをどのような暗号形式で保存するのか」「不正なアクセスを防ぐためにどのような認証方式を採用するのか」「障害が発生した場合、速やかに復旧するためにどのような対策を講じるのか」などが挙げられる。\n発注先は発注元よりもセキュリティの知見を有するため、発注元から要望がなくても発注先は積極的にセキュリティについて調査し、その見積もりを提出するほうが望ましい。\nそこまでしたうえで、発注元がセキュリティ対策は不要だと判断した場合、セキュリティ上の問題が発生した際の非は発注元にある。",
"part_type": "part",
"localID": 8
},
{
"title": "変更管理",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "変更管理とは",
"description": "要件定義において変更管理とは、いったん確定した要件・仕様・設計に対して発生した変更の管理である。\n変更管理は窓口を一本化し、変更管理担当者が一元的に管理することが望ましい。\n変更を要求する場合、業務上および技術上、その変更をおこなうべき妥当な根拠があるか確認したうえで、変更管理担当者に報告する。\n変更管理担当者は、その変更で影響を受ける開発担当者に調査を依頼する。\n変更は必要か、実現できるか、実現する場合どのような方法か、変更による作業やスケジュールへの影響はどの程度か、変更にどの程度の時間・費用が必要か、誰がその変更を実施するのか、優先順位はどの程度かなどを調査したうえで、計画に基づいて変更を実施する。\n実施した変更は、進捗・状況を定期的に確認し、必要に応じて是正する。\n発注先は変更管理の工数もプロジェクト管理費用に含め、発注元に認めてもらうことが重要である。",
"part_type": "part",
"localID": 10
},
{
"title": "要件管理ツール",
"description": "要件管理ツール(requirements management tool)、または要求管理ツールとは、要件や要求を管理するためのツールの総称である。\n要件・要求の管理とは、顧客や利用者からシステムに対する要望を引き出すこと、要件・要求を文書化し体系づけて整理すること、期間内・予算内に開発を終えるため発注元(発注者)と発注先(受注者)の間で要件・要求の範囲について合意を形成することなどである。\n一般に要件管理ツールは、システムやソフトウェアの開発チームが一元的に要件・要求を登録・編集・参照できる機能を有する。\nそのため、要件管理ツールを用いることで、最新の要件を開発チームのメンバー全員が知ることができる。\nまた、要件のトレーサビリティを管理するため、要件管理ツールはトレーサビリティ・マトリクスを登録・編集・参照できる機能を有する。\n要件管理ツールを正しく使いこなすためには、どのように要件や要求を管理しているかが重要となってくる。\n／＊／\nソフトウェア開発において、トレーサビリティ(traceability)とは、仕様書やプログラムなど、各工程や各作業で作られた成果物がどの成果物に影響を与えているか、追跡できることを指す。\nたとえば「要件定義書のA010の要件を変更した場合、整合性を保つため、外部設計書BのB010と外部設計書CのC030も変更する必要がある」「外部設計書BのB010を変更した場合、内部設計書DのD050と結合テスト仕様書XのX320も変更する必要がある」「内部設計書DのD050を変更すると、プログラムEのE120と単体テスト計画書YのY090を修正する必要がある」などである。\n上記の例に出てくるA010やB010などは、追跡を容易にするため、要件や仕様に割り当てられた固有の番号である。\nソースコード上にコメントとして上記の番号を記載することで、要件や仕様が変更になった際、プログラムの修正が容易になる。\nトレーサビリティを管理することで、インパクト分析やカバレッジ分析をおこなえるようになる。\nトレーサビリティは、追跡可能性とも呼ばれる。\n／＊／\nトレーサビリティ・マトリクス(traceability matrix)とは、それぞれの成果物の間の追跡可能性を確保するために考え出された表である。\nたとえば要件と外部設計のトレーサビリティ・マトリクスなら、縦に要件、横に外部設計の固有の番号がそれぞれ記述される。\nA010の要件を変更した際、整合性を保つため、B010の外部設計が変更しなければならない場合、A010の要件の行と、B010の外部設計の列の、交点の升目に印をする。\nこのように、印をした升目から要件の行と外部設計の列を確認することで、一方を変更した際、他方の修正の必要な箇所がすぐに分かる。\nトレーサビリティ・マトリクスは、一般的な表計算ソフト(spreadsheet)でも作成できるが、作成と保守に必要な労力が大きい。\nそのため、規模の大きいプロジェクトでは、要件管理ツールのような専門のソフトウェアを用いることが多い。\nトレーサビリティ・マトリクスは、追跡可能マトリクスとも呼ばれる。\n／＊／\n要件や要求の管理において、インパクト分析(impact analysis)とは、要件や仕様を変更した際、仕様書やプログラムに与える影響を評価することである。\n影響の大きさを知ることで、要件の変更や追加を受け入れるか否かを決める際の判断材料になる。\nインパクト分析は、変更波及解析(change impact analysis)、影響波及解析とも呼ばれる。\n／＊／\n要件や要求の管理において、カバレッジ分析(coverage analysis)とは、不要・余分な仕様がないか、あるいは足りない仕様がないかを評価することである。\n不要・余分な仕様とは、要件定義書に対応する要件がない仕様である。\nまた、足りない仕様とは、要件定義書に記載されている要件に対応する仕様がないことである。\n仕様の過不足を知ることで、不要な機能を作ったり、必要な機能が足りなかったりすることを防ぐことができる。",
"part_type": "part",
"localID": 11
},
{
"title": "仕様変更率",
"description": "ソフトウェア開発において、仕様変更率とは、変更された仕様の件数をすべての仕様の件数で割った割合である。\n仕様変更率は、要件定義書や仕様書の出来栄えを判断する指標となる。\n仕様変更率が高い場合、要件定義書や仕様書の様式や内容にあいまいなところがあると考えられる。\nたとえば、入力値の検証に関する仕様変更があったとき、そもそも入力値の検証を想定せずに仕様書を作成していた場合、その仕様変更をプログラムのどの箇所でおこなうのが妥当なのかというところから検討しなければならなくなる。\n適切な仕様書がある場合、どこで仕様変更に対応するかがおのずと決まるため、仕様変更の影響範囲を小さく抑えることができる。\n仕様変更率が高いプロジェクトと低いプロジェクトを比較すると、どこに改善の余地があるかがわかりやすい。\nたとえば、仕様変更率が高いプロジェクトは顧客にいわれた仕様変更をそのまま受け入れているのに対し、仕様変更率が低いプロジェクトはその仕様変更がどのような要求から出てきたのかを確認していることが多い。\n具体的に例を挙げると、「監視カメラの首振り角度を30度から45度に変更してほしい」と依頼があった場合、首振り角度を広げる理由を確認する。\nひとつの監視カメラが撮影する範囲を広げることで、監視カメラの設置台数を減らし、導入費用を下げることが目的なら、首振り角度の変更で死角ができないよう、カメラの首振り速度を変更するといった対応も必要になってくる。\nこのように、なぜその仕様変更が必要なのかを確認することで、合わせて対応が必要な箇所に気づくことができる。\nまた、要求によっては仕様を変更せず、既存の機能で対応できる場合もある。",
"part_type": "part",
"localID": 12
}
],
"localID": 9,
"expanded": true
}
],
"expanded": true,
"localID": 2,
"description": "流用可能"
},
{
"title": "外部設計・内部設計",
"part_type": "group",
"children": [
{
"title": "外部設計・内部設計とは",
"description": "ソフトウェア開発において、外部設計(external design)とは、開発するシステムが利用者や外部のシステムに対し、機能やインターフェイスをどのように提供するかを設計することである。\n外部設計は、基本設計(basic design)や概要設計(outline design)と呼ばれることもある。\n外部設計を文書にまとめたものを外部設計書や外部仕様書などと呼ぶ。\n外部設計書に記載される内容は、要件定義に基づいて作成される。\n具体的には、システムの目的や方針、機能、ユーザインタフェース、ソフトウェア構成、ハードウェア構成、ネットワーク構成、システムインタフェースなどが外部設計書に記載される。\n外部設計書を作成する際、現行の業務の流れを知ることが重要である。\n業務のどの部分をソフトウェアが担当するか、どの業務を変更するか、ソフトウェアの導入前後の業務の流れをそれぞれ図表で表現することで、システムの規模が明確になり、開発の日程や予算が試算できるようになる。\n確定していない仕様については顧客と交渉している状態を記載する。\nたとえば、画像ファイルの保存形式に「未定」と記載されていると、必要な工数や費用を見積もることができないが、「対応する画像ファイルの保存形式は下記のいずれかを予定」という仕様の下に、保存形式の候補が記載してあれば、開発に必要な日程や費用を推測できる。\n候補の中で特に有力なものがあるなら、そのことも明示するとよい。\nデータベースの設計については、ER図やCRUD図などが記載される。\nER図(entity-relationship diagram)とは、データベースの各テーブルが互いにどのように参照しているかを表した図である。\nまた、CRUD図とは、どの権限を持つ利用者やシステムに対し、生成(create)・読み取り(read)・更新(update)・削除(delete)を許可するかを表した図表である。\n外部設計は、顧客や利用者の目に触れる部分を決めるため、顧客の仕事の結果に直接影響することもある。\nそのため、外部設計の内容については顧客の了承を得ることが望ましい。\n／＊／\nソフトウェア開発において、内部設計(internal design)とは、外部設計に基づいてプログラムやシステムの内部における具体的な処理の手順や実装方法について設計することである。\n内部設計は、詳細設計(detail design)と呼ばれることもある。\n内部設計を文書にまとめたものを内部設計書や内部仕様書などと呼ぶ。\n内部設計書に記載される内容は、要件定義と外部設計に基づいて作成される。\n具体的には、入出力情報のデータ構造、変数の初期値、定数の値、例外処理・エラー処理・異常処理の定義と設計、メモリ使用量の見積もり、割り込みや多重起動の対策、排他制御のロック・アンロックのタイミングなどが内部設計書に記載される。\n内部設計は、外部設計と異なり、顧客や利用者の目に触れない部分である。そのため、顧客の了承を得る必要はほとんどなく、ソフトウェア開発の担当者が理解できる内容になっていればよい。",
"part_type": "part",
"localID": 14
}
],
"expanded": true,
"localID": 13,
"description": ""
}
],
"localID": 1,
"expanded": true
},
{
"title": "下流工程（ソフトウェア開発）",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "コーディング（ソフトウェア開発）",
"part_type": "group",
"children": [
{
"title": "コーディングとは",
"description": "ソフトウェア開発において、コーディング(coding)とは、コンピュータ言語を用いて、ソースコードを記述することである。\nコーディングの対象となるコンピュータ言語には、プログラミング言語やデータ記述言語、スタイルシート言語などがあるが、プログラミング言語による記述をコーディングと呼ぶ場合が多い。\nなお、文章構造を記述するための形式言語であるマークアップ言語は、データ記述言語の一種である。\nプログラミング言語によるコーディングとは、課題の解決策をプログラムが実行できるよう、プログラミング言語に置き換え、ソースコードで記述することである。\nコーディングをおこなう者をコーダー(coder)と呼ぶ。\nプログラミング言語によるコーディングをプログラミング(programming)と呼ぶ場合もあるが、プログラミングにはプログラムの設計も含まれる。\nプログラミングをする者をプログラマ(programmer)と呼ぶ。\nプログラミング言語ごとに、それぞれシンタックスとセマンティクスが異なるため、コーダーがある言語のコーディングができても、別の言語のコーディングができるとは限らない。\nなお、シンタックス(syntax)とは、構文や構文規則、文法とも呼ばれ、データの形式や構造、枠組みを指す。\nセマンティクス(semantics)とは、データの意味や中身である。\nコーディングする際は、シンタックスに応じて文字が色分けして表示するソースコードエディタ(source code editor)を用いると、ソースコードの書き間違いに気づきやすく便利である。\nソースコードエディタによっては、対応しているプログラミング言語の文法上の不備を警告で知らせる機能もある。\nまた、数字の0と英字大文字のOのような紛らわしい文字を判別できるよう、コーディングに適したフォントを用いると、ソースコードの書き間違いに気づきやすく便利である。\n／＊／\nソフトウェア開発において、コーディング規約(coding conventions)とは、プログラミング言語やデータ記述言語などでコーディングする際のルールやガイドラインである。\n複数名でコーディングをおこなう場合、コーダーによって記述方法が異なる場合、他のコーダーが記述したソースコードを読んだり直したりすることに時間がかかり、ミスも増える。\nコーディング規約を遵守すると、ソースコードを読みやすくなるため、プログラムの保守性を上げ、ソフトウェアの品質向上につながる。\nコーディング規約が遵守されているかは、レビューや静的解析によって確認・検証する。\nコーディング規約としては、変数・定数・関数などの命名規則、オフサイドルールなど、様々な規則がある。\n命名規則(naming convention)とは、どのような名前をつけるかという規則である。\nオフサイドルール(off-side rule)とは、レイアウトルール(layout rule)とも呼ばれ、字下げによって文や関数のかたまりの範囲を示す規則である。\nどのようなコーディングが読みやすいかは、コーダーがどのようなコーディングに慣れ親しんできたかが影響するため、明確に決めることは難しい。\nそのため、コーダー同士でどのようなコーディングにすべきか論争とならないよう、妥当なコーディング規約を定めることが望ましい。\nソフトウェアを開発する組織やプログラミング言語のコミュニティですでに普及しているコーディング規約があり、不適切でない場合、そのコーディング規約を採用することが望ましい。\nまた、レビューやテストで見つかったソフトウェアの不備が、コーディング規約の追加・修正で防げる場合、コーディング規約を更新することが望ましい。\nコーディング規約は、コーディング規則(coding rules)、コーディング基準(coding standards)とも呼ばれる。",
"part_type": "part",
"localID": 17
}
],
"expanded": true,
"localID": 16,
"description": "流用可能"
},
{
"title": "ソフトウェア・テスト",
"part_type": "group",
"children": [
{
"title": "ソフトウェア・テストとは",
"description": "ソフトウェアの欠陥・不良・不具合・障害などの問題によって、ソフトウェア本来の機能が制限され、そのソフトウェアに期待される機能や価値を顧客や利用者に提供できない状態を、そのソフトウェアの品質が悪いと表現する。\nこうしたソフトウェアの品質を改善するため、ソフトウェアの問題を見つけ出す行為を総じて、ソフトウェア・テスト(software testing)、あるいはソフトウェアV&V(software verification and validation)と呼ぶ。\nソフトウェア・テストには、問題が起きる操作を発見するために行われるテストや、問題が再現する条件を調べるためのテスト、問題を起こしているソースコードを特定するためのテストなど、いくつかの種類に分かれている。\nソフトウェア・テストは、ソフトウェアの品質を改善するために重要なものであるが、ソフトウェアのすべての問題を発見できるわけではない。\nたとえば、それぞれ0から99までの数値が入力できる二つの入力欄があり、入力した二つの数値を積を表示するという単純なプログラムの場合でも、正常系のみをすべて試すだけで100通り×100通り＝1万通りのテストが必要になる。\n英字や記号などを入力した場合や未入力の場合など、異常系のテストも含めると、テストケースはより多くなる。\nさらに、このソフトウェアが対応すべき動作環境が10通りの中央演算処理装置、10通りのメモリ容量、10通りのドライブ容量とすると10通り×10通り×10通り＝1000種類のハードウェア構成でテストする必要がある。\n実際には、オペレーション・システムの種類やバージョン、ドライバ、様々な周辺機器の組み合わせ、同時に実行するプログラム、テストを実行する順番や入力タイミングなども影響するため、テストケースは膨大となる。\n以上のように、ソフトウェア・テストですべてのテストケースを実行することは不可能であるため、ソフトウェア開発に関係する者は「テストによってすべての問題を発見することは不可能だ」と心得るべきである。\n実際におこなわれるソフトウェア・テストは、妥当な費用・時間・資源で、関心のある範囲をなるべく網羅できるよう、様々な種類のテストを組み合わせて問題を発見している。\nここで「関心のある範囲」とは、たとえば、ソフトウェアを出荷するべきか、出荷するならいつが妥当か、プロジェクトを中止するか、プロジェクトを継続するなら開発要員を増やす必要があるか、ソフトウェアが担う役割の範囲を変えるか、ソフトウェアの価格を変えるかなどを判断するための情報である。\nなぜ様々な種類のテストを組み合わせるのかといえば、学生の学力試験にたとえると、国語の試験だけを行い、その成績がよければ他の教科の成績もよいだろうと判断せず、なるべく出題範囲全体を網羅するような設問の各教科ごとに試験したほうが、その学生の学力を正確に知ることができるからである。\nむろん、学力試験で山を張った一夜漬けの勉強がたまたま出題されて好成績になったり、カンニングをしたりして正しい学力を測定できないことがあるように、ソフトウェア・テストでも不適切なテストや虚偽のテスト結果などでソフトウェアの品質を正しく測定できない場合があるため、そのようなことがないよう、対策を講じる必要がある。\nもし、テストによって収集された情報を使う予定がないのなら、費用や時間の無駄となるため、そのテストをするべきではない。\nなお、ソフトウェア・テストによって発見された問題はすべて修正されるわけではなく、納期や経営戦略などから重要ではない問題をあえて修正せずにソフトウェアを出荷する場合もある。\nなぜなら、問題を修正する過程で新たな問題が作られることもあり、納期が迫っていると修正ミスの頻度も多くなるため、重要ではないなら修正しないほうが妥当と考えられるからである。\nどの問題が重要かは顧客や利用者の価値観による。\n修正が容易か困難かは基本的に問題の重要性とは関係ない。",
"part_type": "part",
"localID": 19
},
{
"title": "テストの分類",
"description": "ソフトウェア・テストの分類はいくつか種類がある。\n開発工程によるテストの分類では、単体テストや結合テスト、総合テスト、受け入れテストなどに分類される。\nまた、どういった品質を検証するかという観点でテストを分類した場合、機能テスト(functional testing、functional requirement testing)と非機能テストに分けられる。\n非機能テストには、性能テスト、負荷テスト、ユーザビリティテスト、セキュリティテスト、保守性テスト、信頼性テスト、移植性テストなどがある。\nどのようにテストを実行するかという観点では、動的テストと静的テストに分けられる。\n動的テストとは、実際にプログラムを動作させることで問題を見つけるテストである。\nそれに対し、静的テストとはソフトウェアを構成するソースコードを検証することで問題を見つけるテストである。\n知類が要件や設計、ソースコードを目視確認するソフトウェア・レビューは、静的テストである。\nまた、静的コード解析(static code analysis)や静的プログラム解析(static program analysis)、静的解析などと呼ばれる、機械的にソースコードやオブジェクトコードを解析することも静的テストである。\n単にソフトウェア・テストと言った場合、動的テストを指すことが多い。\nテストケースを作成する技法で分類した場合、テスト対象を中が見える箱と考えるホワイトボックステストと、テスト対象を中が見えない箱と考えるブラックボックステストに分けられる。\n技法による分類では、ホワイトボックステストとブラックボックステスト以外に、プログラムの仕様と内部構造の両方に着目したグレーボックステスト(gray box testing)という分類を追加する場合もある。\nグレーボックステストは、ホワイトボックステストとブラックボックステストを組み合わせたテストである。",
"part_type": "part",
"localID": 20
},
{
"title": "テスト計画書",
"description": "ソフトウェア・テストにおいてテスト計画書とは、ひとつひとつのテストに対し、どのようにテストするかを記載した仕様書である。\n時間がないプロジェクトマネージャでも概要を理解できるよう、テスト計画書の最初は「なぜこのテスト計画を記載する必要があるのか」「今後はどのような方針でテストを進めていくのか」「どのような品質の製品を出したいのか」など、テスト計画の要約を記載する。\nそれ以外にテスト計画書に記載すべき内容は、テスト計画に関連する他の仕様書、テスト対象のソフトウェアとそのバージョン、テストするべき機能とテストする必要がない機能、テスト方法、合否の判断基準、テスト要員、スケジュール、承認、テストの終了基準などである。\n／＊／\nテスト計画に関連する他の仕様書を列挙することで、どのような資料を参考にして立てられた計画なのかが分かる。\n／＊／\nテストする必要がない機能は重要である。\nなぜなら、たとえば、ある既存のライブラリをテストせずに問題が起きた場合、誰に責任があるかを明確になるからである。\nそのため、テストする必要がない機能は、ソフトウェア開発プロジェクトの責任者に承認を得る必要がある。\nもし、既存のライブラリもテストする場合は、そのための要員や時間・予算を確保しなければならない。\n／＊／\nテスト方法とは、ホワイトボックステストかブラックボックステストなど、テストの方法を記載する。\n文言や動作などのどのような観点・切り口でテストするのか、具体的なテストの操作手順と期待される結果は、テスト設計仕様書と呼ばれる別の仕様書に記載する。\n／＊／\nテスト計画書に記載するテスト要員とは、誰がテスト計画を管理するか、誰がテストケースを作りテストを実施するか、テストで見つかった問題の原因を誰が特定するかなど、その要員計画を記載する。\nテスト担当者に適切な技術がない場合は、テストの技術を身に着けるためのトレーニング計画も記載する。\n遅れが出ているソフトウェア開発プロジェクトに要員を追加すると、新入りが新しい環境に慣れたり、資料にまとめられていない暗黙のルールを新入りに教育したりする必要があるため、さらに遅れることになる。\nそのため、テスト担当者の要員計画はよく考える必要がある。\n／＊／\nテストのスケジュールは開発スケジュールに依存する。\nそのため、計画を立てた後も定期的にスケジュールを見直す必要がある。\nスケジュールを見直す頻度は、たとえば二週間おきなどである。\nテストのスケジュールを見直す際、テスト対象のソフトウェアからあとどれぐらいの不具合が見つかりそうか推定できると、妥当性の高いスケジュールを作ることができる。\n残存する不具合を推定する方法としては、二チームにテストしてもらう方法がある。\nたとえば、XチームとYチームという二つのチームがあり、どちらのチームも同じテストをした場合、Xチームが見つけた不具合がa個、Xチームが見つけた不具合がb個、XとYのどちらも見つけた不具合がc個とすると、そのソフトウェアで見つけられるすべての不具合はa×b÷cと推定することができる。\nあるいは、百のテストケースの中から十を試した結果、不具合が五つ見つかったら、百のテストケースで五十見つかるだろうと推定できる。\nただし、推定方法によっては、実際に見つかる不具合よりもかなり低く見積もる場合もあるため、推定方法の特性について理解する必要がある。\n／＊／\nテスト計画書は承認を得る必要がある。\n承認を誰に得るかは組織によって異なる。\n正式な承認会議を開く場合もあるが、時間の節約のため、チャットや電子メールで不備や要望がないか関係者に確認をとるだけの場合もある。\n／＊／\nテストの終了基準は、何によってテストを終えたと判断するかである。\nたとえば、重要度「高」の不具合が残っていないこと、重要度「高」の不具合が48時間以内に見つかっていないこと、すべてのテストケースの98パーセントが合格となっていることなどである。\n出荷を急ぐ開発責任者が不具合の残ったソフトウェアを詭弁で出荷したりしないようにするため、終了基準には測定できる数値を記載するべきである。\nたとえば、「24時間ソフトウェアを稼働させても充分安定していること」という終了基準の場合、何度かハングアップするソフトウェアでも「ハングアップしてもすぐに復旧できる」「24時間中23時間50分は問題なく動作する」と主張して製品を出荷する恐れがある。\n製品に不具合があった場合、営業やユーザサポートから非難されるのはテスト担当者であるため、自衛のためにも終了基準の記載には注意すべきである。",
"part_type": "part",
"localID": 21
},
{
"title": "レビュー",
"description": "ソフトウェア・レビュー(software review)とは、静的テストのひとつで、単にレビューとも呼ばれる。\nソフトウェア・レビューは、仕様書や設計書、ソースコードなど、ソフトウェア開発の工程で作成された成果物の内容を確認・検証し、不具合や欠陥などの問題点を発見する作業である。\nソフトウェアの不具合や欠陥は、一般に開発工程の初期に発見したほうが修正に費やす費用や時間が少ないとされている。\nソフトウェア・レビューは、ソースコードを記述する前から実施することができるものもあるため、問題を早く気づくために有用である。\nレビューで見つかった不具合や欠陥は、修正し忘れることがないよう、どこにどのような指摘があったか記録される。\n不具合や欠陥が修正されているか確認する目的で、すでにレビューした仕様書やソースコードを再度レビューすることもある。\n誰がソフトウェア・レビューをおこなうのかという観点から分類すると、机上チェック、ピアレビュー、IV&Vに分けられる。\nまた、何をレビューするかという観点から分類すると、外部設計書や内部設計書などをレビューするデザインレビュー(design review)と、プログラムのソースコードをレビューするソースコードレビューに分けられる。\nデザインレビューでは要件定義書や仕様書などで、要件や仕様の不備・不足に気づきやすい構成になっているかどうかも検証の対象である。\n／＊／\n机上チェック(desk checking)とは、ソフトウェア・レビューのひとつで、知類が仕様書やソースコードなどを目視確認する検証方法である。\n基本的に仕様書やソースコードの作成者本人が確認する。\n作成者本人が確認しているため、ピアレビューと比べ、検証の精度は劣るとされている。\n机上チェックは、机上検査とも呼ばれる。\n／＊／\nソフトウェア開発において、ピアレビュー(peer review)とは、ソフトウェア・レビューのひとつで、作成者の同僚やチームの仲間が成果物を確認する検証方法である。\nまた、ピアレビューにはチーム内で知識を共有したり、他社の技術を学ぶ側面もある。\nピアレビューには、ソフトウェアを開発する組織内の公式な活動か否か、参加者の人数などによって、コード・レビュー(code review)やソフトウェア・インスペクション(software inspection)など、いくつかの種類に分類される。\n余談だが、ソフトウェア開発以外の分野でピアレビューとは、学会誌に学術論文を掲載する際、発表に値する内容か否かを判断するため、同じ分野の研修者にその論文を読んでもらうことである。\n／＊／\nIV&V(independent verification and validation)とは、第三者による検証のこと、または検証する第三者のこと。\nここでいう第三者とは、ソフトウェアを開発する組織とも、ソフトウェアの開発を委託した組織とも、管理面や財政面で独立した組織のことである。\n第三者が静的テストや動的テストをおこなうことで、検証の客観性を保証する。\n／＊／\n要件のレビューでは、要件定義書に記述された内容に不備や不足がないか、チェックリストを使って検証し、記述されるべき内容が含まれているかを確認することが重要である。\n要件はできるだけ緻密かつ精確に検討することが理想である。\n一般に、要件は他の開発工程と同様に、荒いものから徐々に完成度を高めていくという工程を経る。\n開発の初期段階では、開発に必要な水準まで要件が定まっていなかったり、必要な要件が出し切れていない恐れがあったり、時間不足で検討できずに保留となっているものがあったりすることがある。\nこのような限界を前提として共有することで、要件を円滑にレビューすることができる。\nまた、顧客や利用者の業務内容や業務で使う用語について、充分に理解できなかったり、完全には確認できなかったりという限界もある。\nそのため、顧客の各業務の担当者を代表として集め、要件定義書の完了レビューをおこなうことが望ましい。\n顧客から要件の内容に不備がないことを確認してもらったら、承認を得たことを署名捺印など法的効力がある形で記録に残すとよい。\n／＊／\n外部設計のレビューでは、外部設計書に記述された内容が要件定義書の記述と矛盾していないか、整合性がとれているかを検証する。\n矛盾がある場合はなぜ矛盾しているのか、その理由が明記されていること、および関係者から了解を得ていることを確認する。\nまた、外部設計として記述すべき入出力や外部インターフェースが不備なく規定されており、論理関係が矛盾していないことも検証する。\n内部設計のレビューも同様に、内部設計書の記述内容が要件定義書や外部設計書の記述と矛盾がないことを確認する。\n内部設計では、どのようにプログラムを実装するのか、具体的なアルゴリズムが充分に明記されていることもレビューで確認する。\n処理すべきデータがない場合はどのような処理になるのか、各種データの初期値なども、内部設計のレビューで確認すべき項目である。\n／＊／\nソースコードレビューでは、コーディング規約に沿って記述されているか、内部設計書に記述された機能やデータ形式がプログラム上で正しく実現しているか、保守や再利用が容易なコードとなっているかを確認する。\nまた、ソースコードにコメントが記載されている場合、そのコメントが有意義か否か、コメント内容の正確さも確認する。\nソースコードを理解できないとレビューできないため、レビューに参加する者はプログラミングの基本的な知識に加え、使用するプログラミング言語の知識も有する必要がある。\nソースコードレビューで問題が見つかった箇所を記録し、分析することで問題が起こりやすい箇所が明らかになる。\n分析結果をプログラミング時の注意点やコーディング規約に反映することで、ソフトウェアの品質向上につながる。\n／＊／\nソフトウェア開発の関係者で「レビューができない」「レビューをするべきでない」と主張する場合、その者の思考様式や開発組織の文化に問題があると考えられるため、メタテストとしてその主張の理由を確認し、妥当でない場合は正したほうがよい。\nたとえば「プログラマ以外が設計書を見ても問題を見つけられない」という主張には「プログラマ以外でも誤字脱字や論理的な誤りは指摘できる」と反論できる。\n／＊／\n前工程で見つかるべき不備や不具合が後工程で見つかった場合、レビューやテストに不備があったと考えられる。\nたとえば、要件のレビューで見つかるべき不備が、外部設計や内部設計のレビューで見つかった場合である。\nこのようにレビューが正しく機能していない場合、レビューのチェックリストに確認項目を追加・修正したほうがよい。\nこのチェックリストはソフトウェア開発をおこなう組織にとって知的財産であり、他のソフトウェアやシステムを開発する際も継承することが望ましい。\nただし、案件によって妥当でない確認項目については、責任者の承認を得て確認を省略してもよい。\nまた項目数が膨大になると確認が形骸化する恐れがあるため、定期的にチェックリストを見直し、不要な確認項目は削除することも検討したほうがよい。",
"part_type": "part",
"localID": 22
},
{
"title": "非機能テスト",
"description": "非機能テスト(non-functional testing)とは、ソフトウェアの非機能要件に関するテストのことである。\n非機能テストには、ドキュメンテーションテスト、性能テスト、負荷テスト、ユーザビリティテスト、セキュリティテスト、保守性テスト、信頼性テスト、移植性テストなどがある。\n非機能テストは、非機能要件テスト(non-functional requirement testing)とも呼ばれる。\n／＊／\nドキュメンテーションテストとは、非機能テストのひとつで、ソフトウェアのマニュアルに不備がないか検証するテストである。\nマニュアルとは、取り扱い説明書のことである。\nマニュアルに記載されている操作手順に誤字脱字や順番の入れ違いがないか、記載された操作手順の通りに操作して意図した通りに動作するか、マニュアルの構成やレイアウトなどに問題がないかをドキュメンテーションテストで確認する。\n／＊／\n性能テストとは、非機能テストのひとつで、想定された状況でソフトウェアの性能が期待された通りに出ているか検証するテストである。\n性能が期待通りとは、ソフトウェアを企画もしくは設計する段階で設定した性能を満たしているかということである。\n性能の定義は具体的な数値におこなう。\nたとえば「10分以内に300メガバイトのデータを処理する」や「決定ボタンを押して3秒以内に処理が終わる」などである。\n性能要件が「300メガバイトのデータを10分以内に処理する」でも、1メガバイトのデータを処理するのに10分近くかかったり、301メガバイトのデータを処理するのに30分かかったりする場合は性能の問題として扱うべきである。\n性能テストで見つかる不具合は最悪の場合、最初の設計からやり直すことになる。\nそのため、ある程度プログラムが動くようになった時点で、定期的に性能テストを実行することが望ましい。\n性能テストはパフォーマンステスト(performance test)とも呼ばれている。\n／＊／\n負荷テストとは、非機能テストのひとつで、負荷を与えた場合の動作を検証するテストである。\nライブやコンサートのチケットの予約システムのように複数名が同時にアクセスするシステムでは、何かの契機に利用が集中する恐れがある。\nそのため、システムに負荷がかかっている状態での動作を確認しておく必要がある。\n負荷テストをおこなうには実際に複数名が同時にアクセスするという方法もあるが、テストに必要な負荷が大きい場合、実施するテスト担当者やテスト用端末の確保が難しくなる。\nそのため、一連の操作を自動でおこなうシミュレータを用意して負荷テストする場合もある。\n一連の操作とは、コンサートのチケットの予約システムなら、コンサートを検索し、予約を入れ、決済するという操作である。\n負荷テストの分類にはロードテストやストレステストなどに分けられる。\nロードテスト(load testing)とは、通常時やピーク時に想定される負荷をかけた場合の負荷テストである。\n特にピーク時に想定される負荷をかけた場合の負荷テストをピークロードテスト(peak load testing)と呼ぶ。\nストレステスト(stress testing)とは、想定の上限を超えた場合の動作を検証するテストである。\nたとえばコンサートのチケットの予約システムで高負荷をかけた場合、決済は済んでいるが予約が保存されていない場合、チケットを入手できなかった利用者から損害賠償を請求される恐れがある。\nこのような事態を防ぐため、高負荷で正常にシステムが正常に動作しない場合の動作を確認しておく必要がある。\n／＊／\nユーザビリティテストとは、非機能テストのひとつで、開発した製品を実際に利用者に使ってもらうことで使い勝手や好みなどを確認するテストである。\n種族や年齢層、職業、性別など、利用者によって使い方が異なる場合、それぞれの利用者に使ってもらうことが望ましい。\nたとえば、大人と子供で使い方が異なると予想され、ユーザビリティテストに十名テストもらうなら、大人の利用者と子供の利用者を五名ずつにテストしてもらうなどである。\n／＊／\nセキュリティテストとは、非機能テストのひとつで、ソフトウェアが悪意ある者の攻撃に耐えうるかを検証するテストである。\n個人情報が保存されているシステムから情報が流出したり、課金要素のあるゲームでプレイヤーのデータが復旧できないよう削除されたりした場合、企業の信用を失う事態になる。\nそのため、ソフトウェアのセキュリティは非常に重要である。\nセキュリティの問題は年々進歩し、高度となっているため、セキュリティテストをおこなうテスト担当者は日々、新しいセキュリティ技術を学び、新しいセキュリティ攻撃の手法を迅速に理解する必要がある。",
"part_type": "part",
"localID": 23
},
{
"title": "ホワイトボックステスト",
"description": "ホワイトボックステスト(white-box testing)とは、プログラムの論理構造が正しいか否かを解析するためのテストである。\nそのため、プログラムの内部構造がわかっていることがテストの前提である。\nホワイトボックステストは主に単体試験で採用されているテストである。\nホワイトボックステストは、クリアボックステスト(clear box testing)、グラスボックステスト(glass box testing)、透明ボックステスト(transparent box testing)、構造テスト(structural testing)などとも呼ばれる。\n／＊／\n制御パステストとはホワイトボックステストの主要な技法のひとつで、プログラムがどのような振る舞いをし、どのように制御され、どのように実行していくかをテストするものである。\n制御パスとは命令や条件分岐などの組み合わせのことである。\nプログラムの規模が大きくなると、制御パスは天文学的な数となるため、いくつかの網羅基準でテストする量を限定して実施される。\n／＊／\n網羅基準(coverage criteria)とは、テスト・カバレッジを算出する際、どれくらい細かくテストするかという基準である。\n網羅基準はカバレッジ基準とも呼ばれる。\n／＊／\nテスト・カバレッジ(test coverage)とは、テスト対象となるソフトウェア全体のうち、テストを終えた、あるいはテストしようとしている箇所の割合のことである。\nテスト・カバレッジは通常、パーセントの単位で数値によって表現される。\n自動車や飛行機のような事故があった際、命に関わるようなものに使われるソフトウェアに関しては、限りなく100パーセントに近いテスト・カバレッジを要求される。\nそうではない一般的なソフトウェアの場合、テスト・カバレッジはソフトウェアの対象によって異なるが、だいたい60パーセントから90パーセントまでが妥当とされている。\nテスト・カバレッジには、プログラムのソースコードをどれだけテストしたかを示すコード・カバレッジや、仕様書や要件に対するどれだけテストしたかを示す仕様カバレッジ(要件カバレッジ)など、いくつか種類がある。\nテスト・カバレッジは網羅率や被覆率とも呼ばれる。\n／＊／\nコード・カバレッジ(code coverage)とは、テストの対象となるプログラムのソースコード全体の中で、テストを終えた、あるいはテストしようとしている箇所の割合のことである。\nコード・カバレッジはコード網羅率やコード被覆率とも呼ばれる。\nコード・カバレッジはテスト・カバレッジの中で最も代表的なテスト指標である。\n／＊／\n行カバレッジ(line coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべてのコード行を少なくとも一回実行するよう、テストケースを用意するものである。\n言い換えると、すべてのコード行を少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準が行カバレッジである。\n／＊／\n関数カバレッジ(function coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての関数を少なくとも一回実行するよう、テストケースを用意するものである。\n言い換えると、すべての関数を少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準が関数カバレッジである。\n／＊／\nコール・カバレッジ(call coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての関数呼び出しを少なくとも一回実行するよう、テストケースを用意するものである。\n言い換えると、すべての関数呼び出しを少なくとも一回実行した場合、テスト・カバレッジを100パーセントと判定するカバレッジ基準がコール・カバレッジである。\n／＊／\nステートメント・カバレッジ(statement coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのコード内の命令文(statement)を少なくとも一回実行するよう、テストケースを用意するものである。\nステートメント・カバレッジは、命令網羅や命令文網羅、C0カバレッジとも呼ばれる。\n一般にプログラムは命令よりも分岐による問題が多いため、テスト手法としてステートメント・カバレッジはあまり有用ではない。\n／＊／\nブランチ・カバレッジ(branch coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての分岐においてすべての分岐の方向を少なくとも一回実行するよう、テストケースを用意するものである。\nたとえるなら「水曜日に女性客は割引」という条件に対し、割引になる場合と割引にならない場合の両方の結果を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。\nプログラム上の分岐個所をソースコードから目視で確認するのは大変であるため、通常、フローチャートやフローグラフと呼ばれる図法で図示して分岐箇所や条件を確認することが多い。\nブランチ・カバレッジはステートメント・カバレッジと比べ、多くの問題を発見することができるが、テストケースの数が膨大となるため、構造が複雑で多くの問題が見つかりそうな箇所に限定してテストすると費用・時間の面で効率がよい。\nブランチ・カバレッジは、分岐網羅や判定条件網羅、ディシジョン・カバレッジ(decision coverage)、C1カバレッジとも呼ばれる。\n／＊／\nコンディション・カバレッジ(condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての開始と終了、および条件文の可能なすべての結果を少なくとも一回実行するよう、テストケースを用意するものである。\nたとえるなら「水曜日に女性客は割引」という条件に対し、水曜の場合と水曜以外の場合、および女性の場合と女性以外の場合を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。\nステートメント・カバレッジやブランチ・カバレッジよりもテストケースが多くなりやすいカバレッジ基準である。\nただし、コンディション・カバレッジは分岐の方向を考慮しないため、コンディション・カバレッジでテスト・カバレッジが100パーセントになるテストケースでも、ステートメント・カバレッジやブランチ・カバレッジではテスト・カバレッジが100パーセント未満になる場合もある。\nコンディション・カバレッジは、条件網羅や条件カバレッジ、C2カバレッジとも呼ばれる。\n／＊／\nディシジョン/コンディション・カバレッジ(decision/condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、ブランチ・カバレッジとコンディション・カバレッジを合わせたものである。\nたとえるなら「水曜日に女性客は割引」という条件に対し、水曜の場合と水曜以外の場合、女性の場合と女性以外の場合、および割引になる場合と割引にならない場合を確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。\nディシジョン/コンディション・カバレッジは、判定条件/条件カバレッジや判定条件/条件網羅とも呼ばれる。\n／＊／\n複合条件網羅(multiple condition coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムのすべての判定において、あり得るすべての結果の組み合せが少なくとも一回実行するよう、テストケースを用意するものである。\nたとえるなら「水曜日に女性客は割引」という条件に対し、水曜かつ女性の場合、水曜以外かつ女性の場合、水曜かつ女性以外の場合、水曜以外かつ女性以外の場合の四パターンを確認できればテスト・カバレッジを100パーセントと判定するカバレッジ基準である。\n／＊／\nパス・カバレッジ(path coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムにあり得るすべての制御パス少なくとも確認するよう、テストケースを用意するものである。\n一般的な規模のソフトウェアでもテストケースが膨大となるため、そのすべてをテストすることは現実的ではない。\nパス・カバレッジは、経路組み合わせカバレッジや経路組み合わせ網羅、C∞カバレッジとも呼ばれる。\n／＊／\nループ・カバレッジ(loop coverage)とは、コード・カバレッジにおけるカバレッジ基準のひとつで、テスト対象となるプログラムにあるすべてのループで、一度もループしない場合、一度ループした場合、複数回ループした場合をそれぞれ少なくとも一回ずつ実行するよう、テストケースを用意するものである。\nループとは繰り返し処理のことである。\nループによるソフトウェアの問題を見つけるためには、複数回ループした場合をより細かく場合分けするテスト戦略もある。\nたとえば、もっとも典型的な回数ループした場合、想定する最大回数より一回少なくループした場合、想定する最大回数ループした場合、想定する最大回数より一回多くループした場合などに場合分けするテスト戦略である。\n／＊／\n制御パステストは、要求仕様あるいは開発者の意図通りにプログラムが実装されているかを検証するものである。\nそのため、要求仕様や開発者の意図が誤っていた場合、制御パステストで問題を発見することはできない。\nここで開発者の意図とは、開発者が要求仕様をどのように解釈したかであり、要求仕様そのものではない。\nまた、本来あるべき機能がまるごとない場合も制御パステストで発見することは難しい。\nマルチヤスクや割り込みによる問題も制御パステストでは発見困難である。\nテスト・カバレッジを100パーセントに近づけるほど、テストにかかる費用や時間が等比級数的に増加するという問題もある。\nホワイトボックステストは数あるテスト技法のひとつであり、苦手な問題もあるため、そのソフトウェアにとって妥当なテスト・カバレッジを目標として設定することが重要である。",
"part_type": "part",
"localID": 24
},
{
"title": "ブラックボックステスト",
"description": "ブラックボックステスト(black-box testing)とは、プログラムの入出力の対応関係だけを注目し、プログラムが仕様通りに動作しているか否かを検証する手法である。\nそのため、プログラムの満たすべき品質が仕様となっていることが前提である。\n仕様があいまいな場合、ブラックボックステストをする前に、プログラムがどのような振る舞いをするべきか、仕様を明確にする必要がある。\nなお、ブラックボックステストをするうえで、プログラムの内部構造がわかっている必要はない。\nブラックボックステストには、同値分割や境界値分析などがある。\n／＊／\n同値分割(equivalence partitioning、equivalence class partitioning)とは、ブラックボックステストのひとつである。\n同値分割とは、入力値を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす技法である。\nたとえば、それぞれ1から99までの数値が入力できる二つの入力欄XとYがある場合、有効同値クラスと無効同値クラスの二つの部分集合に分ける。\n有効同値とはプログラムが期待する入力値のことである。\n上記の例では、XとYはどちらも1から99までの数値を入力することを期待しているため、有効同値は1から99までである。\n無効同値はそれ以外のすべての値である。\nXとYをそれぞれ1未満の場合、1以上99以下の場合、99を超過する場合の三つに分けると3通り×3通りで9通りのテストケースができる。\nさらに0はゼロ除算(division by zero)や無限ループなどエラーの原因となりやすいため、XとYの両方が0のテストケースも追加すると、計10通りのテストケースとなる。\n十通りのテストケースの具体的な値を例示すると、(X=-1,Y=-1)、(X=-1,Y=50)、(X=-1,Y=100)、(X=50,Y=-1)、(X=50,Y=50)、(X=50,Y=100)、(X=100,Y=-1)、(X=100,Y=50)、(X=100,Y=100)、(X=0,Y=0)である。\n有効同値は1から99までであるため、(X=50,Y=50)を(X=1,Y=1)や(X=99,Y=99)にしてもよい。\n同様に(X=-1,Y=-1)を(X=-100,Y=-100)にしたり、(X=100,Y=100)を(X=999,Y=999)にしてもよい。\n上記の例では、有効同値一つに対し、無効同値が九つではテストケースが膨大となる。\nそのため、実際のテストでは、なるべく不具合を見逃さないように無効同値のテストケースを減らす必要がある。\nたとえば、(X=-1,Y=-1)、(X=-1,Y=50)、(X=-1,Y=100)の三つのテストケースはいずれもXが1未満の場合のテストであるため、一つに減らす。\n同様に、(X=-1,Y=100)、(X=50,Y=100)、(X=100,Y=100)の三つのテストケースはいずれもYが99を超過する場合のテストであるため、一つに減らす。\nこのように、他のテストケースでテストしていないもののみを残して、テストケースを減らすことで、不具合を見逃す恐れを減らしつつ、テストの時間と費用を節約できる。\n／＊／\n境界値分析(boundary value analysis)とは、ブラックボックステストのひとつで、境界値近くを詳しくテストする技法である。\n境界値とは、無効同値と有効同値の間の値や、ある有効同値と別の有効同値の間の値などである。\nプログラムの不具合は、境界値付近に潜んでいることが多い。\nたとえば、仕様では「1以上」となっているところを誤って「1より大きい」と設定してしまったり、「99以下」とするべきところを「99未満」と設定してしまったりすることがありうる。\nそのため、たとえば有効な値が「10以上20以下」なら、有効な値の上限(20)と下限(10)に加え、有効な値の上限に近い無効な値(21)、有効な値の下限に近い無効な値(9)をテストする。\nさらに、有効な値の中央(15)と、エラーの原因となりやすい0を加えるとテストケースは6通りとなる。\n上記はプログラムが単純な場合の例であったが、実際のプログラムではデータが複雑に絡み合い、テストケースを網羅することが時間的制約やテスト担当者のスキルの面で難しいケースがある。\nその場合、良いデータと悪いデータを必ずテストするようにする。\nここでいう良いデータとは、利用者がよく使いそうな値、有効な値の上限と下限である。\nまた、悪いデータとは、-999999や0.0000001のような極端に小さいデータ、999999のような極端に大きいデータ、abcdefghijklmnopqrstuのような非常に長いデータ、無効な値などである。\n0は良いデータであるか、悪いデータであるかに関わらず、入力できる場合、必ずテストしたほうがよい。\n境界値分析は、限界値分析とも呼ばれる。\n／＊／\n原因結果グラフとは、プログラムに対する入力条件と、入力に対応するプログラムの動作を図示したグラフのことである。\n原因結果グラフは、原因効果グラフ、CEG(cause-effect graph)とも呼ばれる。\n／＊／\nデシジョンテーブル(decision table)とは、テスト対象プログラムの入力条件や入力データと、その結果の動作や処理を表にまとめたものである。\n表形式になっているため、文章で羅列されているよりも分かりやすく、どのテストをおこなったかも記録しやすい。\nデシジョンテーブルは、決定表とも呼ばれる。\n／＊／\n原因結果グラフ技法(cause-effect graphing technique)とは、原因結果グラフとデシジョンテーブルを使って、有効なテストケースを抽出する方法である。\n仕様から原因結果グラフを作成し、完成したグラフをディシジョンテーブルに変換する。\n原因結果グラフをディシジョンテーブルに変換することは難しいため、自動変換ツールで変換することが多い。\n／＊／\n状態遷移テスト(state transition testing)とは、ブラックボックステストのひとつで、テスト対象プログラムがどのような状態を持ち、どのような条件やイベントで、他の状態に遷移するかを検証するテストである。\nたとえば、入力待ちの状態で入力された場合、処理中の状態に遷移するかを検証するものが状態遷移テストである。\n状態遷移テストにより、期待しない状態に遷移する不具合や、遷移自体が起こらない不具合を見つけることができる。\n状態遷移の図表で表現する方法として、ステートマシン図(state machine diagram)などの状態遷移図(state diagram、state transition diagram)や、状態遷移表(state transition table)などがある。\nステートマシン図は状態マシン図とも呼ばれる。\n／＊／\nランダムテスト(random testing)とは、事前にテストケースを考えず、行き当たりばったりに入力や操作をおこなうテスト手法である。\nランダムテストは、事前に同値を分割したり、境界値を分析したりする必要がない、荒っぽい方法であるが、このテスト方法でもかなりの数の不具合を見つけられる場合がある。\nセキュリティテストでは、ファズテスト(fuzz testing)やファジング(fuzzing)と呼ばれるランダムテストが用いられている。\nファズ(fuzz)とは、予測が困難な入力データのことである。\nただし、同値分割や境界値分析などの方法でなければ、見つけにくい不具合もあるため、セキュリティテスト以外ではランダムテストは推奨されていない。\nランダムテストは、アドホックテスト(ad hoc testing)、ゲリラテスト(guerrilla testing)、モンキーテスト(monkey testing)などとも呼ばれる。\n／＊／\nエラー推測(error guessing)とは、ブラックボックステストのひとつで、経験から知られている不具合が起こりやすいパターンからテストケースを作る方法である。\nたとえば、0やnull、ヌル文字、空文字列などはエラーが起きやすいデータのため、テストしたほうがよい。\n数値を入力する箇所では小数や指数もエラーが起きやすいデータである。\nエラー推測は、テスト担当者の知識や経験、想像力、洞察力に左右されるが、同値分割や境界値分析などで見つけられない不具合を検出することもある。\nそのため、エラー推測は、同値分割や境界値分析など併用が有効である。",
"part_type": "part",
"localID": 25
},
{
"title": "探索的テスト",
"description": "探索的テスト(exploratory testing)とは、ソフトウェア・テストの方法のひとつ。\n記述的テストと呼ばれる伝統的なソフトウェア・テストでは、事前に文書で定義したテストケースを順番にテストする。\nそのため、テストケースを記述することに時間がかかり、テストを実行する時間が削られるという問題があった。\n探索的テストではテストケースを書くことを重視せず、テスト対象となるソフトウェアについて学習し、事前・直前のテスト結果やテスト時のソフトウェアの振る舞いから臨機応変にテストするものである。\nここでいう学習とはソフトウェアを実際に動かして学ぶだけではなく、仕様書やソースコードを読んだり、既存のテスト結果を確認したり、ソフトウェアの開発者と対話することも含まれる。\n探索的テストの具体的な手順としては、まず何がテストの合否を決めるか、その判断基準を決める。\n次にテスト対象となるソフトウェアからテストすべき機能を列挙する。\nテストすべき機能のリストアップが終わったら、危なそうな機能や操作などを列挙する。\nこうしてリストアップされた機能や操作に対し、臨機応変にテストし、判断基準に照らし合わせ、不具合か否かを確認する。\n上記のような探索的テストを複数回おこなう場合、工夫を加えることでさらに不具合の発見を増やすことができる。\nたとえば、テスト担当者が複数いるならお互いのテスト担当範囲を交換したり、複数の環境で動作するソフトウェアなら環境を変えてテストするなどである。\nただし、ユーザビリティテスト以外の非機能テスト、たとえば性能テストや負荷テスト、セキュリティテストなどでは、探索的テストはテストケースを記述するテストと比べ、あまり不具合を見つけられないという欠点がある。\nテスト対象となるソフトウェアについてよく知っているテスト担当者が利用者の視点でテストをすることが探索的テストといえるため、ユーザビリティテストでは記述テストと比べ、多くの不具合を見つけやすい。\n探索的テストは、もともとアドホックテストと呼ばれていたが、アドホックテストがランダムテストを意味するようになったため、探索的テスト、あるいは探索型テストと呼ばれるようになった。",
"part_type": "part",
"localID": 26
},
{
"title": "単体テスト・結合テスト",
"description": "単体テストとは、関数や手続きなどの最小単位(モジュール)でプログラムを動作して内部設計通りに動作するか検証する工程である。\nソフトウェアは規模が大きくなると、指数関数的に複雑になるため、問題が起きている箇所を特定することが難しくなる。\nそのため、できるだけ狭い範囲に絞って検証することで必要な労力を抑えることができる。\n単体テストはこの原理に沿ったテストである。\n単体テストは、ユニットテスト(unit testing)、モジュールテスト(module testing)、単体試験とも呼ばれる。\n／＊／\n結合テスト(integration testing)とは、複数のモジュールを結合して動作を検証する工程である。\n結合テストの主な目的は、モジュールとモジュールの間でインターフェイスやデータの受け渡しが、外部設計通りに動作しているか検証することである。\n単体テストがひとつひとつのモジュールが正常に動作しているかコンポーネントの細部を検証しているのに対し、結合テストはコンポーネント間の細部を検証している。\n何をテストしているかが異なるため、単体テストと結合テストのどちらか一方を省略することはできない。\n建築にたとえるなら、単体テストは建築材料の品質を検証しているのに対し、結合テストは建築材料で作られた壁や床を検証している。\n建築材料の強度が基準に満たない場合も、水平になるよう設計された床が斜めに傾いている場合も、どちらも建築物として適切ではない。\nただし、ソフトウェア開発において、単体テストの範囲が広い場合、単体テストと結合テストの区別が難しいこともある。\n結合テストはI&T(integration and testing)、結合試験とも呼ばれる。\nまた、粒度や目的に応じて、モジュール結合テスト、機能結合テスト、サブシステム結合テストなどと呼び分けられることもある。\n／＊／\n総合テストとは、定められた環境で要件定義や外部設計の内容を実現できているか否かを総合的に検証するテストである。\n結合テストで外部設計の内容を満たしていることを確認したプログラムを、そのプログラムするハードウェアやネットワーク、利用者端末など、本番と同じ環境を用いて検証する。\n本番と同じ環境を用意できない場合、本番に近い環境で総合テストを行う場合もある。\n総合テストで検証する項目は大きく機能要件と非機能要件に分けられる。\nまた、総合テストでは仕様で想定していない状況や利用者の誤操作などを踏まえてシステムの不備を検証することもある。\n総合テストは、システムテスト(system testing)とも呼ばれる。\n／＊／\n受け入れテストとは、作られたプログラムが業務に使えるかを検証するためのテストである。\n単体テストや結合テスト、総合テストなどが開発者側がおこなうテストであるのに対し、受け入れテストは利用者や購入者が主体となって検証する。\nまた、下請けから納品された成果物を元請けが検収することを受け入れテストと呼ぶ場合もある。\n受け入れテストは、受け入れ試験、検収テスト、承認テスト、OAT(operational acceptance testing)、ORT(operational readiness testing)、OR&A(operations readiness and assurance testing)などとも呼ばれる。\nまた、業務部門の利用者やシステム管理者など、誰が承認にするのかによって、ユーザー受け入れテスト、運用受け入れテストなどに分類される。",
"part_type": "part",
"localID": 27
},
{
"title": "メタテスト",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "メタテストとは",
"description": "メタテストとは、テストをテストすることである。\nメタテストはコンピュータでソフトウェアを実行したり、ソースコードを見直したりしなくても実行できる。\nたとえば、仕様書のような重要な書類がどこにあるか分からず、いつ仕様書を見つけられるか見通しも立たない場合、その組織の開発工程に問題があることは容易に想像できる。\nまた、進捗の遅れているコードほどテストしないような開発工程は、綿密にテストすべきコードほどテストしていないため、開発工程に問題があると考えられる。\nあるいは、プログラムに不具合があると担当した開発者に罰則を与えたり、不具合を見つけたテスト担当者や不具合をすぐに修正した開発者に恩賞を与えたりすると、罰則を恐れて不具合を隠蔽したり、恩賞を得るためテスト担当者と開発者が結託して意図的に不具合を作ったり、不具合の発見した時期を偽ったりするなどの弊害が考えられる。\n上司や顧客に対し、進捗が実際よりも良いよう見せるため、発見した不具合の数や重要度の記録を改ざんすることが常態化している場合、その開発組織の文化に問題があると考えられる。\nこのように「ソフトウェア開発で取り扱っている情報の質」に関する情報を知り、適切に使うことで、開発やテストの効率を大幅に改善し、費用や時間を節約することができる。\nそのため、テスト結果の報告書に重要な情報がすべて記載されていると思わず、どのようにテストが実施され、その裏で何があるか直接観察して検証することが望ましい。\nなぜなら、テストの手順を文書に明記してあったとしても、必ずしもテスト担当者がその内容を守っているとは限らないからである。\n特にテスト結果の報告書に記載されているデータが整いすぎている場合、虚偽のテスト結果ではないか疑ったほうがよい。\nただし、開発者やテスト担当者を過度にテストすることは開発工程に悪影響を及ぼす恐れがあるため、適切な範囲でおこなうことが望ましい。",
"part_type": "part",
"localID": 29
},
{
"title": "ドッグフードテスト",
"description": "ドッグフードテストとは、開発した製品を開発者自身が実際に使用するテストである。\nドッグフードテストは、ドッグフーディング(dogfooding)とも呼ばれている。\nドッグフードテストの目的は、開発した製品に対し、開発者がどの程度自身があるかを確かめるためである。\nたとえば、自動車のステアリングとブレーキ制御に関する組込みソフトを作った場合、その製品を搭載した車両に開発者を運転手として乗せ、テストコースで実際に走行してもらう。\nもし、開発した製品に自信がないのなら、あまり速度を出さなかったり、すぐに運転をやめたりするはずである。\n開発者によっては向こう見ずだったり、臆病だったりするため、ドッグフードテストのみで製品の良否を確かめるのは不適切だが、メタテストの出発点としては有用である。\nなお、ドッグフードテストの名前は、一説によると「人知類が犬知類の食糧を作るなら、まず作った本人が食べろ」という故事に由来するとされている。",
"part_type": "part",
"localID": 30
},
{
"title": "獲得時間",
"description": "ソフトウェア開発において、獲得時間とは、要件定義書や仕様書のレビューによって見つかった不備・欠陥・不具合などの数から算出した、失わずに済んだ時間である。\nたとえば、仕様書をレビューし、50個の欠陥が見つかったとする。\nもしプログラムを実装後に欠陥を直した場合、ひとつの欠陥を直すのに平均で4時間かかるとすると、すべての欠陥を修正するのにおよそ200時間かかる。\n仮にレビューが40時間で終わったのなら、差し引き160時間を失わずに済んだことになる。\nこのように獲得時間という数値で計測することで、レビューの効果を目に見える形にすることができる。\nなお、獲得時間を計算する際、レビューによって仕様書が適切な体裁や内容になることにより、ソースコードから仕様を確認する手間が省ける時間は考慮しない。",
"part_type": "part",
"localID": 31
}
],
"localID": 28,
"expanded": true
}
],
"expanded": true,
"localID": 18,
"description": "流用可能"
}
],
"localID": 15,
"expanded": true
}
],
"expanded": true,
"localID": 0,
"description": "流用可能"
}
]
最終更新：2019年01月14日 20:38
