2/11テスト
今週から真面目に勉強しようかなという気持ちでいたら時間がまるで無かったのでとりあえずシラバスだけでも抑えていきたいので雑にまとめている
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf
1.1 テストの必要性
エラー（人間の誤り）
欠陥（作成物の誤り、フォールト・バグ）
故障（欠陥が露出すること）
故障の原因→欠陥
欠陥の原因→エラー
故障は環境要件によっても起きる
→外部要因（自然現象とか）がファームウェアの誤作動を起こす、ハードウェアの構成変更がソフトウェアの動作に影響をあたえる
1.2 テストとは何か
デバッグ→故障の原因を突き止め、解析し取り除く活動
→テスト自体は故障の発見が主で、デバッグは開発側
→デバッグで修正された故障は再テスト
開発担当者→デバッグに責任をもつ
テスト担当者→テストに責任を持つ
1.3 テストの7原則
原則 1：テストは欠陥があることしか示せない
→悪魔の証明は無理
原則 2：全数テストは不可能
→入力が数値なら、全部試すのは無理だよね
原則 3：初期テスト
→はやめにテストは開始するとよい
原則 4：欠陥の偏在
→欠陥は寄っていることが多い
原則 5：殺虫剤のパラドックス
→同じテスト繰り返すと効果が薄くなる（新しい欠陥がでない）
原則 6：テストは条件次第
→条件によってテストは変わる、落ちたらやばいシステムとそうでもないシステムとか
原則 7：「バグゼロ」の落とし穴
→欠陥潰しても結果的に使えなかったらダメ
1.4 基本的なテストプロセス
以下で構成される
・計画とコントロール
・分析と設計
・実装と実行
・終了基準の評価とレポート
・終了作業
■テスト計画作業
→テストの目的決め＋それに併せてテストの仕様決め
■コントロール
→進捗と計画を比較してさてどうしよう的な
→プロジェクトの目的・指名に合致させるために取る対策も含む
■テストの分析と設計
→テストベースのレビュー
※テストベース・・・テストケースの素材となる各種の情報源のこと。
→テストベース/テスト対象の試験正評価
→テストベースの分析に基づいてテスト条件を識別・優先順位をつける
→優先順位をつけるのはテスト条件に対してか？
※テスト条件・・・テストケースによって検証できるもの。可用性はテスト条件なのか？データをX件まで投入しても正常に稼働する、という要件はテスト条件か？
→高度なテストケースの設計と優先順位付け
※高度なテストケース・・・抽象度の高いテストケースのこと
→必要なテストデータなんなのか考える
→テスト環境の設計と必要なリソース/ツールを考える
■テストベースとテストケース間でのトレーサビリティを作成する
→トレーサビリティを作成するとは？？？
→テストケースの元になるテストベースを判断できる状況を作ろうね、くらいの意味か？
■テストの実装と実行
テスト手順の仕様化/テストケース決め/テスト環境のセットアップ～テストの実行
※テストハーネス・・・スタブとかドライバが組み込まれてる環境？このフェーズで作ることも有る
→テストスクリプト書くのもここ
→テスト手順をベースにテストスイートも作る
※テストスイート・・・何かの基準（テスト対象とか目的）でテストケースをまとめたやつ。自動化テストでのテスト実行単位
→テスト環境セットアップの確認（確認だけ？）
→テスト自体の実行
→テスト実行結果の記録
★記録するもの★
→テスト対象のソフトウェア
→テストツール
→テストウェア
→の、IDとバージョン
→実行結果と期待される結果の比較
→比較してなんか違ってたらインシデント。インシデント分析する
→比較して一致しないやつがきえるまで繰り返す
→確認テスト（前ダメだったやつのもっかいテスト、回帰テスtお）
■終了基準の評価とレポート
→テストの実行十分かチェック
→各テストのレベルでやる（★レベルとは？）
→主な作業
→テスト計画で定義した終了基準と比べる
→もっとテストしたほうがよさそうか、終了基準変えたほうがいいかチェック
→ステークホルダにテストサマリレポートかく
■終了作業
→活動の全データをあつめる
→いつやるか
→リリース時、プロジェクト完了（打ち切り）時、マイルストン、保守版のリリースとか
→何するか
→ちゃんとリリースされたかチェック
→インシデントレポートは終了でいいのか（終了とは？全部解決とするかんじ？）
→未対策の欠陥は変更記録に乗せる
→変更記録とは？
→システム受け入れようのドキュメントつくる
→テストウェア/テスト環境/インフラをドキュメント化する（またこんどつかえるように）
→テストウェアを保守部門になげる
→感想戦（あれのすすめかたがダメだったみたいの）をまとめる
→感想戦の結果を今後の改善（テストの成熟度）に活かせるようにする
1.5 テストの心理学
→開発とテスト/レビューのマインドセットは違う
→独立した視点でのテストができるぞ的な
→どのレベルのテストでも実施できる
→開発者のバイアスを排除できる
エラー・欠陥は建設的に扱おう
→ダメなとこを探す、ではなく改善点を探すみたいな 気持ちで
→テスト側と開発側での対立構造にしない
→テスト担当者とその他のコミュニケーション改善には・
→協調姿勢。ゴールはあくまで欠陥の検出とかではなく高品質のシステム
→指摘は中立に、担当者を避難しない。
→自分・他人が何を理解しているのか確認する
1.6 行動規範
・公人・・・テスト担当者は公人として行動すること
・顧客と雇用主・・・"公人"して行動しつつ顧客と雇用主に最大の利益を
・プロダクト・・・成果物はいいものを出さないとだめ
・判断・・・判断は誠実かつ自分でしたやつにしろ
・マネジメント・・・マネージャ・リーダマネジメントに対する倫理的なアプローチに同意・推進しないとだめ（？？）
・専門職としての地位・・・専門職としての地位向上に務めなければならない（なんだこれ？）
・同僚・・・同僚に対して公正・協力的であれ
・自身・・・学習し続けろ、倫理的なアプローチを取れ
2. ソフトウェアライフサイクルを通じてのテスト
2.1 ソフトウェア開発モデル
→開発モデルによってテストへのアプローチは変わるよ
2.1.1 V字モデル（シーケンシャル開発モデル）
V字モデルのテストレベルは4つ
・コンポーネントテスト（ユニットテスト）
・統合テスト
・システムテスト
・受け入れテスト
いわゆるウォーターフォール
→かならずしもこのテストレベルではない
→コンポーネントテストのあとにコンポーネント統合テストがあったり
→成果物（例えば、ビジネスシナリオ、ユースケース、要求仕様、設計ドキュメント、コード)は、上記テストのベースになる
→検証・妥当性確認・初期のテスト設計は成果物の開発中に実施
2.1.2 イテレーティブ・インクリメンタル開発モデル
システムの要件、設計、構築、テストを繰り返す
→プロトタイピング、RAD、RUP、アジャイル開発モデル
RAD→ソース書かないでGUIでアプリつくっちゃおうぜ的なやつ
RAP→アジャイルみたいの？ユースケースごとにイテレーション
★回帰テストが大事★
★検証・妥当性確認は各イテレーションで実施できる★
★妥当性確認って何？何に対する妥当性？テスト？仕様？
★検証って何？
2.1.3 ライフサイクルモデルの中のテスト
いけてるテストを行うときの特徴
→開発の各活動と対応したテスト活動を
→各テストレベルにはそれぞれ特有の目的を
→テストレベルのテスト分析・設計は対応する開発活動に併せて実施
→開発ライフサイクルでドラフトのドキュメントが手に入ったらテスト担当者はレビュー
テストレベルはプロジェクト・システムアーキテクチャの特性によって統合・再編成可能。
2.2 ★★テストレベル★★
★そもそもテストレベルって何？
「テストの対象物の粒度」によって区別するテストの分け方
各テストレベルで何を抑えるか
→一般的な目的
→テストベース（テストケースを出すのに見る開発成果物）
→テスト対象
→典型的な結果・故障
→テストツールの必要性、環境
→特定のアプローチ？？？？各テストレベルで特定のアプローチを抑えるという日本語がわからん
→責任割当て？そのテストレベルに対して誰が何の責任を持つの？みたいな話か？
「もし、そのようなデータがシステムの一部ならば、システム構成データのテストはテスト計画中に考慮されるべきであ
る。 」
→そのような？？？？？？どのような？？？？
→とりあえずなんかのデータがシステムの一部なら、そのデータのテストはテスト計画中に考慮しようねという話か？
2.2.1 コンポーネントテスト
★テストベース
・コンポーネントの要件
・詳細設計★
・ソースコード
★典型的なテスト対象
・コンポーネント
・プログラム
・データ変換・移行プログラム
・テストベースモジュール→わからん 用語集に乗ってねえ
★目的
欠陥の摘出・機能の正しさの検証
システムの他の部分と切り離したテストができる
スタブ・ドライバ・シミュレータなどを使う
以下も含まれる
・機能のテスト
・特定の日機能的な特性（テストに特性を含む？？？？）
・リソースの動作（メモリリークの検出とか）。動作というより動作に対する検証・検出か
・ロバストネステスト→脆弱性のテストのこと？異常系突っ込んで壊れないかどうかとか？SQLインジェクション対策できてるよね？みたいな？
・構造テスト→ホワイトボックステストのこと
何をベースに作る？
・コンポーネントの仕様
・ソフトウェアの設計
・データモデルなどの成果物
普通は開発環境でコードを対象にやる
開発者を巻き込んで実施
★欠陥は真面目に管理するというよりその場でなおしちゃう
コーディングまえにテストケースを準備して実行を自動化
→TDD（テストファースト、テスト駆動開発）
2.2.2 統合テスト
★テストベース
・ソフトウェア・システム設計
・アーキテクチャ
・ワークフロー→業務の一連の処理手続を定義したもの
・ユースケース→誰が何してどうなる、みたいな？
だいたい結合テストと同じ意味でいいらしい雰囲気
★テスト対象
・サブシステムのデータベース実装
・インフラ
・インターフェース
・システム構成・構成データ
ソフトウェアとインフラ・ミドルウェアの間とかソフトウェア間のインターフェースとかのテスト
★さらに細分化
・コンポーネント結合テスト
→ソフトウェアコンポーネント間の相互処理をテスト。コンポーネントテストの後にやる
→リポジトリとサービスの結合とかそういうこと？
・システム統合テスト
→システム間とかハードとソフト間とか
→システムテストの後にやる（ことが多い）。システムテストってなんだ
→統合されたシステムが、特定の要件を満たすことを実証するためのテストのプロセス
システムテストの後にシステム統合テストを実施するのは、片方の開発組織はインタ
ーフェースの片方しか制御できない
どういう意味？一応リスクとして考慮されるべきかもらしい。でもわからん
→ビジネスプロセスは一連のシステムに含まれるワークフローとして実装する
→別のプラットフォームで動作するかどうか、とか
→結合の範囲が大きくなるとどのコンポーネント、システムに欠陥があるのか絞り込みづらい★
★体系的に統合する戦略のベース
→システムアーキテクチャ（トップダウン、ボトムアップ）
→機能的タスク
→トランザクション処理シーケンス
→その他システムの携帯やコンポーネント
★とりあえずの切り分けをしやすくするにはちょっとずつ結合する
→一気に全部結合することをビッグバン統合という
★ビッグバン統合★
★ビッグバン統合★
★ビッグバン統合★
★ビッグバン統合★
★ビッグバン統合★
特定の非機能特性(例えば性能)のテストは機能テストと同様に統合テストに含むことがある。★
統合の各段階で、テスト担当者は統合のみに集中する
→モジュール同士の統合だったら担当者はモジュール間のインターフェースだけきにする
→コンポーネントの機能はコンポーネントテストで確認できてる
→コンポーネントテストが甘いとカオスになるぞ
テスト担当者が統合計画の構造や影響を理解しているのが理想
→コンポーネント・システムの構築前に統合テストを計画すると、テストの効率がいい感じになる順番でコンポーネントを構築できる
→統合テストで分割できる単位で実装してくと効率いいよね的な
2.2.3 システムテスト
★テストベース
・システム要求仕様もしくはソフトウェア要求仕様
・ユースケース
・機能仕様
・リスク分析レポート
いわゆる総合テストか
★テスト対象
・システム、ユーザとオペレーションマニュアル（ユーザはテスト対象なのか？）
・システム構成・構成データ
★本番環境とできるだけ同じ環境でテストする必要がある★
以下の要求仕様に基づいたテストがある
・リスク
・ビジネスプロセス
・ユースケース
・その他システム動作
（を高レベルで記述したテキスト・モデル）
・OSとの相互作用
・リソース
（などの要求仕様）
機能要件と非機能要件と★データの品質特性を検証する必要がある
→担当者は、不完全だったりドキュメント化してない要件も扱わないといけない
★機能要件の検証はブラックボックステスト★
デシジョンテーブルとか
メニューの構造とかWebページのナビゲーションのテストはホワイトボックス
→こういうのホワイトボックスっていうんだな
★独立したテストチームが請け負うことが多い★
2.2.4 受入テスト
★テストベース
・ユーザ要件
・システム要件
・ユースケース
・ビジネスプロセス
・リスク分析レポート
★テスト対象
・統合が完了しているシステム上のビジネスプロセス
・操作と保守プロセス★
・ユーザの利用手順
・書式（書式？ドキュメントに対する試験、レビューみたいな話？）
・レポート★
・構成データ
顧客・利用者が実施しがち、ステークホルダが参加することもある（顧客も利用者もステークホルダじゃないのか？）
★ゴール
・システム全体、一部、非機能的な特性が正しいことを確認すること
・主目的は、欠陥の摘出ではなく「ちゃんと動くよね！稼働できるよね！」の確認
・最終テストではない
・受入テスト→大規模な統合テスト、みたいな手順もある
いろんな場面で行われる。
・COTSならインストール・統合時点でやる
・コンポーネントの使用性の受入テストはコンポーネントテストで実施する
→よくわかんない、ライブラリの受入テストは開発者というよりユーザがやるべきでは
→このタイミングで勝手に欠陥治したらやばい気が
・機能拡張分はシステムテスト前に実施する★
以下の形がある
・ユーザ受入テスト
→ビジネス上ちゃんと使えるかユーザがチェック
・運用受入テスト
→管理者がやる★
→バックアップ/リストアちゃんとできるか
→災害時復旧できるか
→ユーザマネジメント（ができるか？）
→保守（のしやすさ？）
→データ負荷と移行（がちゃんとできるか、しやすいか）
→データ負荷って何、いっぱい投入できるか？みたいな？
→ググってもろくに引っかからない単語はなんなんだろ
→セキュリティの脆弱性の定期的チェック
→定期的なチェックは受入テスト扱いになるんだな
・契約による受入テスト、および規定による受入テスト
→契約による受入テスト→契約書に書いてある判定条件に従って検証
→契約による受入テスト→契約者同士が契約に同意したら受入条件が決まる★
→規定による受入テストは法律とか安全基準に合致してるか検証する★
・アルファテスト、ベータテスト（あるいはフィールドテスト）
→アルファテストは開発組織でやる
→ベータ、フィールドは顧客もしくは潜在顧客
ラグナロクオンラインのテストをガンホーがやるのはアルファ
プロンテラに入るとサーバから切断されるのがベータ
→顧客のサイトにシステムをセットする前後にテストが必要なシステムでは工場受入テストとかサイト受入テストとかいう場合がある
→よくわからん
2.3 テストタイプ
→テスト目的に焦点を当てている
・ソフトウェアの機能
・信頼性、使用性などの非機能的な特定
・構造やアーキテクチャ
・欠陥が修正されてる、意図しない変更がないこと
ソフトウェアのモデルを作って構造テストや日機能テスト、機能テストで使うことがある
2.3.1 機能のテスト
・システムが何をするのか＝機能
※フィーチャ＝ドキュメントに書いてあること、テスト担当者が理解していること
→と、特定のシステムの相互運用性に基づいている
→機能テストはすべてのテストレベルで実施する★
昨日からテスト条件とテストケースの抽出
→しようベースの技法を使える
機能テストはブラックボックステスト
・セキュリティテストは機能テスト★
相互運用性（接続性）テストも機能テスト
2.3.2 機能以外の特性のテスト（非機能テスト）
・性能テスト
・ロードテスト
・ストレステスト
・脂溶性テスト
・相互運用性テスト（どっちだ、どっちもか）
・保守性テスト
・移植性テスト
→何をするのかではなくどのように動作するのか
→すべてのレベルで実施できる★
→多くの場合ブラックボックステスト
2.3.3 ソフトウェアの構造・アーキテクチャのテスト（構造テスト）
構造テスト＝ホワイトボックステスト
すべてのレベルで実施できる★
→仕様ベースの技法を適用後に実施するのがいい
→構造をどれくらい網羅したかで、テスト実施の完全性を評価する
構造テストはシステムのアーキテクチャをベースにする
構造テストのアプローチは
・システムテスト
・システム統合テスト
・受入テスト
で適用できる
2.3.4 変更部分のテスト：再テストおよび回帰テスト
→欠陥を修正
→ちゃんと治ったかの確認が確認テスト
→デバッグ（欠陥の修正）はテストの活動ではない（開発の活動である）
回帰テストは変更で作っちゃった欠陥とか新しい別の欠陥を見つけるためにテスト済みのプログラムを何回もテストすること
→ソフトウェアとか動作環境が変わったら実施する
→範囲は正常に動いてたソフトウェアから欠陥が見つからないリスクを基に決める
→確認、回帰テストのためにテストは繰り返し実施できるようにするう
回帰テストはすべてのテストレベルで実行可能
→テストスイートは何度も実行し、少しずつ内容が変わるのが普通
2.4 保守テスト
システム・構成データ・動作環境は修正・変更・拡張される（ことが多い）
→事前のリリース計画は保守テストの成功に欠かせない
→リリースと修正パッチは区別する
→現在稼働しているシステムに実施するほし
→なんか変わったらやる
→システム・ソフトウェアの変更、別システムや別ソフトウェアへの移行、回収（改修？）
★変更作業
・計画に従った拡張（リリース計画）
・修正や緊急変更
・OSとかミドルウェアのアップグレード
・COTSソフトウェアのアップデート
・OSのパッチとか
・動作環境の変更とか
★移行作業
・ソフトウェアだけじゃなくて新しい環境の動作テストも必要
→他のアプリケーションからのデータを移行する際には移行テストも必要（コンバージョンテスト）
長期間のデータ保有を要求されている場合は、データの移行作業や保管もテストの対象になる
保守テストでは
→変更部分のテストだけじゃなくて回帰テストも必要
→実施範囲は、変更のリスク・現実のテストの規模（？コストの話？）、変更の大きさに依存する
→変更の程度によって、すべてのテストタイプ・テストレベルに適用可能
変更による既存システムへの影響チェック＝影響度分析
→これで回帰テストをどれくらいやるか予測できる
→回帰テストスイートを決めるのに影響度分析を使うことがある
仕様が最新版ではない、仕様がない、ドメイン知識を持つテスト担当者がいない
→保守テストは難しい
★保守テストって保守活動がいい感じに進むためのテストだと思ってたんだけどどっちかって言うと保守活動の一環としてのテストなんだな
3. 静的技法
ソフトウェアの実行が不要
→レビュー＆自動解析（静的解析）
→レビューは成果物のテスト手段である
→動的テスト実行前に大きな効果がある
→動的テストより前に摘出した欠陥の修正は、動的テストで検出した欠陥の修正より”はるかに"安価
”あらゆる”ソフトウェア成果物はレビュー可能★
レビューの効果
→"欠陥"の早期摘出・修正
→開発生産性の恒常
→開発期間の短縮
→テストのコスト・時間をへらせる
→システムのライフサイクルを通じたコストを減らせる
→欠陥が減る
→コミュニケーションがよくなる
→機能や処理（要件とか）の抜けを見つけられる
→動的テストでは見つけづらい
→そもそも要件になってすらいないと動的テストの対処にならない
動的テスト→故障を探す
静的テスト→欠陥を探す
動的テストよりレビューのが簡単に見つけられる欠陥
→規格からの逸脱
→要件の欠陥
→設計の欠陥
→保守の不十分正
→インターフェース仕様の不正
3.2 レビュープロセス
3.2.1 公式レビューの活動
・計画
→レビュー基準を定義する
→人選する
→役割を割り当てる
→公式なレビューでは開始と終了の条件を定義する
→ドキュメントのレビュー対象を選定する
→開始基準をチェックする（より公式）
・キックオフ
→ドキュメントの配布
→目的・プロセス・ドキュメントの説明
・個々の準備
→準備としてドキュメントレビューする
→可能性のある欠陥・質問・コメントを書き出す
・実施/評価/結果の記録（レビューミーティング
→議論して結果・議事を文章で記録（より公式）
→欠陥について話す（なんなのか、どうすんのか）、欠陥を書き出す
→ミーティング中に実施、評価、記録をする。電子的なコミュニケーションの追跡をする
・再作業
→検出した欠陥の修正（ふつう作成者が実施）
→更新された欠陥のステータス記録（公式な）
・フォローアップ
→欠陥が処理されたかチェックする
→メトリクス収集
→終了基準のチェック（より公式）
3.2.2 役割と責任
・マネージャ
→レビュー実施者、スケジュールたててレビューの目的がいい感じ化判断
・モデレータ
→レビューの取りまとめ。レビュー計画、運営、フォローアップ、意見の仲裁★レビューの成功はこの人によることがおおい★ ★この人★
・作成者
→レビュー対象のドキュメントに責任を持つ人
・レビューア
→有る特定のバックグラウンドを持つ各個人・必要な準備の後レビュー対象物で気づいたことを示したり述べたりする。分野・プロセスの役割を代表する人として選ばれてあらゆるレビューに産科
・書記
→課題、問題点、未解決事項を記録する
いろんな視点から見たりチェックリストを使ったりすると効率が良い
→ユーザ視点で見てみたり、保守担当者視点でみたいr、テスト担当者、オペレータ目線で見たり
→問題点チェックリストに併せて見てみたりすると未発見の課題が明確になったり
3.2.3 レビューの種類
レビューの種類によって実施する順番が変わる
非公式レビューはテクニカルレビューの前、インスペクションは"顧客と実施する"ウォークスルーの前
★非公式レビュー
・決まったプロセスはない
・ペアプロとか設計、コードを技術指導てきにレビューすることがある
・レビュー結果をドキュメントすることがある★
・レビューアにより効果が様々である 非公式レビューとくゆうなのかこれは
・金・時間をかけずにそこそこの効果をだすのが主な目的
★ウォークスルー
・作成者が進行を手動★
・シナリオを元に同僚のグループが机上で処理を辿る事がある
→これ非公式っぽいけどウォークスルー？
・制約をつけないセッション
→レビューアの事前準備ミーティングを行う事がある
→指摘の一覧を含む、レビューレポートを準備することがある
→制約とは時間的な制約のことを言っているらしい
・作成者以外が記載者になることもある→なんのだ→作成者は進行とか説明とかするから指摘一覧とか議事録は書記にまかす（こともある）
→一人でMTGきて進行役やって終わった後全部把握してる人つよい→おれはむり
・極めて非公式なものから高度に公式なものまである
→非公式レビューと排他の関係ではない
→インスペクションは排他
→目的はソフトウェアの内容を学習、理解し欠陥を見つけること
→★学習・理解★
★テクニカルレビュー
・欠陥摘出には同僚や技術のエキスパート（そして管理者の場合も）が参加
→プロセスは定義してドキュメント化してある★あ★ら★か★じ★め★
・管理者の参加しないピアレビューとして進めることもある
→ピアレビュー→欠陥を識別・改善するために開発に携わる同僚が成果物をレビューすること
→インスペクション、テクニカルレビュー、ウォークスルーはピアレビュー
→peerは同僚とかそういう意味
→P2Pは同格のやつ同士が対等に通信を行う（サーバクライアントみたいな関係ではなく）
・経験を積んだモデレータ（★作成者ではなく星）が進行を手動するのがりそう
・レビューアが事前ミーtェイングを準備するう
・チェックリストを作ることが有る
・指摘一覧、成果物が要求を満たしているかの判定、指摘事項に関連する推奨事項を含むレビューレポートを準備する
・非公式から公式まで
・主な目的は
→ディスカッション
→判断を下す
→他の方法を評価する
→欠陥を見つける
→技術的な問題を解決する
→仕様、計画、規定、標準に準拠してるかチェック
★インスペクション
・経験を積んだモデレータが進行を主導
・同僚に拠るチェックが一般的
・各人の役割が決まっている
・メトリクス収集を含む
・規則やチェックリストを使って、形式に基づいたプロセスですすめる
・成果物受けいれに対する開始、終了基準を決める★★★
→誰にとって？顧客がいる場合顧客？
→顧客参加する？
・事前準備が必要
・レポート、指摘一覧を書く
・決まった形式のフォローアッププロセスがある
→プロセス改善も含まれる（場合がある）
・ドキュメント読む人を加えることも有る
・主な目的は欠陥の摘出★★
ピアレビューーーーーーーーーーーーーーーーーーーーーー
→仲間内でする場合はピアレビュー？
→顧客が参加したりする場合はピアレビューではない？
3.2.4 レビューの成功要因
・開始前に目的を明確にする
→大体のいろんなことの成功要因
・レビューの目的にふさわしい人に参加してもらう
→そうだ
・テスト担当者はレビューに寄付する価値あるレビューアであり、また製品について学ぶことでより早いテスト準備を可能にする
→テスト担当者もレビューア
→製品について学ぶとより早いテスト準備ができるゆ
・欠陥を見つけることは目的に合致しており、歓迎すべきこと
→不具合はっけんされてキレるのは間違ってるよ的な
→システムがもっとよくなったという気分で
・人の問題や心理的な要素も扱う（作成者にとってそれもプラスの経験にする）
→つくっててつまんない機能のレビューこそしっかりやるとか？
→あとスケジュールぱつぱつのときにつくったやつしっかりみたり
・レビューの結果は参加者の評価に使用しない
→評価者がレビューの結果を知らないレベルじゃないとむずくね
→レビューの結果＝成果物のある程度の評価
→成果物のある程度の評価＝作成者のある程度の評価
→いってることはわかる
・対象のソフトウェア・レビューアのタイプやレベルに最適のレビュー技術を適用する
→レビュー技術とは
・公式性が高いレビューはレビュー実施の技術教育を実施する
→誰にたいする？
→レビューに参加する人？
・管理者の支援がないときちんとレビューのプロセスがすすまない
→レビューの時間が計画になかったらできないよねみたいな
→プロジェクター買ってくれ！とか
・レビュー自体にレビューの方法を学んだりプロセス改善したりみたいな目的も有る★
3.3 ツールによる静的解析
静的解析の目的
→ソースコードやソフトウェアのモデルの欠陥を見つけること
→実行しない
→動的テストで摘出が難しい欠陥を見つけることが出来る
→絶対故障の原因にならない欠陥って欠陥あつかいなのかな
→なんかコンポーネントのバグだけどシステム全体で見ると問題なし、みたいな
→追加開発時に爆発するやつ
・静的解析は故障よりも欠陥を検出する
→動かさないから故障しないので
・静的解析ツールはプログラムコードだけではなく、HTML、XMLなども解析する
★効果
・テスト実施前の早い段階で欠陥を摘出する
→ようするに静的解析はテストではないんだな
→静的テストでぐぐったら静的解析のことだよみたいなのがでてきた
・複雑度の計測などのメトリクス測定で、欠陥がありそうなところ（コードとか設計とか）をはやめに警告できる
→入れ子が深すぎるメソッドに対してキレるやつとかあんのかな
・依存性・非依存性を見つける
・コードの設計や保守性を改善する
・開発中に学習することで欠陥を予防する
★摘出できる代表的な欠陥
・値を定義していない変数の参照
→リファクタリングすると残りがち
→何故か削除するのをおそれがち
→DIとか動きを理解してないと不安だよね
・モジュールやコンポーネント間のインターフェース不整合
・定義はしてあるが使わない、不適切に宣言されている変数
・デッドコード
・欠落した、誤ったロジック（潜在的な無限ループ）
→欠落とは
・過度に複雑な構造
→これできるツールあんまりしらない
→検索するとJSTQBの話がでてきて悲しい
→JTestとかいうのがあるとかなんとか
→https://www.techmatrix.co.jp/product/jtest/staticanalysis/index.html
・コーディング規約違反
・脆弱性
→開放してないメモリとかそういうの？
・構文違反
→コンポーネントテスト、統合テストの実施前・実施中に
→構成管理ツールへのチェックイン間際に
→開発担当者が使う
モデルの設計時に設計者が使う
渓谷メッセージがどちゃくそでるので有効に活用するには渓谷のとりあえ使いに注意
コンパイラには静的解析を支援してくれるやつがある
→メトリクスの計算とか
4. テスト設計技法
4.1 テスト開発プロセス
形式性はさまざま
→レベルはテスト、開発プロセスの成熟度、時間の余裕、安全性、法規制、人員に依存する
★何をテストするのか決める
→すなわちテスト条件をきめる
→ため、テストベースのドキュメントを分析する
→テスト条件は１つあるいは複数のテストケースで検証できる項目やイベントとして定義する
→定義できないものはテスト条件にならない
→テスト条件の例
機能・トランザクション・品質特性・構造的要素
テスト条件→仕様
→要件
のトレーサビリティが確立できるといい
→要件変更したときにテスト要件のカバレッジとか効果的な影響度分析が可能になる
→対策が必要なリスクに大きく影響をうける
→どういう意味？
→リスクの判定をしやすいみたいな話？
テストケースやテストデータはテスト設計で考え出して仕様化する
★テストケースとは
→テスト目的、テスト条件を網羅するために定義したもの
→入力データ群、実行の事前条件、期待結果★、実行後の条件★
期待結果はテストケース仕様の一部として作成が必要
→出力、データの状態や変化などテストにより発生する結果をしるす
→ちゃんと定義してないと間違ってるのにあってるっぽいからOKみたいなあつかいされる
→テスト実行前に定義するのが望ましい
テストケースはテスト実装にてテスト手順仕様として開発、実装、優先順位付けして実行順に並べる
→テスト手順→テストを実行する場合の一連の手順
→そのまんま
ツールを使ってテストする場合の実行手順はテストスクリプトとして定義する
実行スケジュールは
→回帰テスト
→優先順位
→技術的、論理的な依存性も考慮してきめる
4.2 テスト設計技法のカテゴリ
テスト設計技法の目的
→テスト条件、テストケース、テストデータの決定
ブラックボックス
→仕様ベース
→機能テストも非機能テストも
→内部構造についての情報を使わない
ホワイトボックス
→構造技法、構造ベース
→内部構造の分析に基づく
ブラックボックステスト、ホワイトボックステスト
→経験ベースのテストと組み合わせることも有る
仕様ベースのテスト設計技法の特徴
→対象となる問題、ソフトウェア、コンポーネントを定義する場合、
形式的、非形式的に関わらずモデルを使用する
→モデルから体系的にテストケースを導き出す
構造ベースのテスト設計技法の特徴
→ソフトウェアの構成に関する情報（コード、詳細化された設計情報）をもとにテストケースを導きだsう
→カバレッジをあげるためのテストケースを体系的に導ける
経験ベースのテスト設計技法の特徴
→知識や経験をベースにテストケースを導く
→ステークホルダの知識、使用法、環境
→類似した欠陥、存在する箇所の知識は情報源
4.3 仕様ベース/ブラックボックスのテスト技法
4.3.1同値分割
→意味のある単位で入力をぐうr－ぷに分割
→対象は無効なデータも含む
→出力、内部変数、時間に依存する値にも存在する
→同値分割の全ての領域をカバーするよに設計する
→あらゆるテストレベルで実施出来る★
→入出力のカバレッジの基準になる
→人力入力、インターフェース経由でのシステム入力、統合テストでのインターフェースパラメータにつかえる
4.3.2境界値分析
→グループの境界線上の動作はグループ内部での（協会ではない）動作よりもただしくないことがおおい
→協会には血管がありがち
→あるりょういきの最小、最大は境界値
→あらゆるテストレベルで適用できる
→欠陥摘出能力も高い
→詳細化された仕様は境界値の決定に役立つ
→ブラックボックス扱いされやすい
→タイミングやテーブルの範囲
4.4.3 デシジョンテーブルテスト
→論理的な条件を含むシステム要件の把握に有効
→内部設計をドキュメンとかするのに有効
→複雑なビジネスルールを記録するのに使うkと尾がある
入力条件や動作はbooleanであらわしがち
→トリガーとなる条件（全入力条件のtrue、falseの組み合わせになりがち）の組み合わせに対する処理で構成される
・各列は特定の条件の組み合わせを定義するびじねするーるとルールに対応した行動から構成される
→カバレッジはテーブルにおいて一ツの列が最低1回実行されたこと
→トリガーとなる組み合わせの全てを網羅すること
4.3.4 状態遷移テスト
状態に寄ってシステムは異なる動作をする
→動作は状態遷移図で表現できる
→現在の状態、状態間の遷移、状態を変える入力やイベント、状態遷移の結果起こる処理をテスト担当者が見える
→状態は別々で、区別できて、有限個
→状態遷移表は入力と状態の関係を示す
不正な可能性のある遷移の明確化
→代表的な遷移を網羅したりすべての状態を網羅したり、全ての遷移を実行したり、特定の遷移を実行させたり、不正に遷移しないことを確認したりするテスト設計が出来る
組み込みとかテクニカルオートメーションで使う
→特定の状態をもつビジネスプロセスのモデル化
→対話処理風呂ー
→を、テストするにも有効
4.3.5 ユースケーステスト
ユースケースをベースにする
アクターとシステムの相互作用を記述したもの
→ユースケース★
ユースケースは抽象的なレベルまたはシステムレベルで説明される
ゆーすけーすには事前条件がある★
→正常に動作する＝条件を満足させる
事後条件になるとユースケースがおわる
ｌｚ事後条件は、ユースケース完了後の出力結果、システムの最終状態
→メインストリームとなるシナリオが有る（通常）
→第かえシナリオも有る
どういう使われ方が多いかをベースにしてシステムのプロセスフローを記述したもの
→現実でシステムが稼働してる状態でプロセスフローの欠陥を摘出する場合に効果がある
→顧客・ユーザが参画する受け入れテストセ血型
→他のコンポーネントとのやりとりやインターフェースが原因では発生する統合時の欠陥を検出するのに効果がある →個別のコンポーネントテスで見つからないような
ユースケースからのテストケース設計は、他の使用ベースのテスト技法と組み合わせられる
4.4 構造ベース/ホワイトボックスのテスト技法
・特定の構造に着目
→コンポーネント
→ステートメント
→デシジョン（判定）
→分岐（ブランチ）
その他のパス（パス？）
(1) in software engineering, a sequence of instructions that may be performed in the execution of a computer program. [SSEV]
→一連の命令
→統合レベル
→コールツリー→モジュールが他のモジュールをコールするダイアグラム
→システムレベル
→メニューの構造、ビジネスプロセス、ウェブページの構造
→ビジネスプロセスを構造として捉えるとホワイトボックス？
4.4.1 ステートメントテストとカバレッジ
テストケースにより網羅(テスト設計、または実行)したステートメント数を全ての実行可能なステートメント数で割った数である。
→★行単位で実行された割合★
→C0
4.4.2 デシジョンテストとカバレッジ
→ブランチカバレッジと同義
判定結果の実施割合を評価
if分が1個あったらtrueとfalseの２パターンで100ーセント
→ブランチっていうくらいだから分岐の網羅率かな
if(a=="あうあう"){
}
だったらあうあうとあうあう以外の2パターン
if(a=="あうあう" || a=="はあーん"){
}
でも2パターン
あうあうもしくははあーん or あうあうでないかつはあーんでないの2パターン
はあーん
→いわゆるC1
4.4.3 その他の構造ベース技法
条件カバレッジ
→C2
・あうあう
・はあーん
・その他
の3パターン
複合条件カバレッジ
if(a=="あうあう" || b=="はあーん"){
}
aがあうあう で bがはあーん
aがnotあうあう で bがはあーん
aがあうあう で bがnotはあーん
aがnotあうあう で bがnotはあーん
の4パターン
★カバレッジが計測しやすいような設計をするといいぞ★
カバレッジの概念は他のテストレベルでも利用dケイル
→統合レベルでは
テストスイートでモジュール、コンポーネント、クラスwお実行したときの％がカバレッジとして表現できる
→はい
ツールを使うと効果が上がる
→コードのカバレッジ計測主導でやるのめちゃつらいな
ねむすぎ
4.5 経験ベースのテスト技法
効率にばらつきある
公式なアプローチの後に適用すると有効
・エラー推測
・ありがちな欠陥のパターンをリストアップして攻撃するようなテストケースを設計
→フォールト攻撃
欠陥や故障のリスト
→経験、入手可能な欠陥や故障のデータ、故障に対する一般知識から作る
★探索的テスト
テストチャータを基にしている
※テストチャータ→原則？テスト目的を明記したもの
仕様がなかったり不十分だったりスケジュールに余裕がなかったり他の形式的なテスト技法を保管する場合に効果が大きい
テストプロセスのチェックや極めて重大な欠陥を見つけるのに役立つ
テスト技法の選択
システムの種類、規則や標準、顧客や契約上の要件、リスクのレベルや種類、テスト目的、
入手可能なドキュメント、テスト担当者の知識、時間と予算、開発ライフサイクル、ユースケースモデル、様々な種類の
欠陥を摘出した過去の経験など多くの要素に依存する。
そうか・・・
5.テストのマネジメント
5.1 テスト組織
5.1.1 テスト組織と独立性
・俺が作って俺がテストする
・俺が作ってあいつがテストする
・俺が作ってあいつらがテストする
・俺が作ってお客様のテスト担当がテストする
・俺が作ってやばい奴がてセウトする
・俺が作って知らない奴らがテストする
複雑だったり安全性が最優先のソフトウェア開発
→複数のレベルでテストを実施する
→部分的もしくは全部独立したテストチームが担当するといい
→開発スタッフのテストは客観性が足りないので有効性に限界がある
独立したテストチームはテストプロセスを要求したり定義したりする権利がある
→が、プロセスに関する決定は偉い人の明確な要請を基に実施べき
独立したテストの利点
・先入観がない
・仕様策定昼夜実装中に想定通りか検証できる
欠点
・開発チームから隔絶されている
・開発担当者の品質に対する責任感が薄れる
・ボトルネック扱いされたりリリースが遅れて非難されたりしがち
ひどい
5.1.2 テストリーダとテスト担当者の作業
テストリーダ（テストマネージャ、テストコーディネータ）
→プロジェクト管理者、開発管理者、品質保証管理者、テストグループの管理者がやる
→大きいプロジェクトだとテストリーダとテストマネージャがいることがある
→テストリーダはテストの計画とかモニタリングとかコントロールとかする
テストリーダの代表的な作業
・戦略と計画を調整する
・テスト戦略をとかテストポリシーを策定したりレビューしたり
・テストの観点から他の活動に貢献
・テスト目的とリスクを考慮してテストを計画する
→アプローチの選択、工数、コストの見積もり、★リソースの獲得、テストレベル、テストサイクルの定義、インシデント管理計画
※テストサイクル→識別可能な単一のテスト対象のリリースに対し、テストプロセスを実行すること。
・テストの使用か、準備、実装、実行を開始する。開始基準、終了基準を満たしていることを確認する
・テスト結果やテストの進捗に基づいて計画を修正、問題の補正のために対策をとる
・構成管理をセットアップする→トレーサビリティ工場
・進捗の計測とか品質の検証のためにメトリクスを導入したりする
・自動化具合の決定
・支援ツール選んだりトレーニング企画したり
・テスト環境を決める
・テスト中に収集した情報をベースにレポートを書く
テスト担当者の代表的な作業
・テスト計画に対するレビュー
・試験性の観点で用件、使用、モデルを分析してレビュー
→これはソフトウェア自体なのかテストなのか
・テストしよう作る
・テスト環境作る
・テストデータ作ったりもらったり
・全てのテストレベルの実装と実行と記録と結果の評価と期待した結果との差異と文書化と
・必要に応じてテストコントロールツールやマネジメントツールやモニタ用ツールを使う
→これテスト担当者なんだな★リーダはあくまでセットアップするだけで
・自動化する（開発担当者や自動実行のエキスパートの支援が必要）
・コンポーネントやシステムの性能を必要に応じて計測
・他人の実施したテストのレビュー
マネージャとリーダの違いがわからんな
5.2 テスト計画作業と見積もり
5.2.1 テスト計画作業
計画はマスターテスト計画に分割しさらにテストレベルに応じたテスト計画に分けて文書化する
テスト計画作業は、組織のテストポリシー、テストの範囲、目的、リスク、制限、緊急度、試験性、使えるリソースなどの
影響を受ける。プ
連続的な活動でありライフサイクルの中ではずっとやる
→フィードバックに合わせてリスクの変化を認識し、計画を調整
5.2.2 テスト計画策定
テスト計画の活動には以下のものがある
・スコープとリスクを特定、テストの目的を識別
・包括的なアプローチの定 →テストレベっる、開始、終了基準
・取得、供給、開発、運用、保守での活動にテスト活動を統合、強調させる
・テスト対象を決めてどういう職務を実行するか決めていつテスト活動を進めるか決めて結果をどう評価するか決めていつ終わらすか決める
・テスト分析と計画の活動をスケジューリンスグする
・テスト実装実行結果の評価をすkジエジューリングする
・活動にリソースを割り当てる
・テストドキュメントの量、詳細sど、構成、テンプレートを決める
・テストの準備、実行、血管の解決、リスク問題のモニタリングやコントロールをするためのメトリクスを選ぶ
→この感じまったく経験したことないんだよな
・テスト準備や実行の再現性を確保する
→どのくらい手順を詳細化すれば良いか決める
5.2.3 開始基準
いつやるか、いつ準備できるか
・テスト環境の通う生徒準備
・テスト環境におけるテストツールの準備
・テスト可能なコードの可溶性
・テストデータの可溶性
5.2.4 終了基準
いつ終わるか、いつあらかじめ決めたゴールに達するか
終了基準。
・コード、機能性、リスクのカバレッジのような徹底ど
・欠陥密度や信頼性の見積もりち
・コスト
→金がないから終了しまーす、は模擬問題とかだとオッケーなんだよな
・残存リスク
→このバグは残っててもまあ大丈夫っしょ的な
→カバレッジ不足とか
→ここ作った人賢いからいいっしょ的な
・出荷時期などのスケジュール
→これもコストと同じ気分になるがok
お金ないし明日リリースだからやーんぴ
5.2.5 テスト見積もり
工数見積もりのアプローチは次の二つ
・」メトリクスベース
→以前のプロジェクトやる医女のプロジェクトのメトリクス、代表的な値をベースに見積もる
→なんか前作ったあれとおんなじようなやつでしょ？３人くらいだったっけ？
・経験ベース
→だいたい規模感的に２人月っしょ
工数みつも李ができたらリソースが決まる
→スケジュールが立てられる★
工数に影響を与える要素
・プロダクト自体の特性
→仕様がカオスだったら時間かかる
→斬新すぎるシステムだと時間がかかる
→求められる品質がやばいと時間がかかる
→でかいと時間がかかる、複雑だと時間がかかる
→あと信頼性とかセキュリティとかドキュメントとか
・開発プロセスの特性
→開発メンバー全員すげーアホなので全ステートメントが欠陥です→めっちゃ時間かかる やめちまえ
→あといけてるツールがあると短縮できるとか、時間のプレッシャーはなんだろ
→スケジュールパツパツ→テンパる→ミス増える→工数増えるみたいな？
→テス東女出力結果
→欠陥がどちゃくそ多いと工数増えるよね。修正も時間かかるし
5.2.6 テスト戦略、テストアプローチ
テストアプローチ→テスト戦略を実装すること
→テスト計画とテスト設計の中で定義され改良される
→一般的にプロジェクトのゴールとリスクアセスメントに基づく決定を盛り込む
→テストプロセスの計画、設計技法の選択とテストタイプの適用、開始、終了基準の定義を行うための出発点★
選択されたアプローチは
プロジェクトの状況
リスク
危険性と安全性
使用可能な試験とスキル
テクノロジー
システムの性質（カスタムメイドなのかcotsなのか）
テスト目的
法規制
とかを考えて決まる
cotsってよく出てくるな グラインドコアのイメージしかない
代表的なアプローチ
・分析的アプローチ
→緊急度が高いやつ先にやるリスクベースのテストとか
→ここでの分析はプロジェクトに対する分析でシステムに対する分析ではない感じ
・モデルベースアプローち
→故障率とか使用法に関する統計情報を使う確率的テストなど
→メトリクスで決めるやつ？
・方法論的アプローチ
→フォールトをベースにしたやつとかチェックリストをベースにとか品質特定をベースにとか
→経験則でありがちなパターンに沿ってやる感じ
・プロセス準拠、標準準拠アプローチ
→なんかの方法論に沿ってやる。アジャイル方法論とかうちの会社のやり方はこれ！とか
・動的で経験則に基づいたアプローチ
→つどつど起きたイベントに対しやる。探索的テウsととか
・コンサルテーションベース
→なんか外部のやばいやつの意見を聞いてカバレッジを上げていく
・怪奇的アプローチ
→既存のテストを再利用したり怪奇テストを高度に自動化したり標準のテストスイートを使ったり
変換がすごいことになった
異なるアプローチを組み合わせることもある
5.3 テスト進捗のモニタリングとコントロール
5.3.1 テスト進捗モニタリング
モニタリングの目的
→テスト活動の可視化、フィードバック
→手動或いは自動で収集
→終了基準の計測に使う
→カバレッジとか
→めとりくすで実際のしんちょくと予定スケジュール、コストを比較
代表的なテストメトリクス
・テストの準備完了割合（もしくは作成したテストケースのパーセンテージ）
・テスト環境準備で完了した割合
・テストケースの実行具合（実行数・未実行の数、合格・不合格の数★）
・欠陥情報（欠陥密度、摘出数と修正数、故障率、再テストの結果） なぜ確認テストと言わないんだろう なんか違うのかな
→欠陥密度 １０００行のコードで欠陥が５００個あったら５０パーセント やめちまえ
→これ１００パー越えようと思えば超えるな
→故障率→測定単位に発生したあるカテゴリの故障数の率 何が違うんだろ
。要件、リスク、コードにおけるテストカバレッジ
分岐が一切なくて入力もないただ実行するだけのシステムのテストを依頼
・品質に対するテスト担当者のしゅかんてきな信頼度
→人によるけどわかる
→何でもかんでも大丈夫にしちゃうおじさん
・テスト作業のまいるすとん
・テストに要するコスト
→この欠陥があるとへいきん５０００おくえん損するけど摘出に２兆円かかるならやらない方向にかじをきるとか
5.3.2 テストレポート★
勘案勘案
・テスト期間中に発生したこと、例えば終了基準を満足したひ
→なんかれいがなんとも言えない
→マネージャのペットが死んで一ヶ月休職したとかレポートに載せたい
・将来の方針を決めたり参考にしたりすることができるような分析情報やとりくす
残存欠陥の評価
コスト上の効果
発生する可能性の高いリスク
テスト完了したソフトウェアに対する信頼どのレベッル
なんか適当になってきた 眠たい
メトリクスは各レベルのテスト期間中や終了時に計測
・テスト目的に対する十分性
・テストアプローチに対する十分性
・テスト目的に対する有効性
5.3.3 テストコントロール
実施結果やレポートをベースに今後の方針を決めたり作業を補正したり
補正作業はあらゆるテスト活動を網羅し、他のソフトウェアライフサイクルの活動や作業に影響を与える
→セキュリティチームがずっと寝てるから開発環境の構築は後回しにしよう
テストコントロールの作業
・テストモニタリングの情報をベースに意思決定する
→欠陥密度が５万パーセントを超えたから開発チームを全員解雇するとか？
・発生したリスクに対してテスト順位を見直す
・テスト環境の利用カフカじょうきょに寄ってテストスケジュールを変更する
→社内の回線が全部ちぎれたからローカルでできるやつ先やろうとか
・修正をビルドに反映する前に開発者自身による再テストを実施することを開始基準にするとか
→ちゃんと確認してからビルドに反映しろてきな
5.4 構成管理
ライフサイクルを通じてプロダクトやシステムの完全性を確立し維持することがもくてき
→完全性ってなんだろ
テストの場合構成管理では以下を確認する
・テストウェアの全アイテムの識別、バージョンコントロール、変更履歴、各アイテム間の関連付け、トレーサビリティのいじ
・ドキュメントの識別
むかし結合試験中にバージョン管理にコミットしまくって怒られたな・・・
テストアイテム、テストドキュメント、テストケースやハーjネスを一いいに識別し再作成する場合の強力なツール
→環境とテストケースがマッチしてなくて死んだりあるもんね
テスト計画作業では構成管理の手順や仕組みを選択し文章化し実行する★必要がある★
5.5 リスクとテスト
リスクとは
→イベント、危険、脅威、発生する状況などの見込みとその望ましくない結果、もしくは可能し
→リスクのレベルはやばいことが起きる可能性とダメージの大きさで決まる
→テストリーダの家の近くに殺人鬼が住んでいる
→テストリーダが殺された場合６００万円くらいのコストが
→殺人鬼がテストリーダを殺す可能性かける６００万円がリスクのレベル
5.5.1 プロジェクトリスク
・組織問題のようそ
スタッフのスキル、トレーニング、人員不足
人事の問題
政治的な問題
→テスト担当者のニーズやテスト結果がうまく伝わらない（これニーズか？）
→テストやレビューで見つかったことがあんまりフォローアップされてない
→テストから期待できるものを正しく評価しない
→ログイン機能が実装されてないのでログインできません！！！！→嘘だあ
・技術的な問題
要件を正しく定義d系ない
制約があるために要件を拡張できない
テスト環境が予定通りに用意できない★
データ変換の遅れ、行こう計画の遅れ、でーたへんかん、移行ツールの開発、テストの遅れ
設計、コード構成データ、テストデータ、テストの低い品質
・供給者側の問題
サードパーティ製品の故障
契約上のもなだい
マネージャはちゃんと「プロジェクト管理のルールに従う
5.5.2 プロダクトリスク
ソフトウェアやシステムで失敗する可能性のある領域をプロダクトリスク
→プロダクトの品質に対するリスク
・故障が起きやすいソフトウェアの出荷
・ソフトウェアやハードウェアが個人や会社に対し損害を与える可能性
・貧弱なソフトウェア品質特性
・貧弱なデータの完全性と品質
→CSV出力ボタンを押したら５%の確率でJSONが出てくる
・予定の機能が動作しないソフトウェア
→ならない目覚まし時計
何をテストするか、さらにテストするかはプロダクトリストで決める
→実際にリスクを減らしたり影響を減らしたりするのはテストの世界★
・リスクベースのアプローチ
→プロダクトリスクの洗い出し
→リスクをテスト計画のガイダンスとして使う
リスクベースのアプローチでのリスクのようと
・テスト技法を決める
・実行範囲を決める
・優先順位を決める
・その他リスク減らす方法の検討
リスクマネジメントでは決まったアプローチを備えている必要がある
・リスクの評価（定期的な再評価
・重大性を決める
・重大なリスクを処理する方法を作る
＋テストでリスクの洗い出し、軽減すべきリスク極め、不明瞭さを減らす
5.6 インシデント管理
テスト結果と期待する結果に差があればインシデントを残す必要がある
→インシデントは調査しないといけない。欠陥かもしれない
→検出した時から分類、修正、最終確認まで追跡が必要
→全てのインシデントを完了するまで管理するためインシデント管理のプロセエスを定めて分類の規則を設ける必要がる
コード、システムドキュメント、ユーザ情報、ヘルプなどあらゆる場所に出てくる
インシデントレポートの目的
開発担当者や関係者に対して問題を特定抽出解決できるようフィードバックする
テストリーダにシステムの品質、テスト進捗を追跡する手段を提供する
→テストの進捗を追跡するのにインシデントレポート★
テストプロセス改善のためにヒントを提供する
インシデントレポートの中身★★
・日付、組織、作成者
・期待した結果と実際の結果
・テストアイテム、環境
・ソフトウェアやシステムのライフサイクルプロセス
・インシデントログ、DBダンプ、スクショなどインシデントの再現ッデキル気jルウつ
；ステークホルダに与えるインパクトの範囲や程度
→これむずいな
・システムに与えるインパクト
・修正の緊急度・優先順位
→ここまでやるんだね
・インシデントのステータス
→修正待ちとか諦めとか
・結論、アドバイス、承認
・外部との問題（直すと他が爆発する）
・修正履歴
・ID
6. テスト支援ツール
テストを支援するあらゆるツール
→この意味では表計算ソフトウェアもテストツールである
→これを根拠に答えると間違えそうな問題が
目的
・自動化、テスト計画テスト設計レポートモニタリングなど主導の作業を支援するやつ
・手動でやるとクソめんどくさいやつの自動化（カバレッジ測定とか
・手動では無理なやつ
→めっちゃアクセスしまくるとか
・テストの信頼性をあげる
→機械的にできることを機械的にやる
テストフレームワークの意味３つ
・テストツールに組み込まれているテストライブラリ（テストハーネス）
・自動化のための設計のしゅるい（データ駆動、キーワオド駆動）
データ駆動→入力と結果をスプレッドシートとかに入れといて一発で全部テストする
プロセス全体のことお
6.1.2 テストツールの分類
ブローブ効果
→テストツールが実際のテスト結果に影響を与えるもの
→webさーばにJMeter入れたらJMeterが重すぎてWebサーバが動かんとか
6.1.3 テストマネジメントの支援用ツール
テストマネジメントツール
定量分析、テスト対象のレポート、テスト実行、血管の追跡、要件マネジメントのためのインターフェースを提供
テスト対象→要件仕様書への追跡も支援する
→バージョン管理できるとかもある
要件マネジメントツール
ようけん→各テストの追跡を支援する
インシデントマネジメントツール
故障とかケッッ感とかインシデントレポートを格納して管理する
→統計的分析の支援ができるのもなる
構成かrんりツール ★厳密にはテストツールではない
6.1.4 静的テスト支援ツール
レビューツール
→レポートの補完とかにも疲れう
静的解析ツール
6.1.5 つと仕様の支援ツール
テスト設計ツール
→入力データ、ツェウト、テストオラクルを生成できる
UI,設計モデル、ソーソコードから
6.1.6 テスト実行と結果記録の支援ツール
テスト実行ツール
→実行するツール（自動でできるとか結果記録とか
テストハーネス、ユニットt４えすと風呂rームワーク
スタブとかドライバとかの構造
テスト比較ツール
ファイル、データベース、テスト結果の違いをチェックする
カバレッジ測定うtーる
→特定の種類のコード構造（ステートメント、部r那智、判定、もじゅーうrをふぁんくしょん
6.1.7性能・モニタリング支援ツール
動的解析ツールx→っっっっっっっっっっっっっっ
→実行中に表せる欠陥をみる（メモリリークとか）
6.2 ツールの効果的な使い方：利点とリスク
6.2.1 ツールでテストを支援する利点とタスク
→工数が必要
ツールを使うことで期待できる効果
・反復作業が減る
・一貫性野菜実効性が増加する
・客観的jな評価が環境になる
・テストやテストケースrへの節夫↑亜型s区計測
ツールのリスク
・ツールを過大評価
・導入サさあああああああああああああああああああああああああああああああああああ
・工数、いかん、キナk￥k＾￥￥
・テスト資産の必要な時間kにゃ構図うを過大評価する
→テスト資産の保守工数を過小評価
。・依存しすぎ（テスト設計書をおこ変えたり）
・ツール内にあるテスト資産のバージョン管理が甘い
・要件管理ツール、バージョン管理ツール、インシデントマネジメントツール、欠陥追跡ツール、ベン団がま
→ツール館での相互運用性の問題を無視する
→ベンダーがサポートやめたりして死ぬ
・ツールのサポート。あっぷぐれーど、欠陥修正に対するべんだの対応が悪い
べんだて
：；；；；；；；；；；；；；；；：；；；；；；；；；；；；；；；；眠い
・
：OSS、フリーツールプロジェクトが停止
・新しいプラットフォームをサポートできない
6.2.2 個別ツールの使用上の注意
テスト実行ツール
→自動テストスクリプトでテスト対象を実行する
→大量に工数をかけないと大きな効果が出ないことが多い
→手動テスト担当っしゃのs操作をそのまま記録することで実行手順をキャプチャ
→大量の自動テストスクリプトを活用するよう拡張できない
？？？？？？
→期待しないイベントが起きると動作が不安定になる
データ駆動を追うお要した技術
→
キーワード駆動
→実行させる動作を定義するキーワード（アクションわーdp）とテストデータをスプレッドシートに設定
→テストが動く
→スクリプトのスプレッドシートへのマッピング見たいな
使用したスクリプト技術に関わらず、各テストで必要な期待結果は後で比較するのであらかじめ格納氏と行くあうがらる・スクリプト言語ではアプローチに関わらず技術的な専門知識が必要
静的解析ツール
→コーディング規約の遵守とかに使えるけどめっちゃメッセージでることがある
→理想としては保守が簡単いなるように見直すべき
→さいしょはメッセージのフィルタとかしてちょっとずつ導入するといいかもしれませんゆお
6.2.2 個別ツールじ
テストマネジメントツール
組織が必要とするフォーマットで役立つ情報を作成するために他のツールやスプレドシートとのインターフェースが必要
テストプロセスのマネジメントおwコントロールするためのツール
テストウェアの管理
スケジューリング
結果の記録
進捗管理
インシデントマネジメント
テスト報告
とかの機能があるkとが大分
6.3 組織へのツールの導入
基本原則
・テストプロセス改善の機械や組織の成熟sど、長所短所を評価する
・明確にした要件と客観的な基準を背景に評価
・コンセプトの照明をする →テスト対象に効果的に使えるか、今のインフラでいい感じに使えるか、もしくあh逆にいい感じに使うにはインフラどう変えるかとか
・ベンダ、サポート提供者の評価
俺はjenkinsよりhudsonのが好き
顔が憎たらしいから
・教育や訓練に対する組織内の必要事項を特定する
→マウス必須のツールを導入したけどマウスが車内に浸透してないから教育するとか
・自動化スキルを考慮してトレーニングの必要性を評価する
・具体的な美jネスケースに基づいて費用対効果を見積もる★
★パイロットプロジェクト
ツールを試すためのプロジェクト
とりあえず導入してみようぜ！！！！！使えん！！！！何もかも終わった！！！！ってならないように
→ツールの詳細を学習
→適用可能か、何か変更必要なら何をへkのうすればいいかチェック
→プロセスやプラクティスに対して
→関連物（ファイルmテストケースの命名法、ビルド、テストスイートの部品の定義なd）の試用感利確の穂いう保守の表示順的jな方法おw定める
期待する効果kが妥当なコストで実現可能か見極める
組織内でツールの展開を成功させるには
・未使用の部署に徐々に展開する
→徐々に展開する
→徐々に展開すると徐々に消滅する印象があるがいきなり全部突っ込んで爆発するよりマシなんだろうな
→ツールに合わせたプロセスのてきようやかいぜん
→新規ユーザへのトレーニング
利用ガイドづくり
使用する上でそれを活用するための情報集めの方法の実装
ツール使用状況や効果をモニタリングする
テストチームへの支援を提供する
全てのチームから学んだ教訓を集める
http://jstqb.jp/dl/JSTQB-glossary.V2.3.J02.pdf
http://www.itmedia.co.jp/im/articles/0704/23/news107_2.html
参考にした ページ
http://www.itmedia.co.jp/im/articles/1111/07/news187.html
https://webrage.jp/techblog/design_method_of_test/
http://www.itmedia.co.jp/im/articles/1111/07/news172.html
https://ja.wikipedia.org/wiki/RAD_(%E8%A8%88%E7%AE%97%E6%A9%9F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E7%92%B0%E5%A2%83)
https://codezine.jp/article/detail/6423
http://www.itmedia.co.jp/im/articles/0806/25/news136.html
http://kyon-mm.hatenablog.com/entry/20121217/1356444948
http://monoist.atmarkit.co.jp/mn/articles/1008/25/news101.html
http://www.itmedia.co.jp/im/articles/0704/23/news107_2.html
https://appkitbox.com/knowledge/test/20121112-107
https://books.google.co.jp/books?id=DaIeHk3pX1YC&pg=PA148&lpg=PA148&dq=%E5%88%B6%E7%B4%84%E3%82%92%E3%81%A4%E3%81%91%E3%81%AA%E3%81%84%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3&source=bl&ots=gUCCImX3Ps&sig=mzAc6x-vMkOMEgED8OPfoAeu3z4&hl=ja&sa=X&ved=0ahUKEwiq4_a1rIbSAhXMTrwKHX5YD9UQ6AEIHDAA#v=onepage&q=%E5%88%B6%E7%B4%84%E3%82%92%E3%81%A4%E3%81%91%E3%81%AA%E3%81%84%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3&f=false
何か言葉の定義がはっきりしてなくて腹が立つな・・テストに携わる人にとっての一般名詞なんだろうか
全体的に背景じゃなくて言葉の定義をかいてほしい
