4-1プログラミング
水曜の夜、閉店後の作業台に、開発会社から届いた設計書が広げてありました。ミナトはその横でノートパソコンを開き、焼き上がり通知のうち「誰に知らせるかを決める部分」を書いています。書き終えて試しに動かすと、すぐにスマートフォンが震えました。画面には「メロンパン 焼き上がりました（残り0個）」。棚はもう空で、最後の1個は5分前に売れていました。店長が空の棚を指さして笑います。「これを見て走ってきたお客さんに、何て言えばいいんだろうね」。書いたばかりの条件を見直すと、「残りが0個以上なら知らせる」となっていました。
設計書には「残りがあれば知らせる」と書いてあるだけでした。設計書に書かれた処理を、コンピュータが実行できる形の文に書き起こす作業をコーディングといいます。書き起こしに使うのは、文法が厳密に決められた人工の言語で、これをプログラム言語（プログラミング言語）と呼びます。Python、Java、C などがその例です。
コーディングでは、設計書が言葉で済ませていた所を、すべて決めきらなければなりません。「残り」をどのデータで表すのか。「ある」を「1以上」と書くのか「0より大きい」と書くのか。ミナトの誤りは、この最後の一歩で起きました。「以上」と「より大きい」を取り違えるだけで、0個のときにも知らせが出てしまいます。
コーディングの前に、処理の中身は手順として決まっています。問題を解くための手順を、あいまいさのない有限の段階で表したものをアルゴリズムといいます。通知のプログラムなら、「焼き上がったパンの名前を受け取る」「そのパンを登録しているお客さんを探す」「残りが1個以上で、朝7時台でなければ、一人ずつ知らせる」という手順です。同じアルゴリズムは、どのプログラム言語でも書けます。アルゴリズムが処理の中身、プログラム言語がその書き表し方です。
「そのパンを登録しているお客さんを探す」ときに読みに行く先は、データベースです。いくつものプログラムや利用者が共有して使えるように、データを整理してまとめて格納したものを指します。こむぎ堂では、お客さんとパンの登録も、パンごとの残り個数も、データベースに入っています。通知のプログラムもレジのプログラムも、同じ残り個数を読みます。
ここから基本情報！処理の組み立て方
入力されたデータに計算・変換・並べ替え・集計などの操作をして、必要な結果を得ることをデータ処理といいます。このプログラムは、「メロンパンが焼き上がった」という入力から「知らせる相手の一覧」を作り出すデータ処理です。
手順をプログラムに組み立てるときの考え方に、構造化プログラミングがあります。処理を「順次」（上から順に実行する）、「選択」（条件で分かれる）、「繰返し」（同じ処理をくり返す）の三つの基本構造だけで組み立て、処理の流れを好きな場所へ飛ばす goto 文のような命令を避けます。通知のプログラムも、受け取ってから探す（順次）、登録者を一人ずつ調べる（繰返し）、残りが1個以上かで分ける（選択）の三つで書けます。どのかたまりも入口と出口が一つずつなので、上から読めば流れを追えます。
基本情報の範囲ここまで
ミナトは条件を「残りが1個以上なら知らせる」に書き直しました。0個のときに知らせが出ないことも、その場で確かめています。これで直ったはずでした。
4-2コーディング標準と支援ツール
翌朝、開発会社の担当者がミナトのプログラムを読みました。最初に指摘されたのは、条件の誤りではありませんでした。「行の頭の空け方がばらばらで、どの『もし』の中にどの行が入っているのか、読み取るのに時間がかかります」。開発会社には、プログラムの書き方をそろえる決まりがあるそうです。
プログラムの書き方について、チームや会社で決めておく取り決めをコーディング標準（コーディング規約）と呼びます。書く人が何人いても同じ形になるので、他人が書いたプログラムでも読み違えにくく、直しやすくなります。
担当者が指摘したのは字下げです。制御構造の階層が見て分かるように、行の先頭を下げることをインデンテーション（インデント）といいます。通知のプログラムでは、「登録者を一人ずつ調べる」繰返しの中に「残りが1個以上なら」の選択があり、さらにその中に「7時台でなければ」の選択があります。このように、制御構造の内側に別の制御構造を入れ子にして書くことをネストといいます。ネストが一段深くなるごとに字下げも一段増やせば、どの行がどの条件の中にあるのかが形で分かります。
ネストは深くなるほど読みにくくなります。四段、五段と重なると、ある行がどの条件をすべて満たしたときに実行されるのか、頭の中で追いきれません。そのため、コーディング標準でネストの深さに上限を設けることもあります。
ここから基本情報！規約の中身と支援ツール
コーディング標準には、字下げやネストのほかに、変数や関数の名前の付け方を決める命名規則や、誤りを招きやすいので使わないと決めた使用禁止命令などを書きます。残り個数を表す変数を、ある人は zan、別の人は count2 と名付けると、読む人は毎回その意味を調べることになります。決まりを守らないと、読み違い、直し漏れ、人ごとの癖が積み重なり、後から直す費用が増えていきます。
決まりを人の注意だけで守るのは大変なので、エディタやツールが手助けをします。入力の途中から変数名や関数名の続きを予測して候補を出す機能がコード補完で、長い名前の打ち間違いが減ります。改行したときに、直前の行に合わせて字下げを自動で付ける機能がオートインデントです。予約語・文字列・コメントなどを種類ごとに色分けして表示する機能をシンタックスハイライトといい、閉じ忘れた引用符のような誤りが色の乱れで見つかります。
書き終えたソースコードを機械的に検査し、コーディング標準に反する所や問題になりそうな書き方を見つけ出すツールはコードオーディターと呼ばれます。ネストの深すぎる箇所や、禁止した命令を使った行を、人が読む前に一覧にしてくれます。
開発の工程全体を支えるツールもあります。コンピュータで開発作業を支援するツールをまとめて CASE ツールと呼び、そのうち要件定義や設計といった開発の初めの工程（上流工程）を支えるものを上流CASEツールといいます。図を描いて設計書を作ったり、図の間の食い違いを調べたりします。プログラムの生成やテストなど、後の工程を支えるものは下流CASEツールと呼ばれます。
基本情報の範囲ここまで
ミナトはエディタの字下げをそろえ直しました。入れ子の形が見えるようになると、「7時台でなければ」の条件が、残り個数の条件の内側に入っていることも一目で分かります。
4-3コードとテスト結果の評価
字下げを直したプログラムを送ると、担当者から表が1枚返ってきました。左の列に要件定義書の項目が並び、右へ向かって設計書の節、プログラムの部品の名前、テストの番号が書き込まれています。「焼き上がりを知らせる」の行は最後まで埋まっていました。「朝7時台は送らない」の行だけ、テストの番号の欄が空いています。
この表が確かめているのは、要件定義で決めたことが、設計・プログラム・テストへと抜けなく受け継がれているかです。要件から設計、プログラム、テストまでの対応をたどれる度合いを追跡可能性（トレーサビリティ）といいます。要件から先へたどれるだけでなく、プログラムのどの部分がどの要件のためにあるのかを逆にたどれることも求められます。
空いた欄が示しているのは、「朝7時台は送らない」という要件を確かめるテストがまだ無い、という事実です。プログラムには7時台を除く条件が書いてあっても、それが正しく動くかは誰も確かめていません。要件を一つ落としたまま次の工程へ進むと、気づくのはお客さんの朝7時のスマートフォンになります。
ここから基本情報！評価の観点
プログラムを書き終えたとき、そして部品ごとのテストを終えたときには、出来上がったソースコードとテストの結果を、決めておいた観点で評価し、レビューします。追跡可能性はその観点の一つで、ほかに次の観点が挙げられています。
| 観点 | 見ること | 焼き上がり通知での問い |
|---|---|---|
| 外部一貫性 | 設計書など、ほかの文書や上位の仕様と矛盾しないか | 設計書は「1分以内に届く」なのに、5分ごとにまとめて送っていないか |
| 内部一貫性 | そのプログラムの中で、記述どうしが矛盾しないか | ある所では残りを「個数」で、別の所では「天板の枚数」で数えていないか |
| テスト網羅性 | テストが仕様と処理をどこまで覆っているか | 「朝7時台は送らない」を確かめるテストはあるか |
| コーディング方法及び作業標準の適切性 | 選んだ書き方と作業の決まりが妥当で、守られているか | コーディング標準の字下げや名前の付け方に従っているか |
| ソフトウェア統合及びテストの実現可能性（ソフトウェア結合及びテストの実現可能性） | ほかの部品とつないでテストを進められる見込みがあるか | ボタンの部品から受け取るデータの形が、両方でそろっているか |
| 運用及び保守の実現可能性 | 動き始めた後、運用し、直していける見込みがあるか | 「7時台」を「6時台」に変えたいとき、プログラムを書き換えずに設定で変えられるか |
「統合」の観点は、以前は「結合」と書かれていました。部品をつなぎ合わせる工程を「結合」と呼んでいたころの言い方で、指している中身は同じと考えてよいでしょう。いまのシラバスの用語例は「ソフトウェア統合及びテストの実現可能性」です。
基本情報の範囲ここまで
担当者は表の空欄に「7時台の確認」と書き足し、ミナトのテストの予定に1行加えました。その行でどの時刻を試すのかは、まだ決めていませんでした。
4-4コードレビュー
金曜の夕方、開発会社とビデオ通話をつなぎ、ミナトが書いた通知の部品を3人で読むことになりました。プログラムは動かさず、画面に映したソースコードを1行ずつ追っていきます。書いたミナト自身は、どの行も「こう動くはず」と読めてしまいます。
作った人以外がソースコードを読み、誤りや改善できる所を見つける作業をコードレビューといいます。書いた本人は、自分の意図を知っているぶん、書いてあることではなく書いたつもりのことを読んでしまいます。0個のときの誤りも、ミナトは書いた直後に何度か読み返していました。
コードレビューで確かめるのは、コーディング標準を守っているか、設計書どおりに作られているか、無駄な処理がなく（効率性）、後から直しやすいか（保守性）といった点です。プログラムを動かす前に誤りを見つけられれば、直す手間は小さくて済みます。
ここから基本情報！レビューの進め方と、複雑さの数え方
コードレビューには進め方の違いがあります。同じ立場の同僚どうしが、互いのソースコードを読み合って指摘し合う形をピアコードレビューといいます（ピアは「仲間」の意味）。作成者が説明役になり、参加者と一緒に処理の流れを順に追っていく形はウォークスルーと呼ばれます。
いちばん形式が整っているのがコードインスペクション（インスペクション）です。進行役のモデレータを中心に、参加者の役割と手順をあらかじめ決め、見つけた欠陥を記録し、直ったかどうかまで確かめます。手間はかかりますが、そのぶん見落としが少なくなります。
読む人の感覚だけに頼らず、プログラムの規模や複雑さ、品質を数値で測ることをメトリクス計測といいます。行数は規模の分かりやすい物差しですが、複雑さは行数だけでは分かりません。そこでよく使われるのがサイクロマティック複雑度（循環的複雑度）で、McCabe が考えた指標です。プログラムの処理の流れを、処理を点、流れを線にしたグラフで表し、線の数を E、点の数を N とすると、一つのプログラムについて E − N ＋ 2 で求めます。
分かれ道が二つに分かれるものだけなら、もっと手早く数えられます。判定（分かれ道）の数に1を足したものが、サイクロマティック複雑度になります。このプログラムには、登録者を一人ずつ調べる繰返しの判定が1つ、「残りが1個以上か」と「7時台でないか」の判定が2つ、合わせて3つの判定があります。複雑度は 3 ＋ 1 ＝ 4 です。ただし、一つの判定の中で「かつ」「または」を使って条件を重ねたときは、条件の数だけ判定があると数えます。「7時台でないか」を「7時より前、または8時より後」と書けば、判定は一つ増えて複雑度は5になります。値が大きいほど通り道が多く、読むのもテストするのも難しくなるので、目安を超えた部品は分けることを考えます。目安としては10がよく挙げられます。
基本情報の範囲ここまで
レビューでは、変数の名前を2つ直すことになりました。条件の誤りは見つかりませんでした。見つからなかったことが、誤りが無いことの証明にはならないと分かるのは、翌週のことです。
4-5デバッグ
月曜の朝8時ちょうど、クロワッサンが焼き上がりました。ところが、登録していた常連さんの誰にも知らせが届きません。8時1分に焼き上がった食パンの知らせは、ちゃんと届いています。ミナトはプログラムを眺めても理由が分からず、相棒に打ち込みました。「動いている途中で止めて、中を見られないかな」
プログラムの中の誤り（バグ）を探し出し、原因を突き止めて取り除く作業をデバッグといいます。デバッグはおおよそ、誤りを確実に起こせるようにする（再現）、誤りのある場所を絞り込む、直す、直ったかを確かめる、の順に進みます。8時ちょうどで必ず起きるなら、再現はもうできています。
ここから基本情報！動かさずに調べる・動かして調べる
デバッグの方法は、プログラムを動かすかどうかで二つに分かれます。動かさずに、ソースコードを紙や画面の上で追い、具体的な値を手で当てはめて誤りを探すのが机上デバッグです。ミナトが「8時0分」を当てはめて条件を一つずつたどると、7時台を除く条件が「時刻が7時より前か、8時より後なら送る」になっていました。8時0分は「8時より後」に入らないので、送られなかったのです。
プログラムを実行せずに、ソースコードの構造や書き方を調べて問題を見つける方法をまとめて静的解析と呼びます。それをツールにしたものが静的テストツール（静的解析ツール）で、使われていない変数や、決して実行されない行、規約違反などを機械的に拾い出します。これに対し、プログラムを実際に動かし、その振る舞いから誤りを見つける方法を動的テストといいます。机上デバッグやレビューは、動的テストには含まれません。
動かして調べるには、試す場所とツールが要ります。デバッグに使うツールや、本番とは切り離した実行の場所をひとまとめにしたものをデバッグ環境といいます。こむぎ堂なら、本物のお客さんには送らず、ミナトのスマートフォンにだけ知らせが届く試験用の仕組みです。
中心になるツールがデバッガです。プログラムを1行ずつ実行したり（ステップ実行）、その時点の変数の値をのぞいたりできます。実行を一時的に止めたい行に付ける目印をブレークポイントといい、相棒の「止めて中を見る」はこれで実現します。7時台を調べる条件の行にブレークポイントを置いて8時0分で動かせば、条件が「偽」になる瞬間を目で見られます。
ほかにも、実行した命令の順番や変数の値の移り変わりを記録して追えるようにするトレーサーや、指定した時点のメモリや変数の中身を写し取って出力するスナップショットといったツールがあります。
誤りを早く見つけるために、プログラムの中に仕掛けを書いておく方法もあります。ある時点で必ず成り立っているはずの条件を書き込み、実行中にそれが破れたらすぐ知らせるようにする仕組みがアサーションです。「知らせを送る直前には、残りは1個以上のはず」と書いておけば、0個の知らせは送られる前に止まります。
基本情報の範囲ここまで
原因は8時ちょうどの扱いでした。ミナトは7時台を除く条件を「8時以降」を含む形に直し、8時0分と7時59分で動かして結果を確かめました。0個のときの誤りと同じく、境目の値で起きた誤りです。
4-6単体テストの目的と手順
2つの誤りを直したミナトは、「これでもう大丈夫」と言いかけて、口をつぐみました。0個の誤りも8時ちょうどの誤りも、見つけたのはたまたまです。相棒の返事は短いものでした。「たまたまに頼らず、試す値と、そのとき起きるべきことを、先に書き出しておきましょう」
ほかの部品とつなぐ前に、モジュールや関数のようなプログラムの小さな単位ごとに、仕様どおりに動くかを確かめるテストを単体テスト（ユニットテスト）といいます。焼き上がり通知でいえば、「誰に知らせるかを決める部分」だけを取り出して、ボタンやスマートフォンとはつながない状態で確かめます。部品を一つに絞れば、誤りが出たときに原因の場所も絞れます。
単体テストが探すのは、プログラムの中にある誤りです。動かしたときに不具合を引き起こす原因になる、プログラムの中の誤りを欠陥（バグ、フォールト）と呼びます。ミナトが「0個以上」と書いた行が、まさに欠陥でした。
ここから基本情報！欠陥と障害
欠陥は、書かれているだけでは誰も困らせません。欠陥が実行のときに表に出て、システムが求められたとおりに動かなくなる現象を障害（フェイラー）といいます。「0個以上」と書いた行が欠陥で、空の棚について知らせが届いたことが障害です。欠陥があっても、その行を通る条件がそろわなければ、障害は起きません。
障害が起きたら、なぜ、どのような経緯で起きたのかを明らかにします。これを障害分析といいます。ミナトの2つの障害を分析すると、どちらも「以上」と「より大きい」、「より前」と「より後」の取り違えで、境目の値でだけ起きていたことが分かります。分析の結果は、次に何を重点的に試すかを決める材料になります。
基本情報の範囲ここまで
単体テストは、思いついた値を打ち込んで終わりにはしません。いつ、誰が、どのツールで試すかを決めてテストの計画を立て、試すためのデータや場所を用意し、テストを実施して、結果を評価します。計画から評価までを一続きの手順として進めます。
ここから基本情報！テストの計画と準備
テストをどのような考え方と手順で計画し進めるかを、体系としてまとめたものをテスト方法論といいます。その中で最初に決めるのが、どこからどこまでを試すかを定めたテスト範囲です。今回のテスト範囲は「誰に知らせるかを決める部分」だけで、ボタンの部品や、スマートフォンに届くまでの仕組みは含みません。
テストを始める前に、必要なものをそろえる活動がテスト準備です。テストに使うハードウェアやソフトウェア一式をテスト環境といい、こむぎ堂では本番のデータベースの写しを使う試験用のサーバを用意しました。入力として与える値を集めたテストデータも準備します。決めた手順に従って実際にテストを実行する担当者をテスト実施者と呼び、今回はミナトがその役です。
テストの一つ一つは、入力、実行の条件、期待する結果の組で書き表します。この組をテストケースといいます。ミナトが最初に書いたのは次の3件でした。
- 残り0個、8時30分に焼き上がり → 知らせを送らない
- 残り1個、8時30分に焼き上がり → 登録者に知らせを送る
- 残り5個、7時30分に焼き上がり → 知らせを送らない
期待する結果を先に書いておくのは、動かした後で「こうなったから正しいのだろう」と結果に合わせて判断しないためです。
基本情報の範囲ここまで
試す値と起きるべきことを書き出してみると、ミナトの表は思ったより長くなりました。残り個数と時刻の組み合わせだけで、何十通りも考えられます。
4-7テストの実施と記録
次の月曜、ミナトのテストの表は40行を超えていました。残り個数と時刻を手で打ち込み、結果を表に書き写す作業に、半日かかります。しかも1か所直すたびに、前に通ったテストもやり直さなければなりません。店長が焼き上がったバゲットを並べながら聞きます。「それ、いつになったら終わるの」
テストは、実施して終わりではありません。結果を記録し、期待と違ったものについて原因を調べ、プログラムを直し、もう一度試します。記録が残っていなければ、どのテストが通り、どれが直し待ちなのかが分からなくなり、同じ誤りを二度探すことにもなります。店長の「いつ終わるの」に答えるにも、記録が要ります。
ここから基本情報！テストを進めるツールと、終わりの見きわめ
テストケースをどう作るかと、テスト全体の進み具合をどう管理するかをまとめた手法を、テスト設計と管理手法といいます。どの値を選べば少ない件数で多くの誤りを見つけられるかが設計の側、何件中何件が済み、いくつ誤りが残っているかを追うのが管理の側です。
手で値を打ち込む手間は、ツールで減らせます。指定した条件に合うテスト用の入力データを自動で作るツールをテストデータジェネレーターといいます。「残り個数は0から40、時刻は6時から20時」と条件を与えれば、組み合わせのデータを一度に作れます。
テストやレビューで見つかった誤りの原因を直し、プログラムから取り除く作業はエラー除去と呼ばれます。直したら、その誤りが本当に消えたか、ほかの所を壊していないかを、テストをやり直して確かめます。
「いつ終わるのか」の見当を付けるには、誤りの見つかり方を図にします。テストの期間を横軸に、見つかった誤りの累積数を縦軸にとって描いた曲線がバグ曲線です。テストの初めは見つかる数が少なく、慣れてくると急に増え、残りが少なくなると増え方が鈍ります。そのためS字の形になることが多く、曲線が平らになってきたら、誤りが出尽くしてきた（収束してきた）目安になります。
見つかった件数と合わせて、直し終えた件数やまだ直っていない件数の推移も追う図を、バグ管理図と呼ぶことがあります。見つかった数が平らになっても、直っていない数が減っていなければ、テストはまだ終わっていません。
基本情報の範囲ここまで
それでも、40行の表のすべてを毎回試すのは大変です。表をよく見ると、似たような行がいくつも並んでいました。
4-8ブラックボックステスト
相棒がミナトの表を読んで、問いを返してきました。「残り2個、3個、4個……と順番に試していますね。2個のときと3個のときで、プログラムの動きは違うでしょうか」。ミナトは手を止めました。2個でも3個でも、知らせは送られます。違いが出るのは、どこか別の所のはずです。
このテストの表は、プログラムの中身を見なくても作れます。仕様に「残りが1個以上なら知らせる」「朝7時台は送らない」とあれば、どんな入力でどんな結果になるべきかは決まるからです。プログラムの内部の作りを考えずに、仕様をもとに入力と期待する出力の関係だけを確かめるテストをブラックボックステストといいます。中が見えない箱として扱う、という意味の名前です。
中を見ないので、プログラムを書いていない人でもテストを作れます。書いた人の思い込みが入りにくいのも利点です。ただし、試す値を思いつくままに選んでいては、件数ばかり増えて肝心の値を落とします。相棒の問いは、その選び方を指していました。
ここから基本情報！試す値の選び方
仕様の上で同じ扱いになる入力をひとまとまり（同値クラス）に分け、各まとまりから代表の値を一つずつ選んで試す技法を同値分割法（同値分析法）といいます。2個と3個は同じまとまりに入るので、どちらか一つを試せば足ります。
まとまりの境目に注目し、その両側の値を重点的に選ぶ技法が境界値分析（限界値分析法）です。ミナトの2つの誤りは、どちらも境目で起きていました。誤りは境目に集まりやすいので、同値分割法とあわせて使います。
こむぎ堂の天板では一度に40個まで焼けるので、仕様では残り個数を0〜40としました。この範囲で分けると、次のようになります。
| 同値クラス | 期待する結果 | 同値分割法の代表値 | 境界値分析で選ぶ値 |
|---|---|---|---|
| 0未満（ありえない値） | 誤りとして受け付けない | −5 | −1 |
| 0個 | 知らせを送らない | 0 | 0 |
| 1〜40個 | 知らせを送る | 20 | 1、40 |
| 41個以上（ありえない値） | 誤りとして受け付けない | 50 | 41 |
同値分割法なら4件、境界値分析なら −1・0・1・40・41 の5件です。40行あった表の残り個数の列は、これだけで覆えます。ミナトが最初に書いた「0個以上」の誤りは、0を試せば必ず見つかります。代表値の20だけを試していたら、見逃していました。時刻も同じように、6時59分・7時0分・7時59分・8時0分が境目の値になります。
基本情報の範囲ここまで
値の選び方を変えると、テストの件数は減り、見つかる誤りはむしろ増えます。ブラックボックステストでは、仕様のどこに境目があるかを読み取ることが、テストを作る作業の中心になります。
ここから基本情報！組み合わせ・状態・残りの誤りの見積もり
条件が複数重なると、値を一つずつ選ぶだけでは足りません。入力の条件（原因）と出力（結果）の関係をグラフに表し、そこから条件の組み合わせを整理してテストケースを導く技法を原因結果グラフ法といいます。焼き上がり通知なら、原因は「焼き上がった」「残りが1個以上」「7時台でない」「そのパンを登録している」、結果は「知らせを送る」です。グラフから、どの組み合わせで結果が変わるかを表（決定表）にまとめ、その行をテストケースにします。
パンには「焼いている途中」「焼き上がり」「売り切れ」といった状態があり、出来事が起きると状態が移ります。システムがとりうる状態と、状態を移す出来事（イベント）の組み合わせが仕様どおりに動くかを確かめる技法を状態遷移テストといいます。「売り切れ」のパンに、もう一度「焼き上がり」が来たらどうなるか、のような移り方も試します。
テストでいくつ誤りが見つかったかは分かっても、まだいくつ残っているかは分かりません。そこで、わざと誤りを混ぜておく方法があります。既知の誤りを意図してプログラムに埋め込み、それがどれだけ見つかったかの割合から、まだ見つかっていない誤りの数を見積もる手法をエラー埋込法といいます。
たとえば、担当者が誤りを10個埋め込んでおき、ミナトがテストをしたところ、埋め込んだ誤りが8個、もともとあった誤りが12個見つかったとします。埋め込んだ誤りの8割が見つかったのなら、もともとの誤りも8割が見つかったと考えます。もともとの誤りの総数は 12 ÷ 0.8 ＝ 15個と見積もられ、まだ 15 − 12 ＝ 3個が残っている計算になります。
組み合わせが多すぎて全部は試せないときに使われるのが実験計画法です。複数の要因の組み合わせが結果にどう影響するかを、直交表などを使って、少ない回数で効率よく調べる統計的な手法です。スマートフォンの種類2通り、通知の設定2通り、時間帯2通りなら、全部の組み合わせは8通りです。直交表を使うと、どの2つの要因をとっても全部の組み合わせが同じ回数ずつ現れるように選んだ4通りで済ませられます。
基本情報の範囲ここまで
4-9ホワイトボックステストと網羅
境目の値を選び直したテストは、すべて通りました。ところが、担当者がプログラムを開いて一つ指摘します。「売り切れになったことを知らせる行は、この表のどのテストでも、一度も実行されていませんね」。売り切れの知らせは、常連さんへの聞き取りで出てきた要求でした。
仕様から作ったテストがすべて通っても、プログラムの中に一度も通っていない行が残ることがあります。そこで、プログラムの内部の作り、つまり命令や分かれ道の通り方に注目してテストを作り、通る道を確かめるのがホワイトボックステストです。中が見える箱として扱うので、この名前があります。
ブラックボックステストは「仕様どおりの結果になるか」を、ホワイトボックステストは「書いたプログラムの道をどこまで通したか」を確かめます。片方だけでは、仕様にない余計な動きにも、一度も試していない行にも気づけません。単体テストでは、二つを組み合わせて使います。
ここから基本情報！網羅の基準
どこまで通せば十分とするかの決まりを、網羅の基準といいます。通知のプログラムにある、次の判定で比べてみます。
もし「焼き上がった」かつ「残りが1個以上」ならば、知らせを送る（そうでなければ何もしない）
すべての命令を少なくとも1回は実行することを基準にするのが命令網羅です。この判定では、「知らせを送る」を1回実行すれば命令はすべて通ったことになるので、両方の条件が真になるテスト1件で足ります。ところが、判定が偽になる道は一度も試していません。
判定の結果が真になる道と偽になる道の両方を、少なくとも1回ずつ通すことを基準にするのが判定条件網羅（分岐網羅）です。真になる1件と、偽になる1件の、合わせて2件が要ります。命令網羅よりも強い基準です。
判定の中にある個々の条件（「焼き上がった」と「残りが1個以上」）のそれぞれについて、真と偽の両方を少なくとも1回ずつとることを基準にするのが条件網羅です。判定を作っている条件の真と偽について、ありうる組み合わせをすべて試すのが複数条件網羅で、条件が2つなら4通りになります。ここで挙げた四つの基準の中で最も厳しいものです。
| 網羅の基準 | テストケース（焼き上がった, 残り1個以上） | 判定の結果 | 件数 |
|---|---|---|---|
| 命令網羅 | （真, 真） | 真 | 1 |
| 判定条件網羅 | （真, 真）（真, 偽） | 真、偽 | 2 |
| 条件網羅 | （真, 偽）（偽, 真） | 偽、偽 | 2 |
| 複数条件網羅 | （真, 真）（真, 偽）（偽, 真）（偽, 偽） | 真、偽、偽、偽 | 4 |
テストでどれだけ通したかは、割合で表します。テストによって実行された命令や分岐が、全体のどれだけにあたるかを示す割合を網羅率（カバレッジ）といいます。このプログラムに命令が20あり、テストで実行されたのが19なら、命令の網羅率は 19 ÷ 20 ＝ 95％ です。残る1つが、売り切れの知らせを送る行でした。
網羅率を測り、テストがどこまでプログラムを通したかを評価する手法をテストカバレッジ分析（カバレッジ分析）といいます。多くはツールで行い、どの行やどの分かれ道を一度も通っていないかを示してくれます。網羅率が100％でも、仕様どおりの結果かどうかまでは分からない点には気を付けます。それはブラックボックステストの受け持ちです。
基本情報の範囲ここまで
金曜の夜、ミナトは売り切れを知らせるテストケースを表に足し、最後の1回を流しました。残り0個、1個、40個、41個。7時59分と8時0分。売り切れになったメロンパン。表の行はすべて「合格」になりました。店長は空になった棚を拭きながら言います。「0個で知らせが来たあの晩から、ずいぶん遠回りしたね」
遠回りの中身は、誤りが出る場所を偶然に任せず、先に決めておく手順でした。境目の値を選ぶ、期待する結果を先に書く、一度も通っていない行を探す。どれも、あの晩の「残り0個」の知らせを、出る前に止めるための手順です。
通知の部品は、単体テストを終えて、ボタンの部品やスマートフォンへ送る部品と組み上げる段階へ渡されました。担当者は最後に一言だけ付け足しました。「部品一つずつでは、ですけどね」。ボタンを押してからお客さんのスマートフォンに届くまでを一続きで動かしたら、何が起きるのか。それはまだ、誰も試していません。