某MLで「チームメンバーにテストの勉強をしてもらうにはISTQBのシラバスがいい」という話を聞いた。ISTQBはソフトウェア・テストに関する国際的な資格認定団体のことである。もちろん英語なのだけれども、日本ではJSTQBという団体が翻訳や日本語情報を発信している。というわけで、JSTQBのシラバスを読んでいろいろ考えてみたこと。
Foundation Level シラバスを読んでみた
というわけで上記でダウンロード(無料)できるシラバスのうち、今回は基礎的なFoundation Level シラバスを読んでみた。全部で81ページ。
- コンパクトにソフトウェア・テストに関する知識が詰め込まれていて良い
- 各章に目安としての「学習時間」が書かれている。
- 単純に合算すると14時間ほどの自習になる。が、実際には既に知っている知識などはすっ飛ばせば良いので、そこまで時間はかからない。
- 「テストの7原則」というものが紹介されていて興味深い
- 原則 1：テストは欠陥があることしか示せない
- テストにより、欠陥があることはわかるが、欠陥がないことは示せない。テストにより、ソフトウェアに残る未摘出欠陥の数を減らせるが、欠陥が摘出できない状態でも、正しさの証明とはならない。
- 原則 2：全数テストは不可能
- 全てをテストすること(入力条件の全組み合わせ)は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスクや優先順位によりテストの焦点を絞る。
- 原則 3：初期テスト
- 早く欠陥を見つけるために、テストはソフトウェア開発もしくはシステム開発のライフサイクルのなるべく早い時期に開始し、あらかじめ定義した目的に集中すべきである。
- 原則 4：欠陥の偏在
- テストは、モジュールごとの欠陥密度の予測や直近の観察結果に比例してテストの焦点を絞らなければならない。リリース前のテストで見つかる欠陥や運用時の故障の大部分は、ある特定の少数モジュールに集中する。
- 原則 5：殺虫剤のパラドックス
- 同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストケースを定期的に見直して、改定する必要がある。ソフトウェアやシステムのいろいろな部分に対しテストを実行して多数の欠陥を摘出するには、これまでと違うテストケースが必要となる。
- 原則 6：テストは条件次第
- 条件が異なれば、テストの方法も変わる。例えば、高信頼性が必要な 24 時間稼動するシステムのテストは、e コマースのテストとは異なる。
- 原則 7：「バグゼロ」の落とし穴
- 欠陥を見つけて修正しても、構築したシステムが使えなかったり、ユーザの要件や期待を満足したりしなければ役に立たない。
「テスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02」より引用
- こちらの解説が詳しい → ソフトウェアテストの基礎：ソフトウェアテストの7原則 | Knowledge Note
情報共有に使えないか
実はJSTQBを自分はこれまで避けていた。初心者向けの内容だと思い込んでいて、若手に読むことを勧める割りには自分ではあまり詳しく読んでなかった（大反省）。その認識は大間違いだ。むしろ、様々な局面で、プロジェクトの利害関係者の認識合わせに使ったほうが良いドキュメントだと思う。
自分のまわりのプロジェクトだけの問題かもしれにけれど、ソフトウェアテストはものすごく現場の方言が多くて、なかなか情報共有が難しい印象がある。また、一言で「単体テスト」だの「システムテスト」といっても、その意味が違ったりするのでややこしい。
シラバス自体が割とコンパクトなので全体を読み合わせてもいいけれど、むしろ目次などをチェックリストがわりに使って認識あわせしてもいいと思う。
イメージはこんな感じ。項目はもうちょっと削ってもいいかも。
| 項目 | 知ってる？ | このプロジェクトではどうする？ |
|---|---|---|
| 1. テストの基礎 | ||
| 1.1. テストの必要性 | ||
| 1.1.1. ソフトウェアシステムの状況 | ||
| 1.1.2. ソフトウェアの欠陥の原因 | ||
| 1.1.3. ソフトウェアの開発、保守、運用におけるテストの役割 | ||
| 1.1.4. テストと品質 | ||
| 1.1.5. テストの十分性 | ||
| 1.2. テストとは何か？ | ||
| 1.3. テストの7 原則 | ||
| 1.4. 基本的なテストプロセス | ||
| 1.4.1. テスト計画作業とコントロール | ||
| 1.4.2. テストの分析と設計 | ||
| 1.4.3. テストの実装と実行 | ||
| 1.4.4. 終了基準の評価とレポート | ||
| 1.4.5. 終了作業 | ||
| 1.5. テストの心理学 | ||
| 1.6. 行動規範 | ||
| 2. ソフトウェアライフサイクルを通じてのテスト | ||
| 2.1. ソフトウェア開発モデル | ||
| 2.1.1. V 字モデル(シーケンシャル開発モデル) | ||
| 2.1.2. イテレーティブ-インクリメンタル開発モデル | ||
| 2.1.3. ライフサイクルモデルの中のテスト | ||
| 2.2. テストレベル | ||
| 2.2.1. コンポーネントテスト | ||
| 2.2.2. 統合テスト | ||
| 2.2.3. システムテスト | ||
| 2.2.4. 受け入れテスト | ||
| 2.3. テストタイプ | ||
| 2.3.1. 機能のテスト(機能テスト) | ||
| 2.3.2. 機能以外の特性のテスト(非機能テスト) | ||
| 2.3.3. ソフトウェアの構造／アーキテクチャのテスト(構造テスト) | ||
| 2.3.4. 変更部分のテスト：再テスト、および回帰テスト | ||
| 2.4. 保守テスト | ||
| 3. 静的技法 | ||
| 3.1. 静的技法とテストプロセス | ||
| 3.2. レビュープロセス | ||
| 3.2.1. 公式レビューの活動 | ||
| 3.2.2. 役割と責任 | ||
| 3.2.3. レビューの種類 | ||
| 3.2.4. レビューを成功させるために | ||
| 3.3. ツールによる静的解析 | ||
| 4. テスト設計技法 | ||
| 4.1. テスト開発プロセス | ||
| 4.2. テスト設計技法のカテゴリ | ||
| 4.3. 仕様ベース/ブラックボックスのテスト技法 | ||
| 4.3.1. 同値分割法 | ||
| 4.3.2. 境界値分析 | ||
| 4.3.3. デシジョンテーブルテスト | ||
| 4.3.4. 状態遷移テスト | ||
| 4.3.5. ユースケーステスト | ||
| 4.4. 構造ベース/ホワイトボックスのテスト技法 | ||
| 4.4.1. ステートメントテストとカバレッジ | ||
| 4.4.2. デシジョンテストとカバレッジ | ||
| 4.4.3. その他の構造ベース技法 | ||
| 4.5. 経験ベースのテスト技法 | ||
| 4.6. テスト技法の選択 | ||
| 5. テストのマネジメント | ||
| 5.1. テスト組織 | ||
| 5.1.1. テスト組織と独立性 | ||
| 5.1.2. テストリーダとテスト担当者の作業 | ||
| 5.2. テスト計画作業と見積り | ||
| 5.2.1. テスト計画作業 | ||
| 5.2.2. テスト計画策定 | ||
| 5.2.3. 開始基準 | ||
| 5.2.4. 終了基準 | ||
| 5.2.5. テスト見積り | ||
| 5.2.6. テスト戦略、テストアプローチ | ||
| 5.3. テスト進捗のモニタリングとコントロール | ||
| 5.3.1. テスト進捗モニタリング | ||
| 5.3.2. テストレポート | ||
| 5.3.3. テストコントロール | ||
| 5.4. 構成管理 | ||
| 5.5. リスクとテスト | ||
| 5.5.1. プロジェクトリスク | ||
| 5.5.2. プロダクトリスク | ||
| 5.6. インシデント管理 | ||
| 6. テスト支援ツール | ||
| 6.1. テストツールの種類 | ||
| 6.1.1. ツールによるテストへの支援 | ||
| 6.1.2. テストツールの分類 | ||
| 6.1.3. テストマネジメントの支援用ツール | ||
| 6.1.4. 静的テスト支援ツール | ||
| 6.1.5. テスト仕様の支援ツール | ||
| 6.1.6. テスト実行と結果記録の支援ツール | ||
| 6.1.7. 性能・モニタリング支援ツール | ||
| 6.1.8. 特定のテストに対する支援ツール | ||
| 6.2. ツールの効果的な使い方：利点とリスク | ||
| 6.2.1. ツールでテストを支援する利点とリスク (全ツール) | ||
| 6.2.2. 個別ツールの使用上の注意 | ||
| 6.3. 組織へのツールの導入 |
（「テスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02」に基づいて作成）
