花陽「前回の話で、品質って複雑なものだから、手当たり次第にテストしても駄目なのはわかったよね」
ことり「ちゃんと考えないといけないのはわかったけど、でもすごく難しそう」
穂乃果「やっぱり穂乃果の頭じゃ難しいのかなあ」
花陽「・・・」
ことり「・・・」
穂乃果「あ、あれ？」
ことり「順番的には、今回は穂乃果ちゃんが講師かなって」
穂乃果「いやー穂乃果、勉強会は教わる専門だからさー、ははは」
ことり「廃校」
穂乃果「やる！やるったらやる！次回！」
花陽「はあ・・・じゃ、今回も花陽が」
ことり「うん、よろしくね花陽ちゃん。あと、穂乃果ちゃんは『誠意』見せてね♪」
穂乃果「あう・・・今度ケーキおごります・・・」
花陽（ことりちゃんが怖いです・・・）
IEEE829ドキュメント体系
花陽「今回はIEEE829っていう規格に従って話をするけど、作成すべきドキュメントセットとしてこういうものが定められてるの」
- Test Plan (テスト計画書)
- Test Design Spec (テスト設計仕様書)
- Test Case Spec (テストケース仕様書)
- Test Proc Spec (テスト手順書)
- Test Log (テスト結果記録)
- Test Incident Report (インシデントレポート)
- Test Summary Report (テストサマリレポート)
穂乃果「・・・帰って、いいかな？」
花陽「は、廃校・・・」
穂乃果「はいっ！ ・・・ああ、ついに花陽ちゃんにまで・・・」
花陽「これは、計画に従って効率的に漏れのないようにテストしていくためのプロセスと対応しているんです。大まかな方針から具体的なテスト手順まで段階的にかみ砕いていくんだよ」
ことり「最初から1つ1つのパターン考えてたら大変だもんね～」
花陽「各ドキュメントは目次とかまで決まってたりするんだけど、すごくボリュームがあるから概要説明にとどめるね」
穂乃果「そんなにたくさん書くの？」
花陽「例えば、テスト計画書だと・・・」
- テスト計画識別番号
- はじめに(序文)
- テストアイテム
- テストすべき機能
- テストしない機能
- アプローチ
- 合否判定基準
- テスト中止 / 再開基準
- テスト成果物
- テストのタスク
- 環境要件
- 責任範囲
- 要員計画とトレーニング計画
- スケジュール
- リスクと対策
- 承認
穂乃果「概略でいこう！概略で！」
花陽「個人的には、そのプロジェクトに必要な内容が盛り込まれていればこの構成にこだわる必要はないと思ってます・・・」
花陽「具体的なテスト技法とかはこの後勉強していくことになると思うから、ここではこんなことを考えるんだ、というのを理解してもらえれば大丈夫、です」
テスト計画書
花陽「テスト計画書では、まずテストのスコープを定めます。スコープっていうのは、システムのどこをテストしてどこをテストしないか、ってこと」
穂乃果「全部テストするんじゃだめなの？」
花陽「できるならいいんだけど、時間や人数には限りがあるから・・・どこを重点的にテストすれば効率的に品質を確保できるか、この段階で考えます」
花陽「それから、テストアプローチを定めます。これは、例えばテストフェーズは単体テスト、結合テスト、システムテストの3段階にして、それぞれのテストでは何を担保して、みたいな」
ことり「具体的なのは、またそのうち、かな」
花陽「そうだね。とにかく、どういう構成でテストをするのか、というのを決めます」
花陽「それから、とっても重要な終了基準。どこまでやったらテストを終わりにするかです」
穂乃果「これがないと、いつまでも続いちゃうもんね」
花陽「それと、テスト始めたけどバグだらけで進まない、なんてときに中止する基準も決めます」
花陽「それから成果物。一般的には、テスト結果記録とインシデントレポートとテストサマリレポートが成果物なんだけど、必ず全部を作るとは限らないし、それ以外の成果物が必要な場合もあるから・・・」
花陽「あとはリソースとスケジュールかな。いつ、誰が、どんな機材を使ってテストするかの計画を立てておきます」
ことり「誰が、まで考えるんだ」
花陽「人によってスキルに差がありますから、腕のいい人は難しいところをお願いするとか、初心者にはトレーニング期間を用意するとか。あと、人件費」
テスト設計仕様書
花陽「テスト計画ができたら、次はテストの設計をします。設計は、具体的にどうやってテストするかを決めること」
ことり「テスト計画は何をする、テスト設計はどうする、なんだね」
花陽「そうだね。テスト計画の実現方法を決める、って考えるといいかな」
花陽「まずはじめに、『テストベース』って呼ぶものを集めます。これは設計書とか仕様書とか、議事録とかメール、場合によっては発注書とかまで。設計のための根拠になる資料です」
ことり「どう動くのが正しいのか、それを見て決めるってことかな」
花陽「うん。例えばどんな画面があってどんな入力欄とかボタンとかが付いてて、ボタン押したらどうなるのが正しい動きなのか、とかを読み取っていくんだ」
花陽「テストベースをもとにして、テスト条件を洗い出します。これは、テスト対象、って言った方が伝わりやすいかな。どんな機能があって、とか、どんな画面があって、とか」
穂乃果「うーん、たしかに条件って言葉だと微妙かなあ」
花陽「やっぱり・・・。とにかく、そのテスト条件ごとに、どういうやり方で、どういうパターンでテストするかを決めていきます」
A01: ログイン画面
- 技法
- 同値分割による入力テスト
- テストケース概要
- A01-01: 正常
- A01-02: ユーザID不正
- A01-03: パスワード不正
- A01-04: ユーザID/パスワードとも不正
- A01-05: ユーザID空欄
- A01-06: パスワード空欄
- A01-07: ユーザID/パスワードとも空欄
- 合否基準
- 全てのテストケースについてOKとなること
花陽「実際はExcelとかで作ることが多いと思うけど、内容としてはこんな感じかな」
穂乃果「ふむふむ・・・こうして見ると、いろいろ試さないといけないんだね」
花陽「これ、パターンはまだ全部じゃないよ。ただ、時間の制約とかがあるから、どこまでテストするかはこの段階で決めるんだ」
ことり「ユーザIDが不正でパスワードが空欄、みたいなパターンは入れてないんだね」
花陽「この場合だと、ユーザIDとパスワードそれぞれについて不正と空欄を試してるから、組合せまでは見ないことにしてるの。もちろん、時間があるならやった方がいいけど」
花陽「あと、環境を決めないとね。Web系だったらどのOSとどのブラウザでテストするか、スマホだったらどの機種でテストするか」
ことり「Chromeで見るのとFirefoxで見るのって微妙に違ったりするよね」
花陽「IE5.5の強敵さといったらそれはもう・・・」
穂乃果「花陽ちゃん何言ってるの！？」
テストケース仕様書とテスト手順書
花陽「テストケース仕様書とテスト手順書は、実際はひとまとめになってることも多いんだ。だから、ここではまとめて説明しちゃうね」
花陽「これもExcelで作ることが多いんだけど、ここではテキスト書きにするね」
A01-01: ログイン画面（正常）
- 環境
- OS: Windows10
- ブラウザ: Edge
- 事前条件
- ログインしていないこと
- 手順
- A01: ログイン画面を表示する
- ユーザIDに「nico」を入力する
- パスワードに「nico252」を入力する
- 「ログイン」ボタンを押下する
- 期待結果
- A02: マイページ画面へ遷移すること
花陽「フォーマットはいろいろあるけど、書く内容の基本はこんなところかな」
穂乃果「うんうん、この通りに操作すればいいんだ！簡単だねっ！」
花陽「テストケースとテスト手順を分けて書くなら、こんな感じかな」
テスト手順: A01: ログイン画面
- 事前条件
- ログインしていないこと
- 手順
- A01: ログイン画面を表示する
- ユーザIDを入力する
- パスワードを入力する
- 「ログイン」ボタンを押下する
テストケース: A01-01: ログイン画面（正常）
- 環境
- OS: Windows10
- ブラウザ: Edge
- 入力値
- ユーザID: nico
- パスワード: nico252
- 期待結果
- A02: マイページ画面へ遷移すること
ことり「テストケースは条件だけ書くようになるんだね」
花陽「分かれてる方が書きやすいけど、テストする時には資料2つ見ないといけないから、一長一短って感じです・・・」
花陽「あの、花陽、さすがに疲れたので・・・続きは、今度にしてもいいかな？」
穂乃果「そうだね。もう穂乃果もくたくただよ～」
ことり「じゃ、ケーキ食べに行こうよ。もちろん、穂乃果ちゃんのおごりで♪」
穂乃果「はっ、そうだった・・・」
