1. はじめに（記事作成の背景）
保守運用の向上を目指し、初めてテスト設計と実施に取り組むことになりました。 その学習の一環として、名著『知識ゼロから学ぶソフトウェアテスト』を参考に、実務で意識すべきテストの考え方を整理しました。
2. 参考文献
高橋寿一 著、『知識ゼロから学ぶソフトウェアテスト 【改訂版】』（翔泳社、2013年）
3. テスト担当者が持つべき「5つの心得」
テストを始める前に、まず以下のマインドセットを持つことが重要です。
a) バグは「ゼロ」にできない ソフトウェアは非常に複雑なため、全てのバグを見つけ出すのは不可能です（Cem Kaner）。
b) バグは「偏在」する（4%の法則） バグの47%は、プログラム全体のわずか4%に集中しているという説があります。
c) 「2:8の法則」で優先順位をつける 闇雲にテストするのではなく、バグが出やすい箇所を重点的に攻めるのが効率的です。
d) 投資対効果を考える 完璧を目指しすぎず、修正コストや重要度に見合った「十分な品質」を目指します。
e) テストケースを書き切る難しさを知る コードを書くより、漏れのない「テストケース」を設計するほうが高度なスキルを要します。
【例題】三角形判定プログラム 「3つの整数を入力し、それが『不等辺三角形』『二等辺三角形』『正三角形』のどれかを判定するプログラム」 ―― このテストケースを漏れなく書けますか？（※答えはぜひ書籍で確認してみてください！）
4. ホワイトボックステスト：論理構造を検証する
プログラムの内部構造（ロジック）が正しいかを解析する手法です。
カバレッジ（網羅率）の重要性
ステートメントカバレッジ（命令網羅）：全ての行を実行したか。
ブランチカバレッジ（分岐網羅）：全ての分岐（Yes/No）を通ったか。
目標値の目安
通常の商用テスト：60〜90%
厳格な現場：80%以上を目安に計画を立てます。
5. ブラックボックステスト：機能と仕様を検証する
内部構造は気にせず、入力に対して期待通りの出力が得られるかを確認します。
代表的な3つの手法
同値分割法・境界値分析：入力と出力の「境目」を重点的にチェック。
ディシジョンテーブル：複雑な条件の組み合わせを表（状態・ルール・動作）にして整理。
状態遷移テスト：GUIや通信プロトコルなど、状況によって動作が変わる仕組みに有効。
バグ発見率の現実 テストでのバグ発見率は60%程度が現実的です。早期にこの60%を叩き出し、「なぜ残りのバグが発生したのか」「どう防ぐか」という分析に時間を割くのが賢明な運用です。
6. テストプランと自動化の勘所
テストプランの標準化
国際規格「IEEE 829」のテンプレートを参考にすると漏れがありません。
テストケースの品質
再現性が必須です。誰がやっても同じ結果になる必要があります。
ケース数の目安は、コード10〜15行につき1ケース程度（日立ソフトの事例など）。
管理ツール（Zephyrなど）の活用も有効です。
自動化の罠
自動化はアピールしやすいですが、何を持って「正解（パス）」とするかの判断は人間にしかできません。自動化自体が目的にならないよう注意が必要です。
7. まとめと今後のアクション
今回、テストの全体像を学んだことで、以下の習慣を開発に取り入れようと考えています。
バグのレベル分け：重要度に応じた優先順位付け。
サンプリングテスト：効率的な検証。
標準化の意識：ISTQB（国際的なテスト資格団体）の基準を学び、共通言語でテストを語れるようになること。
「とりあえず動く」から「品質が担保されている」開発者へステップアップしていきたいと思います！
最後まで読んでいただきありがとうございました！