はじめに
「同値分割とか、そういった小手先の技法は学んだことがあるけど、いまいちテストってよくわかってない」ってのが正直な感覚。
「過去連綿と受け継がれた秘伝のタレみたいなテスト計画書のフォーマット」はある。
でも、それが本当に良いのか疑念を感じたので、テスト界隈に足を踏み入れる。
沼だった。
今までの変遷（興味ある人だけ開いてみてください）
注意事項
あくまで、JSTQBのFLシラバス理解に向けた個人的メモです。
「これを読んだら FLシラバスが習得できます！」とかじゃないです。全然違います。
当然ですけど、こんな記事より「JSTQBのHP - JSTQB公認研修コース」に参加するのが正しい道です。（もしくは自力でシラバスを読むか。）
※本記事は「Foundation Level シラバス 日本語版 Version 2018.J03」を対象にしています。
0 イントロダクション
シラバス自体の説明が多いので、本文は基本的には割愛して、ざっくり理解した一文を載せる。
0.1 本シラバスの目的
基本的には教育・振興のためと理解。
0.2 ソフトウェアテスト向けテスト技術者資格制度 Foundation Level
Foundation Levelは、「ソフトウェアテストについて基本的な理解を望む方」が対象。マネジメント層にも適切。
0.3 試験対象の学習の目的と知識レベル
イントロダクションと付録以外は、「記憶しなさい」。明示的に触れられていない用語であっても、その用語は記憶しなさい。
0.4 Foundation Levelの認定資格試験
イントロダクションと付録を除いて、全て試験対象。
0.5 認定審査
教育機関の認定に関する話。割愛。
0.6 詳細レベル
国際的に一貫した教育と試験を可能にするために、シラバスは以下のようになっている。
- 全般的な教育内容の目的（Foundation Level の意図について説明）
- 用語のリスト（思い出すことができなければならない用語）
- 各知識領域の学習の目的（達成しなければならない知識レベルの学習の成果について説明）
- 教えるべき主要なコンセプトの説明（承認された文献や標準を情報源として含む）
本シラバスの内容は、「ソフトウェアテストの全知識領域の説明ではない」。
- シラバスの範囲内
- 全てのソフトウェアプロジェクトに適用できるテストコンセプトとテスト技法に重点を置いて説明している。
- これらのコンセプトをアジャイルプロジェクト、他の種類のイテレーティブ/インクリメンタルライフサイクル、およびシーケンシャルライフサイクルに適用する方法については説明している。
- シラバスの範囲外
- 「用語のリスト」などの詳細な内容は、トレーニングコースでカバーされる。
- 特定のライフサイクルおよび方法論に関連する個別の学習の目的は取り上げていない。
「基本的に、学習コースに参加しなさい。」と、理解した。
（そう理解はしたけど、別件に研修費使いたいので、ひとまず独学してみる。）
JSTQB 認定テスト技術者資格 Foundation Level試験合格
ここらへん見ると、コース受講は必須じゃないっぽい？まぁ資格は後でいいや。
0.7 本シラバスの構成
約17時間での学習を想定。
- テストの基礎： 175min
- ソフトウェア開発ライフサイクル全体を通してのテスト： 100min
- 静的テスト： 135min
- テスト技法： 330min
- テストマネジメント： 225min
- テスト支援ツール： 40min
17時間か・・・長い戦いになりそうだなぁ・・・
8 付録A - 本シラバスの背景
（個人的興味から、付録を優先。「付録はだいたい面白い」って勝手に思ってるので。）
このドキュメントができるまでの経緯
本ドキュメントは、ISTQB（www.istqb.org）によって承認された、国際的資格の初級レベルにあたる、ISTQBテスト技術者資格制度Foundation Levelのシラバスである。
国際的資格なんだなぁ。
冒頭のCopyrightにも記載あったけど、日本のローカル規格じゃなく、世界規格ってのはなんとなく安心感ある。
本ドキュメントは、国際ソフトウェアテスト資格認定委員会（ISTQB）によって選任されたメンバーにより構成されるWorking Groupによって、2014年から2018年の間に作成された。
4年かかったのか。先人に感謝しつつ学習しよう。
- Foundation Level 資格認定の目的
- 国際資格認定の目的
- 本資格認定試験の受験要件
読めばわかる内容なので、割愛。
ソフトウェアテスト Foundation Level の資格認定の経緯と歴史
こういうの待ってた！気になる！
独立したソフトウェアテストの資格認定は、1998年にイギリスのブリティッシュコンピューターソサエティ情報システム研究委員会（ISEB）によってソフトウェアテスト委員会が設置されたときからスタートした（ http://www.bcs.org.uk/iseb ）。
2002年には、ドイツのASQFがドイツのテスト技術者資格認定のスキームを支援し始めた（www.asqf.de）。
本シラバスは、ISEBとASQFのシラバスが基となっている。
これは再編成され、内容を更新、追加したものとなっている。
ほーん。そこまで古くないのか。あ、いや、20年前って言われると、まぁまぁ前だな。
ISEBとかASQFとかって初めて聞いたけど、テスト界隈の人にとっては有名なのかな？？？
この際最も重要視したことは、テスト技術者にとってより実用的になるように心がけたことである。
実用的！嬉しい！
この国際資格がスタートする前に認定されたソフトウェアテストFoundation Levelの資格（例えば、ISEB、ASQF、またはISTQBが認可した各国の委員会によるもの）は国際資格と同等のものだと見なす。
Foundation Leveの資格認定は、期限が切れることはなく、更新の必要もない。資格が与えられた日付が認定書に記されている。
更新不要なのは、ありがたいなー。そういえば、イントロダクションで触れてたコースって、どこでやってるんだろう？
あった → JSTQBのHP - JSTQB公認研修コース
各々の参加国において、そこでの見解はISTQBに加盟している各国の委員会（日本ではJSTQBが該当する）にて管理される。各国の委員会の任務はISTQBによって規定されているが、各国内の小委員会によって履行される。各国内の小委員会の任務は、教育機関の認定と資格試験の設定も含まれる。
ほー。各国ちゃんとあるのかな？？？
→ ISTQBのHP - Geographic coverage
上記を見ると、アフリカはあんまりカバーしてないけど、一般的にシステム開発が多そうな国には一通り小委員会が存在するみたい。
どうでもいいけど、JordanはJOSTQB。日本は、JASTQBじゃなくて、JSTQB。日本のが加盟が早かったのかな？
各国見てると、地味にバリエーションあるな。Testing Boardはソフトウェア以外も対象にしてるのかな・・・？
- xSTQB: 国名 Software Testing Qualifications Board・・・ロシアとか日本とかアメリカとか
- xSTB: 国名 Software Testing Board ・・・パキスタンとか
- xSTA: 国名 Software Testing Association ・・・ケニアとか
- xTB: 国名 Testing Board・・・インドとか
フランスはフランス語だ・・・「Comité Français des Tests Logiciels (CFTL)」
へー。
9 付録B - 学習している知識の目的と認知レベル
（個人的興味から、付録を優先。「付録はだいたい面白い」って勝手に思ってるので。）
レベル 1：記憶レベル（K1）
用語または概念を認識し、記憶して、想起することができる。
例：
「故障」の定義を以下のように認識できる。
「エンドユーザーまたは他の関係者にサービスを引き渡しできないこと」、または
「コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること」
レベル 2：理解レベル（K2）
課題に関連する記述について理由または説明を選択することができ、テスト概念に関して要約、比較、分類、類別、例の提示を行うことができる。
例：
できるだけ早期にテストの分析と設計を行わなければならない理由を説明することができる。
早期に欠陥を検出すれば除去コストが低くなるため。
重要な欠陥をより早く見つけるため。
レベル 3：適用レベル（K3）
概念または技法を正しく選択することができ、それを特定の事例に適用することができる。
例：
有効/無効に分ける境界値を見分けることができる。
特定の状態遷移図からすべての遷移をカバーするテストケースを選択できる。
これでスキルレベル評価するのも面白そうだなー。
FL資格合格には、K1:記憶レベルが求めれているらしい。ほぉ。
1 テストの基礎
175min
目標のほとんどがK2だったけど、FLの基準はK1では無いのか・・・？？？？
（それとも「テストで確認できるのはK1レベルでしかないから」っていうことかな？）
まぁFLの資格取得ではなく、テストについての学習が目的なので、関係ないけど。
キーワード
ひとまずぱっと見、分からなかったものだけ調べるようにしてみる。
キーワードで理解できなかったもの
※「品質保証」とか、本当の意味で理解できてない気はするけど、表面的にすら理解が怪しいものを抜粋してます。（ちなみに、「品質保証」は、全然理解できてませんでした。後の方で、補足してます。）
| 用語 | 意味 | ITmediaの説明リンク |
|---|---|---|
| テストベース | テストケースの素材となる各種の情報源のこと。 | link |
| テストオラクル | ソフトウェアテストの正しさや妥当さを判断する根拠となるもののこと。 | link |
| テストスイート | ソフトウェアテストの目的や対象ごとに複数のテストケースをまとめたもの。 | link |
1.1 テストとは何か？
以降は、学習目標が定義されているので、シラバスを読んだ上での理解を学習目標ごとに整理していく。
ただ、学習目標に外れる気になったことは随時記載していく。
気づき
テスト対象のコンポーネントやシステムを実行することは、動的テストと呼ぶ。テスト対象のコンポーネントやシステムを実行しない場合は、静的テストと呼ぶ。このため、テストは要件、ユーザーストーリー、ソースコードなどの作業成果物をレビューする活動も含む。
レビューが 品質保証 品質コントロールの一貫であるのは理解しているけど、定義的にはテストに含めているのか・・・
感覚的には別物だったけど、テストに含まれるという前提で読み進めていこう。
K1記憶 テストに共通する目的を識別する。
思ったより多い。。。全部は書くのはなんか違う気がするので、個人的理解で、まとめてみる。
◆違和感のなく記憶できそうなもの◆
（表現をだいぶ丸めているので、原文と全然違います）
- 要件充足の評価
- 妥当性確認
- 欠陥の作り込み防止
- 故障や欠陥の発見
- ステークホルダーが意思決定するための情報提供（特に品質面）
◆違和感があったのでもう少し深めて理解したいもの◆
「K1記憶」レベルなので、別に「K2理解」までは要らないんだけど、「K2理解」までした方が記憶に残りやすいので。
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
- テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
- （以前に検出されなかった故障が運用環境で発生するなどの）不適切なソフトウェア品質のリスクレベルを低減する
- 契約上、法律上、または規制上の要件や標準を遵守する、そして／またはテスト対象がそのような要件や標準に準拠していることを検証する。
いくつかググってみたけど、この目的の解釈に言及している人が居ない・・・
ひとまず個人的に解釈してみる。
そもそもみんな引っかからないのかな？自分が引っかかる理由から整理するか・・・
要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
なぜ引っかかるか？どこに違和感を感じるか？
「作業成果物の評価」と言われれば分からなくはないんだけど、なんかこう定義が広すぎて・・・
分解してみる
無理やり分解するなら以下5つに分けられる。それごとに理解してみる。
- 要件を評価する
- テスト目的に「契約上、法律上、または規制上の要件や標準を遵守する〜」的な表現もあるので、要件自体の評価もテストに含むということだろう。
- ユーザーストーリーを評価する
- 上に同じか・・・？
- ユーザーストーリーを実現することで、そもそもの要件が達成されるのか？とかは評価するポイントな気もする。
- 設計を評価する
- わかる。レビューもテストに含むらしいし、主にレビューを指しているのだろうか？いや、結合テストとかでも設計不備とか見つかるし、レビューには限らないだろう。
- コードを評価する
- わかる。同上な気がする。
- その他作業成果物を評価する
- まぁ多分プロジェクト成果物全てなんだろうな。あ、いや、でもそんな風には表現されてないな。う〜ん。ひとまずプロジェクト成果物全てって理解しちゃうか。
その他疑問
- 「評価」って何するの？
- 他の目的に記載されていることだと理解。
- 具体的には、妥当性確認とか、要件充足の評価とかだと思われる。
- なぜこの目的が一番最初なのか？
- 一番包括的だからだろう。（分解してみて、そんな感覚を抱いた）
テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
なぜ引っかかるか？どこに違和感を感じるか？
「信頼を積み重ねて」ってニュアンスがいまいちよく分からない。
「信頼」ってどういう意味合い？
品質特性の「信頼性」のこと？それとも、国語的なニュアンスとしての「信頼」のこと？
分解してみる
- テスト対象の品質に対する信頼を積み重ねて
- 対象：テスト対象の品質
- 行動：信頼を積み重ねる
- 「信頼」とは、「ある人や物を高く評価して、すべて任せられるという気持ちをいだくこと。」（weblio類語辞書）
-
「信頼性」とは「ある状況がある時間続いたときにソフトウェアがどの程度機能するかに影響する特性群。」（wikipedia - ISO/IEC 9126）- ここで急に「品質特性」の「信頼性」だけを取り上げるのは不自然だと思うので、普通に考えてこっちじゃないだろうな。
- 所定のレベルにあることを確証する。
- 基準：所定のレベル
- この「所定のレベル」の定義が難しいと感じるんだけど、そこらへんはおいおい言及されるのかな・・・？（それとも厳密に定義されていることのみを指しているのか？？）
- 行動：確証する
- 「確証する」とは、「ある事柄について、その真偽を明らかにすること」（weblio類語辞書）
- 「確証」とは、「たしかな証拠。」（weblio辞書）
- 基準：所定のレベル
個人的な解釈
「信頼」に引っかかってしまったけど、多分「積み重ねて」が重要なんだと、思い始めてきた。
『「一発で品質を保証するような方法は無い！」だから、ちょっとずつ「積み重ねて」、品質を向上させていくしかない。
その際、「確実な証跡」を元に品質を確認/評価することが、テストである。』
ってことだろう。そんなに悪く無い気がする。
（以前に検出されなかった故障が運用環境で発生するなどの）不適切なソフトウェア品質のリスクレベルを低減する
なぜ引っかかるか？どこに違和感を感じるか？
「不適切な」がどこにかかるのかが分かりづらくて・・・
「不適切なソフトウェア品質」なのか？「不適切な（ソフトウェア品質の）リスクレベル」なのか？
個人的な解釈
「（不適切なソフトウェア品質によって、高まってしまう）リスクレベルを、低減すること」が目的。
目的はあくまで「リスクレベルの低減」。
特に、「ソフトウェア品質が不適切な状態であることに起因するリスクレベルの高さ」に手当てすることが、テストの目的である。
この理解は悪く無い気がする。
契約上、法律上、または規制上の要件や標準を遵守する、そして／またはテスト対象がそのような要件や標準に準拠していることを検証する。
なぜ引っかかるか？どこに違和感を感じるか？
「契約・法律・規制」の順番が気になった。一番広いところから行くなら、法律＞規制＞契約の順だと思うけど、契約が先に来ているのはなぜ？（あんまり深い意図は無い気がするからここは掘り下げない）
「そして／または」という表現。「または」って状況はあるのか・・・？
個人的な解釈
「そして／または」だけ掘り下げてみる。
「契約・法律・規制」で、プロセスだけが定義されているなら、「または」っていう状況だろう。あ、いや、その場合プロセスがテスト対象になるのでは・・・？？？
う〜ん。ちょっと掘り下げを諦める。材料が少なすぎる。読み進めていったらわかることに賭けて、ここまでにしておく。
（ただ、ここK1レベルなので、補足説明なさそうな予感もしてる。）
K２理解 デバッグとテストを区別する。
テストを実行することは、ソフトウェアに存在する欠陥に起因する故障を見つけることである。
「欠陥に起因する故障を見つけること」。了解。
なんか、「1.1 テストとは何か？」の前説では以下説明があるので、矛盾している感がある。
ソフトウェアテストはさまざまな活動を含むプロセスである。テスト実行（結果の確認を含む）は、それらの活動の 1 つにすぎない。
まぁ、前説で触れているのは「広義のテスト」、ここで触れられているのは「狭義のテスト」って感じか・・・？？
あ、いや、矛盾してないのか。
前説で触れているのは、『テストの中に「テスト実行」が含まれるよ』という内容。ここで触れているのは『テスト実行は、欠陥に起因する故障を見つけること』だと表現しているので、矛盾してないや。
というかそうすると、この章は厳密には『「デバッグ」と「テスト実行」を区別する』なんだろうな。
一方、デバッグは、故障の基となる欠陥を見つけて、解析し、取り除く一連の開発の活動である。その後、テスト担当者が確認テストを実施し、修正により欠陥が解決したことを確認する。
「故障の基となる欠陥を見つけて」「解析し」「取り除く」、了解。
「テスト担当者が確認テストを実施し〜」は、アジャイルとかだと役割分担変わる場合あるよねってのもシラバス本文中で触れられている。
1.2 テストの必要性
K2理解 例を挙げてテストの必要性を説明する。
文章から読み取れる「テストの必要性」というか、「テストの効果」
- 運用環境で問題が発生するリスクの低減
- コンポーネントやシステムの品質向上
- 契約や法律上の要件、および各業界の標準に合致していることの証明
- 問題を含むリリースの頻度の低減
箇条書きのやつ
- 効果：要件に対する欠陥の検出と除去を行うことにより、テストができない機能、または正しくない機能が開発されるリスクを低減できる。
- 手段：テスト担当者が要件レビューやユーザーストーリーの洗練作業に関与する。
- 効果：基本的な設計の欠陥が混入するリスクを低減し、テストケースを早い段階で識別できる。
- 手段：システムの設計時にテスト担当者がシステム設計者と密接に連携して作業する。
- 効果：コードとテストケースに欠陥が混入するリスクを低減できる。
- 手段：コード開発時にテスト担当者が開発担当者と密接に連携して作業する。
- 効果：ソフトウェアがステークホルダーのニーズに合致し、要件が満たされる可能性が高める。
- 手段：テスト担当者がリリース前にソフトウェアを検証および妥当性確認することで、デバッグを支援する。
「テスト担当者」いろんなところに関わることになるな・・・大変だ・・・
上記をフェーズ分割すると、要件定義・設計・実装・リリース前検証なので、要は全フェーズで関わるって感じだなー。
途中から入れればいいってもんじゃないってことだな。
目的を見返す
「例を挙げてテストの必要性を説明する。」ってあるけど、例ってのは、上記粒度でいい感じなのかな。
なんとなく、各工程でのテスト担当者（テスト技術者）の役割が理解できていれば、普通に説明できそうな感覚。
K2理解 テストと品質保証の関係を説明し、品質を確保する上でテストがどう貢献するかを、例を挙げて説明する。
品質保証（または単に QA）という用語がテストを意味するために使われることがある。しかし、品質保証とテストは、関連してはいるが同じではない。
お、まじか。「広義のテスト」＝「品質保証」くらいの感覚でいたぞ。違うのか。
さらに大きな範囲を表す品質マネジメントという概念が両者を結び付けている。
品質マネジメントは、品質に関して組織の方針を示し、組織をコントロールするための活動をすべて含む。
品質マネジメントは、品質保証と品質コントロールの両方を含む。
なんかだいぶ横道にそれ始めた感じがあるぞ・・・？？？？
品質保証は、一般的に、品質が適切なレベルに確実に到達するよう、適切なプロセスを遵守することに重点
を置く。
ひとまず「品質保証」は、「プロセスの遵守」に重点を置いてるのか。なるほど。
品質コントロールには、テスト活動を含め、適切なレベルの品質を達成するために役立つさまざまな活動が含まれる。
う〜ん。。。「プロセス」自体を指すって理解でいいのかな・・・？？？いや、「プロセスの集合体」が「品質コントロール」？？？
なんか理解が間違ってる気がする。。。。
品質保証では、テストを含むプロセス全体を適切に実行することが必要となるため、適切なテストを支援する。1.1.1 と 1.2.1 で説明しているように、テストはさまざまな方法で品質の達成に貢献する。
う〜ん。品質保証は、テストよりも広義の定義だと理解すれば良いのかな・・・。
個人的な解釈
ひとまず、包含関係を整理する。以下で読み取ったけど、なんか不安が残る。
- 品質マネジメント＞品質保証（QA）：プロセスの遵守を指す？？？（なんか違う気がするが・・・う〜ん）
- 品質マネジメント＞品質コントロール（QC）＞テスト：個々の活動を指す
実例に合わせると・・・こんな感じか？
「設計とか実装とか、実際に品質を作り込む作業は、品質マネジメントの範囲であり、品質コントロールの一貫でもあるが、テストではない。
設計の結果や実装の結果などを評価したり、それらプロセスがうまくいくように前提となるインプットを精査することは、テストである。（＝品質マネジメントの範囲でもあり、品質コントロールの一貫でもある。）」
品質マネジメント＞品質コントロール＞テストの関係性はこれで説明がつくとしても、品質保証が分からんな・・・
よく分からないので、調べてみたら、以下あたりがわかりやすかった
ひとまず、以下であると理解した。
- 品質保証は、品質が一定の水準にあることを示すための証跡の提供等も含む。
- 品質管理（品質コントロール）は、品質向上を目的とした活動一般を指す。
『「適切なプロセスが遵守されていること」を示すことで、「品質が一定の水準にあること」を保証していることが多い』って書かれているのだと読み取った。
ジャストフィット！って感じではないけど、ひとまずこの理解でとどめておく。。。
K2理解 エラー、欠陥、故障を区別する。
基本的な定義
- 基本構造：エラー（人的要因） → 欠陥（故障を引き起こしうる成果物の誤り） → 故障（業務的不都合）
- エラーによって、欠陥が生じる。欠陥によって、故障が生じる。
- エラー：人、欠陥：モノ、故障：結果（影響は含めない、あくまで直接的な結果）
比較的よくある話
- 前工程の「欠陥」が原因で新たな「エラー」を引き起こすこともある。
- 例：要件定義の記載が曖昧で、設計担当者がうまく受け取れず、設計書に欠陥を混入してしまう。
- 「単一のモノ」では故障は発生しないが、「モノの組み合わせ」で故障が発生するという状況もある。
- 例：気温が低くても、気温が高くても動くが、気温が高いところから低いところに移動したことによる結露で故障が発生するなど。
少し掘り下げた話
- 偽陽性（誤検出）：実際には欠陥でないものを欠陥として報告してしまうこと。
- 偽陰性（検出もれ）：検出すべき欠陥を検出しないテスト。
偽陽性、偽陰性を発現させないために・・・みたいな話は無く、用語の説明のみ。
JSTQB AL テストマネージャ 第４章 150分
どうやら、ALまで行くと、そこらへんの対処も記載されている気配を感じた。
ひとまず、掘り下げはここまでにしておく。
K2理解 欠陥の根本原因と結果を区別する。
欠陥の根本原因とは、欠陥を埋め込んだ最初の行為または条件のことである。
ほい。
例えば、1 行のコードの間違いが間違った利子の支払いを引き起こし、顧客の不満を招いたとする。欠陥のあるコードは、プロダクトオーナーが利子の計算方法を誤解しており、ユーザーストーリーが曖昧となったために埋め込まれた。
この例では、「顧客の不満」が影響で、「間違った利子の支払い」が故障である。
なるほど。
おおもとの欠陥の根本原因はプロダクトオーナーの知識不足であり、ユーザーストーリーの作成時に誤りを犯した。
ふむ。
根本原因分析のプロセスは、『ISTQB-ETM Expert Level Test Management Syllabus』と『ISTQB-EITP Expert Level Improving the Test Process Syllabus』で説明する。
次のステップを示してくれるのは、めっちゃありがたいな。でも、ISTQBの方なんか・・・
ISTQB - Test Management(概要)
ISTQB - Improving the Testing Process(概要)
ISTQB - EITP Expert Level Improving the Test Process Syllabus(2011シラバス)
English！
というか、エキスパートに相当するスキルが必要な、とてもスキルフルな作業なんだろうな。これ。
1.3 テストの7原則
運良く、Kouichi Akiyamaさんのテスト7原則の連載が終わったところだったので、シラバスと照らしながら理解を深めてみる。（現在2019/08/26なので、ちょうど最後の原則が投稿された日。ありがたやー！）
K2理解 テストにおける7原則を説明する。
- テストは欠陥があることは示せるが、欠陥がないことは示せない
- 全数テストは不可能
- 早期テストで時間とコストを節約
- 欠陥の偏在
- 殺虫剤のパラドックスにご用心
- テストは状況次第
- 「バグゼロ」の落とし穴
1.テストは欠陥があることは示せるが、欠陥がないことは示せない
悪魔の証明1みたいな話だよね。わかる。
先人のブログも参照してみる。
◆Kouichi Akiyama - テストは欠陥があることは示せるが、欠陥がないことは示せない(2019/07/16)
証明することが不可能か非常に困難な事象を「悪魔」にたとえて「悪魔の証明」と呼ばれることもあります。
さて、私たちは「悪魔の証明」に対して無力なのでしょうか？
一つだけ対抗手段があります。それは、証明するときの範囲を限定する方法です。
あー。範囲を限定すれば確かに可能だなー。
逆に言えば、テストを行うときには、「どういう目的で、どの範囲について、どんな網羅基準でテストしたのか」の情報が大切ということになります。
前提はちゃんと整理しましょうってことか・・・？
よくわかっていない人が無視してもよい人なら無視すればよいのですが、無視することが困難な役職が高い人でもいうことがあります。そんなときに、この原則を説明してみるとよいかもしれません。「いいからやれ」と言われる可能性も高いですが。
悲しみ。
2.全数テストは不可能
ここらへん、数字で説明できるようになりたいなぁ。。。
感覚としては分かってるんだけど・・・
先人のブログも参照してみる。
◆Kouichi Akiyama - 25号：全数テストは不可能(2019/07/22)
原則2は、専門家にとって当たり前でも「テストのことを良く知らない人にとっては当たり前とまでは認識されていない」ため、言い続ける必要がある原則です。
そうなんすよー。
例えば、家を建てたら、まずは、トイレが流れること、風呂が沸くことなどなど生活が成り立つかのテストをしますよね。続いて、防音・防火・耐震など、不備があったら困ることを（リスクが高い順に）確認すると思います。「お風呂の蓋の色が注文と違う」といったような、問題があったとしても軽微な問題だったり、直ぐになおせることが期待できるのであれば、その確認は後回しにすることでしょう。それが、リスクベースドテストです。
なるほどー。こういうのを長い時間かけて刷り込んでいかないといけないんだろうなぁ・・・
3.早期テストで時間とコストを節約
CIとかの話かな。分かる。
先人のブログも参照してみる。
◆Kouichi Akiyama - 26号：早期テストで時間とコストを節約(2019/07/29)
さて、今回の原則3は、「早期テストで時間とコストを節約」ですが、若い人にとっては、当たり前になっているので、何を言っているのか、かえって分かりにくい原則かもしれません。
なんかそれが普通な感覚だったので、私は若い人である。
各開発者が作るモジュールの開発がすべて終わったら、それら多数のモジュールを一斉に結合しテストするため「ビッグバンテスト」と呼ばれました。
あー。そりゃ、この原則が叫ばれますわ。
「静的テスト」、つまり「仕様書のレビュー」や「コードを静的解析ツールに掛けて欠陥を見つけること」を早期テストで推奨しています。
割と普通にできているので、あんまり違和感無い。（100点満点ではないけど）
テスト設計を対応する開発プロセスが終わった直後に実施しようという図です。
本文 見たほうが分かりやすいので、見てください。
4.欠陥の偏在
言われてみれば確かにそうだったなー。という感覚。
原則になるほど、共通する事象なのか・・・
あと、「偏在を予測する」って本文中にあるけど、どうやって予測するんだ・・・？？？リスク分析によって予測する感じか・・・？
先人のブログも参照してみる。
◆Kouichi Akiyama - 27号：欠陥の偏在(2019/08/05)
ソフトウェアテストのテクニックの一つとして「ミューテーション」が流行ったことがあります。いまでもその進化型というべき「fault-prone」の研究が続いています。
ほうほう。ミューテーションテストとかは初めて聞いたなぁ。人工的にバグを入れることによって、残バグを推定する手法らしい。（ちょっと物言いが入っているらしく、確認が必要。）
どうも、本当のバグも人工的なバグも偏り方に相関があるので、ある程度実際的な手法っぽい。
なかなか工数が掛かりそうな手法に見えるけど、実際どうなんだろうか・・・
あと、進化系の「fault-proneモジュール予測」をもう少し知りたいなぁ。
ここに書かれているように、「モジュール単位でみたときの偏在」もありますし、書いていませんが、「境界値のあたり」に多くのバグが存在するといった偏在もあります。（ですから境界値分析というテスト技法が存在します。）
なるほど。「境界値あたりの偏在」も偏在にふくまれるのか。
結局、「モジュール単位で見た時の偏在」ってどうやって推定するんだろうか。
「欠陥の偏在を予測」する技術は、上述した、「fault-prone」のことです。（fault-proneは、「欠陥を含んでいる確率が高い」とか「欠陥の傾向」という意味です）
お、出てきた。つまるところ、「fault-proneモジュール予測」が肝なのかな？
fault-proneというと、難しそうに思われたかもしれません。でも、ソースコードのサイクロマチック複雑度を測定し、「複雑なモジュールに欠陥があるのでは？」と推測してテストすることありませんか？ これもfault-proneです。
やってるやってる。これもそうなんか。
ん？経験と勘ってこと？？？？
いや、それを積み重ねて、偏在ポイントを整理しておくことが大事ということか・・・？
私が一番よく使うのは、開発者に3Hを教えてもらう方法です。
3Hは、3H作業とも呼ぶのですが、「変化（Henka）」、「初めて（Hajimete）」、「久しぶり（Hisashiburi）」の3つのHで3Hです。
これも経験から生まれた偏在ポイントなんだろうな。
実装スキルとか、業務知識量とかでも偏在が生まれそうだなぁ。
「欠陥の偏在」自体は非常に分かりやすく実感が持てる原則です。それゆえに納得感も高いものです。したがって、「ミューテーションテスト」や「fault-proneモジュール予測」は大変人気があります。機械学習技術を応用すると面白いのではと思っています。
あー！確かに機械学習とかと相性良さそうだなー！
なんかやれたら面白そう！頭の片隅にいれておこう。
ただ、「fault-proneモジュール予測」が雑な理解しか出来てない気がするから、それがあってるかもう少し調べてみるかな・・・
◆テスターのテストによる開発者のためのテスト(なそさん) - テストってなんだろう？ 第4回「欠陥の偏在」(2016-06-27)
過去に結合テストで失敗したプロジェクトがあれば、そこに重点を置くのも手です。
そうやっていろんな人の知見を得ながら少しずつ成長するべきだと私は思っています。
それが歴史を積み重ねるということで、老舗のSIerにしかできないことだと思ってました。今も思ってます。
なんとなく、「偏在ポイントを積み重ねていく」って方向性は合っている様子。
「リスクベーステスト」のPRISMAメソッドと呼ばれる手法もあるらしいが、基本前提は同じっぽい。
PRISMAメソッド
「fault-proneモジュール予測」の方がメジャーぽい？？（日本語でのヒット数が多いだけか？）
prismaがどこまでメジャーなのかちょっと分からんかった。
◆fault-proneモジュール予測
slideshare - 「コンテキストの理解による技法、事例の分析」森崎 修司
論文では着眼点の紹介までなんだろうな。
これだ！みたいなのは基本的に無くて、プロジェクトによって着眼点は変わるだろうし、組織やシステムに合わせて偏在ポイントを積み重ねてくべしってことか・・・
5.殺虫剤のパラドックスにご用心
ほい。
これは「テスト関連のslideshareで、よく取り上げられている原則」ってイメージ。（観察母数が少ないので、たまたまかもしれんけど）
テストに慣れてくると、ここらへんが罠になりがちなのだろうか？
先人のブログも参照してみる。
◆Kouichi Akiyama - 28号：殺虫剤のパラドックスにご用心(2019/08/12)
さて、今回の原則5は、「殺虫剤のパラドックスにご用心」ですが、こちらも欠陥が持つ性質のひとつで「バグを見つける万能薬はないよ」ということです。
原則5は、あまり良い喩えとは思えないのですが、名前のユニークさも手伝ってか、広く知られている原則です。
「バグを見つける万能薬はないよ」と比べると、ニュアンス違う感すごい。
第1法則：殺虫剤パラドックス－－ バグの予防や発見にどんな方法を使用しても、それを通り抜ける巧妙なバグが存在する。
原文はこういう意味だったのか・・・
シラバス側には「同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。」って書いてあるので、だいぶニュアンス変わっちゃってるのね。。。
かなり、ニュアンスが違う気がします。バイザーが本当に言いたかったことは、「同じテスト」の問題というよりも、「どんなテストだってすり抜けるバグが存在する」ということのように思います。というのは本の後半に「すり抜けたバグを分析してテストに反映するように」と書いてあるからです。
「すり抜けたバグを分析してテストに反映するように」
これが大事なんだろうな。
「殺虫剤のパラドックスにご用心」という原則5について説明すると「『同じテストを繰り返すと、新しい欠陥を見つけられなくなる』のどこがパラドックスなのでしょうか？」という質問が来ることがあります。
読んでて面白かったけど、ちょっとテストとは離れる気がしたので、ここでは触れない。是非 本文 でご確認ください。
6.テストは状況次第
例えば、ロケットのテストと、twitter用の自作クライアントアプリのテストが、同じレベル感でやる必要は無いよね。っていう話だと思ってる。
先人のブログも参照してみる。
◆Kouichi Akiyama - 29号：テストは状況次第(2019/08/19)
多くの組織では、「テストは開発全体の20%くらいの期間でいいよね？ 前回もそれで何とかなったし。」というような「政治的な力関係」で外堀が埋められ、気が付いたらテスト終了日や予算が決まっていて、そこから逆算してどんなテスト（内容）をするのがベストなのかを考えているようです。そういった仕事の進め方をしている人ほど、この原則を噛みしめてほしいです。
お、結構ずっしり来るぞ。
しかしそうすると、どうやって見積もるのが良いんかなぁ・・・悩ましいなぁ。。。
この原則のポイントは「状況」です。2011年版のFLシラバスでは「条件」と訳されていて、もっとわかりにくいものでした。ISTQBの原文は、“Testing is context dependent”ですから「状況」は“context”を訳したものと分かります。
ほう。Contextなのか。
やっぱ原文見たほうが良いのかなぁ・・・
将来的には見たほうが良いんだろうけど、ひとまずはこういう先人のフォローで解釈していくか・・・
後半のこちらは、「開発プロセスが違うと、テストの実行方法は変わる」ということです。「実行方法」であることに注意しましょう。つまり、同じ価値を提供しようというソフトウェアに対して作成するテストケースは同じでも、作成したテストケースを誰が、どのタイミングで、どういう方法で行うべきかは変わるということです。
結構、言葉の端々に気を使ったシラバスなのね・・・
う～ん、この先、自己解釈が多分に入りそうだなぁ・・・
7.「バグゼロ」の落とし穴
「テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。」
こういう組織が存在することを前提としつつ、容赦なく否定しているあたり好き。
先人のブログも参照してみる。
◆Kouichi Akiyama - 30号：「バグゼロ」の落とし穴(2019/08/26)
さて、今回の原則7の『「バグゼロ」の落とし穴』ですが、「テストって何だろう？」と改めて考えさせられる原則です。最後にこれを持ってきたISTQBのエディタのセンスを感じます。
センス！私にはまだ分からない！
ところで、「バグゼロ」になれば、全てハッピーなのでしょうか？ 「そこに落とし穴があるかもよ！？」というのが、この原則です。
ほーん？
言い換えると、「たとえ、バグゼロを実現できたとしてもユーザーのニーズを満たさないなら、それって意味なくないですか？」ということです。
まぁ意味ないっすね。
ん？？？当たり前過ぎてよく分からんぞ・・・？？？
一番身近なのはテストの最終日に見つけた軽微なバグを修正するかどうかでしょう。「バグゼロ」が目的であれば直すべきですが、直す行為に新たなバグ（リグレッション）を作ってしまうリスクがあります。
短時間かつプレッシャーが高いときにデバッグすると、簡単な修正ですらロクなことが起こりませんよね。
まぁ直したいけど、「手を入れること」＝「バグを混入する可能性がある」なので・・・って話よね。
それでは、テストとは何かと言えば、
— あきやま🍧 (@akiyama924) 2018年11月22日
『“どんな人間でも間違えてしまうことがある”ことを事実として認め、そのことを前提とした上で、“開発成果物が利用者に与える価値の最大化”と“開発成果物を作るコストの最少化”という２つの狙いを良いバランスで達成するための活動』
と思っています。
つ・・・疲れた・・・
7原則にパワー割きすぎた感・・・
1.4 テストプロセス
万能なソフトウェアテストプロセスというものはない。しかし、テストの目的を達成する確率を高くする、汎用的なテスト活動のセットというものが複数ある。
「万能なソフトウェアテストプロセスというものはない！」ってちゃんと言い切ってくれるあたり、安心感ある。ついこういうのがあるんじゃないか！？と思い、探してしまうので。
原則5・6あたりでも示されている話ではあるけど。（5. 殺虫剤のパラドックスにご用心（万能薬は無い）、6. テストは状況次第）
K2理解 テストを取り巻く状況がテストプロセスに与える影響を説明する。
組織のテストプロセスに影響する状況のいくつかを次に示す（すべてが示されているわけではない）。
- 使用するソフトウェア開発ライフサイクルモデルとプロジェクト方法論
- 考慮対象のテストレベルとテストタイプ
- プロダクトとプロジェクトのリスク
- ビジネスドメイン
- 次を含む運用上の制約：
- 予算とリソース
- 期間
- 複雑さ
- 契約上および規制上の要件
- 組織のポリシーと実践例
まぁここらへんがテストプロセスに影響するよねってのは分かる。
う～ん。K2理解まで至ってるのか不安だけど、一旦ここまで。
K2理解 テストプロセスにおけるテストの活動と関連するタスクを説明する。
テストプロセスを構成する主な活動のグループは以下の通りである。
- テスト計画
- テストのモニタリングとコントロール
- テスト分析
- テスト設計
- テスト実装
- テスト実行
- テスト完了
ほい。
さらに、これらのグループの多くは論理的には順次行われるが、繰り返されることが多い。
繰り返した方が良いのは分かっていても、なかなか実践できてないなぁ。
一回作りきりってことはさすがに無いけど、もっとサイクル回したほうが良い気はしてる。
テスト計画
テスト計画では、テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する。
テスト計画については、5.2 節でさらに説明する。
あ、はい。
テストのモニタリングとコントロール
モニタリングは、メトリクスによる進捗確認を指す。
コントロールは、テスト計画書の目的に合致させるために対策を講じる活動。
テストのモニタリングとコントロールは、終了基準の評価により支援される。
終了基準は、ライフサイクルによっては「完了（done）の定義」とも呼ばれる。
今更だけど、ユーザーストーリーとか、プロダクトオーナーとか、割とスクラムの用語が多めに出てきている感覚。（スクラム限定の用語ってわけじゃないけど）
その方が表現として近しいんだろうか。それとも、国際的な潮流的にそれが常識になってるからなんだろうか・・・？
計画に対するテスト進捗は、テスト進捗レポートを使用してステークホルダーへ伝える。
このレポートで伝える内容には、計画からの逸脱や、テストの中止を決定するために必要な情報を含む。
計画の逸脱は分かるけど、テストの中止って例えばどういう状況下で判断されるんだろうか・・・
「不具合出すぎ！一旦止めて！」みたいな感じ？
テスト分析
テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析する。
言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定する。
作ってると、「計測可能なカバレッジ基準から見る」ってのをついつい忘れちゃうんだよなー・・・
その点においてTDDは優秀な気がする。否応なく意識させにくるので。（TDDというか、テストファースト？）
- テストレベルごとに適切なテストベースを分析する
テストレベルとは・・・？
テストレベル（test level）：
系統的にまとめ、管理していくテストの活動のグループ。
各テストレベルはプロジェクトの特定の責務と対応付けができる。
テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
- JSTQB用語集
なんとなく・・・わかったような・・・分かってないような・・・（たぶん分かってない）
ちなみに、よく誤解される用語にテストフェーズってのもあるらしい。
togetter - テストレベルとフェーズの話
本論に戻ります。
なんとなく、「テストレベルをちゃんと整理して、そのインプットをちゃんと用意して分析しよう」という話だと理解した。
テストレベルを曖昧にしていると、何を分析しているのか分からなくなるからだろうか。
- テストベースとテストアイテムを評価して、以下のようなさまざまな種類の欠陥を識別する。
- 曖昧/欠落/不整合/不正確/矛盾/冗長なステートメント
こういう基準で分析して、何をテストするのか決めるんだろうな。
ん？これってレビューとどう違うんだ・・・？
「前工程成果物の欠陥を見つけよう！欠陥が多いところは不具合が出やすいぞ！」みたいな感じで良いのか？
う～ん。
- テストすべきフィーチャーとフィーチャーのセットを識別する。
「フィーチャーのセット」とは・・・？
なんとなく、一緒にテストできる機能、みたいな感じ？もしくは「関連する機能」みたいな感じかな・・・
- テストベースの分析に基づいて、各フィーチャーのテスト条件を決めて優先度を割り当てる。この際には、機能/非機能/構造の特性、他のビジネス/技術的要因、リスクのレベルを考慮する。
これはわかる。
- テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する。
これ大変なイメージ。
子くらいまでは良いけど、孫、夜叉孫とかまでいくとやばい感覚。
実際どうやってるとか見れると良いけど、あんまりテスト関係ってネットに情報上がらないよね・・・
（テストってオープンにしにくいよなぁ・・・）
テスト分析プロセスにてブラックボックス、ホワイトボックス、および経験ベースのテスト技法を適用することは（第 4 章を参照）、重要なテスト条件の欠落を防止し、精度と正確性が高いテスト条件の特定に役立つ。
ふむふむ。
テスト分析で欠陥を検出できることは大きな利点だといえる。
あ、レビューみたいなもんって理解である程度あたってるっぽい。
テスト設計
つまり、テスト分析は「何をテストするか」を決定し、テスト設計は「それをどうテストするか」を決定する。
ほうほう。
- テストケースおよびテストケースのセットを設計し、優先度を割り当てる。
はい。
- テスト条件とテストケースを支援するために必要なテストデータを識別する。
はい。
- テスト環境を設計し、必要なインフラストラクチャーやツールを識別する。
はい。
- テストベース、テスト条件、テストケース、テスト手順の間で双方向のトレーサビリティを確立する（1.4.4 節を参照）。
大変そう。
テスト分析と同じように、テスト設計はテストベースに含まれる類似の欠陥を識別することもある。
「結果的に、見つかることもある」くらいの感覚で受け取った。
テスト実装
つまり、テスト設計は「それをどうテストするか」の答えであり、テスト実装は「テストの実行に必要なものすべてを準備したか」の答えである。
うぃっす。
- テスト手順を開発して優先度を割り当てる。場合によっては、自動化のテストスクリプトを作成する。
はい。
「この場合によっては」の判断基準が知りたいが・・・
書籍になってるレベルの情報な気がするので、寄り道は控えておく。
- テスト手順や（存在する場合）テストスクリプトからテストスイートを作成する。
- 効率的にテスト実行ができるように、テスト実行スケジュール内でテストスイートを調整する（5.2.4 節を参照）。
わかる。
- テスト環境（これには、テストハーネス、サービスの仮想化、シミュレーター、およびその他のインフラストラクチャーアイテムが含まれる）を構築する。また、必要なものすべてが正しくセットアップされていることを確認する。
- テストデータを準備し、テスト環境に適切に読み込ませてあることを確認する。
そっすね。
- テストベース、テスト条件、テストケース、テスト手順、テストスイートの間での双方向トレーサビリティを検証し更新する（1.4.4 節を参照）。
ここでもか・・・。トレーサビリティ重要なんだな・・・。分かっちゃいるけど・・・
分かっちゃいるけどって言っちゃうあたりが、分かってないんだろうな。
テスト実行
- テストアイテムまたはテスト対象、テストツール、テストウェアの ID とバージョンを記録する。
バージョン管理大事。再現できなくなっちゃう。
- 手動で、またはテスト実行ツールを使用してテストを実行する。
- 実行結果と期待結果を比較する。
うぃっす。
- 不正を分析して、可能性のある原因を特定する（故障はコード内の欠陥によって発生する可能性があるが、偽陽性が発生することもある（1.2.3 節を参照））。
- 故障を観察し、観察に基づいて欠陥を報告する（5.6 節を参照）。
- テスト実行の結果（合格、不合格、ブロックなど）を記録する。
はい。
- 不正への対応の結果、または計画したテストの一環として、テスト活動を繰り返す（修正したテストケースによるテスト、確認テスト、および／またはリグレッションテストの実行）。
そうっすね。
- テストベース、テスト条件、テストケース、テスト手順、テスト結果の間で双方向のトレーサビリティを検証し更新する。
がんばる。
テスト完了
テスト完了の活動では、完了したテストの全活動のデータを集め、プロジェクトから得たこと、テストウェア、およびその他の関連する情報すべてをまとめる。
なる。
割とリリース直後ってドタバタしていて、きれいにまとめられず、後で・・・っていってずっとやらない・・・みたいなのが比較的多い気がする。
良くない。
- すべての欠陥レポートがクローズしていることを確認する。または、テスト実行の終了時に未解決として残されている欠陥について変更要求またはプロダクトバックログアイテムを作成する。
まぁ、普通っすね。
- テストサマリーレポートを作成して、ステークホルダーに提出する。
どんな粒度のレポートかはケースバイケースなんだろうな。
目的に記載があったように、「ステークホルダーが意思決定できるだけの情報」は必須なんだろうな。
- テスト環境、テストデータ、テストインフラストラクチャー、その他のテストウェアを次回も使えるように整理し保管する。
- テストウェアをメンテナンスチーム、他のプロジェクトチーム、および／またはその使用により利益を得る可能性のある他のステークホルダーに引き継ぐ。
- 完了したテスト活動から得られた教訓を分析し、次回のイテレーションやリリース、プロジェクトのために必要な変更を決定する。
- 収集した情報をテストプロセスの成熟度を改善するために利用する。
振り返り、必要なノウハウを蓄積し、再利用可能な状態にしておく・・・
ここがいつもおざなりになってしまう・・・ちゃんとやらなくちゃなぁ・・・
K2理解 テストプロセスを支援する多くの作業成果物を区別できる。
テスト作業成果物は、テストプロセスの一環として作成する。組織ごとにテストプロセスの現場での適用のされ方は大きく異なるため、テストプロセスで作成する作業成果物の種類、それらの体系や使われ方、成果物名も大きく異なる。
本シラバスでは、前述したテストプロセス、本シラバスまたは ISTQB 標準用語集で説明する作業成果物に従う。
うぃっす。万能なテストプロセスが存在しない以上、万能な成果物もまた存在しないと心得ます。
- テスト計画
- テストのモニタリングとコントロール
- テスト分析
- テスト設計
- テスト実装
- テスト実行
- テスト完了
テスト計画
- テスト計画書
- テストベースに関する情報
- 「テストのモニタリングとコントロール」で使用する終了基準
- トレーサビリティに関する情報
テスト計画書は5.2節でまた説明があるらしい。
う～んプロセス系は5.x節に飛ばされることが多いから、この時点では概略だけ抑えておけばいいってだけなのだろうか・・・？
一旦、そういうことにしよう。
テストのモニタリングとコントロール
- テストレポート（随時または定期的に作成）
- 進捗（完了マイルストーンで作成することが多い）
- タスクの完了/リソースの割当や使用状況/工数など（これらマネジメント領域にも言及する）
- サマリー
- 進捗（完了マイルストーンで作成することが多い）
インプットは、レポート作成時点の情報。
アウトプットは、読み手に合わせた情報であること。
詳しくは、5.3節へ。
テスト分析
- テスト条件（決定して優先順位を付けた状態）
- テストベースとの双方向のトレーサビリティを確立していること
探索的テストのテスト分析では、「テストチャータ」を作成する場合がある。
う～ん。「テストチャータ」と「テスト計画」はどう違うんだろうか・・・
テストチャータはこういうものらしい。なるほど、テスト計画とは違うわ。
日本ナレッジ技術WGのブログ - 【探索的テスト】④テストチャーター その１(2017/7/11)
テスト設計
テスト設計の結果は、テスト分析で決定したテスト条件を実行するためのテストケースとテストケースのセットになる。
文章として何を言っているのか分からんかった・・・
分からなさすぎるので原文見るか・・・
During test design, the test conditions are elaborated into high-level test cases, sets of high-level test cases, and other testware.
自力翻訳すると・・・
テスト設計のタイミングで、テスト条件は「概略レベルのテストケース」「概略レベルのテストケースのセット」および「その他テストウェア」に落とし込まれる。
設計工程でもまだhigh-levelなのか・・・。てっきり、low-levelまで落とし込むのかと思ってた。まぁただのタイミングの問題だから、そこまで拘らなくていいか。
具体的な入力データと期待結果の値を記載しない高位レベルテストケースを設計することがよい実践例だといえる。
高位レベルテストケースは、テストサイクルに応じた具体的な値を指定して複数のテストサイクルで再利用できる上に、テストケースの範囲を適切に文書化できる。
high-levelってどういうことかってのは、こういうことか。具体的な値は記載しないレベル感をhigh-levelって言うんだな。
テスト設計では、必要なテストデータの設計、および／または識別も行う。また、テスト環境の設計およびインフラストラクチャーとツールの識別も行う。ただし、これらを文書化する度合いは、状況によって大幅に異なる。
うぃっす。
こういう状況なら詳細化したほうがいいとか、指針があると嬉しいなぁ。
まぁそこは経験を積んで、「問題があるのが見えているなら、詳細化する」って流れなのかな。
テスト実装
- テスト手順とそれらの順序付け
- テストスイート
- テスト実行スケジュール
成果物isこれら。
トレーサビリティを介して、テスト計画書で定めたカバレッジ基準の達成度が把握できるようになることが理想である。
理想だ。わかる。
この理想的な成果物をサンプルとして是非見たい。。。
他の記述は、読む以上の話が無い気がするので、割愛。
テスト実行
- テストケースまたはテスト手順のステータスに関するドキュメント（例えば、テスト実行可能、合格、不合格、ブロック、意図的にスキップなど）
- 欠陥レポート（5.6 節を参照）
- テストアイテム、テスト対象、テストツール、テストウェアに関するドキュメント
成果物isこれら。
トレーサビリティにより、テストカバレッジ基準が満たされたことを検証でき、テストの結果をステークホルダーが理解できる言葉で報告できる。
わかる。
テスト完了
- テストサマリーレポート
- アクションアイテム（改善案）
- 変更要求（プロダクトバックログアイテム）
- テストウェア
K2理解 テストベースとテスト作業成果物との間のトレーサビリティを維持することがなぜ必要であるかを説明する。
- 変更の影響度を分析する。
- テストを監査可能にする。
- IT ガバナンス基準を満たす。
- テストベースの要素のステータスを含めることで、テスト進捗レポートとテストサマリーレポートの理解しやすさを向上する。
- テストの技術的な側面をステークホルダーにとってなじみのある言葉で説明する。
- ビジネスゴールに対するプロダクトの品質、プロセス能力およびプロジェクト進捗の評価に関する情報を提供する。
わかる。ただ、効率的なやり方が分かってない・・・
本節で概説しているテスト作業成果物の一部、またはすべてに合致するテスト作業成果物モデルを提供するテストマネジメントツールもある。
へー。そんなんあるんか。探してみよう。
あー、ググると確かにちらほらヒットするのね。全然中身は見てないけど、存在しているのは理解した。
なんか会社に言って使ってみたいけど、評判を知りたいところだ・・・
テスト界隈の人はどういうの使っているんだろう・・・いにしえのExcel管理だったりするのかな・・・
1.5 テストの心理学
K2理解 テストの成否は心理的要素に影響されることを識別する。
- 確証バイアスによって、持っている信念に合わない情報を受け入れがたくする。
- 認知バイアスによって、理解・受入をさらに困難にする場合がある。
対策としては「これらの心理的傾向を軽減するためには、欠陥や故障に関する情報を建設的な方法で伝えるべきである。」とのこと。
テスト担当者およびテストマネージャーは、欠陥、故障、テスト結果、テストの進捗、リスクの情報を効果的に伝えることができ、同僚と建設的な関係を構築するための優れた対人スキルが必要となる。
なんか、テスト担当者のハードル高すぎない？？？いやまぁ、誰でもテキトーにできるような仕事とは思わないけどさ。
具体的には以下の方法が上げられている。
- 対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであることを再認識するとよい。
- テストの利点を強調する。例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る。
- テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする。客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレビューしたりする。
- 他人の気持ちや、他人が情報に対して否定的に反応した理由を理解するように努力する。
- 自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する。
こういうのって、個別の話をするまえに、目的をすり合わせたり、お互いの役割を話し合ったりなどの下準備/関係性づくりが大切なイメージ。
ドラッカー風エクササイズとかそういうヤツ。
典型的なテスト目的については 1.1 節で前述しているが、テスト目的を適切かつ明確に定義することが心理的に大きな影響を持つ。
と思ったら、書いてあった。
K2理解 テストの活動とソフトウェア開発の活動で必要となるマインドセットが違うことを説明する。
開発担当者とテスト担当者は、異なった考え方をすることが多い。
(中略)
両者のマインドセットを組み合わせることで、より高いレベルのプロダクト品質を達成できる。
わかる。
最近はこれを仕組みでカバーできないかなぁ・・・とかぼんやり思ってる。
いつも、見つかってからバトル！2みたいなノリなので、プロセスとか役割とか目的とかをすり合わせることでもうちょっとなんとかなる気がしてる。（具体的にはイメージついてない。）
特に大規模、複雑、またはセーフティクリティカルなシステムにおいては、独立したテスト担当者がテスト活動のいくつかを担うと効果的な欠陥検出ができる。独立したテスト担当者は、作業成果物の作成者（ビジネスアナリスト、プロダクトオーナー、設計者、プログラマー）とは異なる認知バイアスと観点を持つためである。
自分は兼務することが多いんだけど、やっぱりできれば独立したいなぁ。
さいごに
175minどころじゃないくらい時間かかっている・・・
興味が横道にそれすぎている・・・その分理解も深まってる気はするけど・・・
またあと2～6章があるのに・・・最後まで走りきれるだろうか・・・
現場にすぐにでも適用したいこと
（なんとなくゴールイメージが沸いているもの）
- 偏在ポイントの蓄積
- 個人のノウハウになっているのを、組織のノウハウとしてまとめたい。
- シラバスに記載されたプロセス/成果物イメージに沿ってテスト成果物を作成する
- サンプルがみたい・・・
継続して考え続けたい
（ゴールイメージがそこまで沸いてないもの）
- 結局我々が保証している品質レベルってどのレベルなのか？
- 稀にお客様の中に「バグゼロは当たり前！」みたいな偏った人がいるので、そういう人に向けてちゃんとメッセージを出さないといけない感覚が強くなった
- テストレポートをもっと顧客の意思決定に近づける
- 「保証レベルを明確にしてから」じゃないと、話が伝わらない気がするけど、もっと意思決定のそばにいられるようなレポートにすべきと感じた。イメージはまだ沸いてない。
- 適切なテスト分析のやり方
- ISTQBのエキスパートレベルを参照したら分かるかも
- テスト成果物間におけるトレーサビリティの実現
- ツールあるっぽいからそれを試すのが最初かな？
- テスト担当と、開発担当とで協力関係をうまく気づきあげる仕組み
- 感覚的にスクラムのノウハウが使えそうな予感
以上です。
-
超絶横道だけど、「悪魔の証明」って、最初は「土地や物品等の所有権が誰に帰属するのか過去に遡って証明することの困難さ」だったのね。また、悪魔の証明＝「存在しないことは表明できない」的なニュアンスで思ってたけど、「証明することが不可能か非常に困難な事象を悪魔に例えたものをいう。」らしいので、それ以外にも証明が困難なもの全般を指すんだなぁ。ほー。 参考： wikipedia - 悪魔の証明 ↩
-
仲は良い（念の為） ↩