[読書メモ]ソフトウェアテストの教科書をざっくり読んでみた
最初に
【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版] を読んでいる際に、個人的につけていたメモです。
いわゆるまとめ記事ではなく、内容も飛び飛びで自分の感想もりもりですが、参考になれば。
全体的にウォーターフォール開発がベースになっているような構成ではあるのですが、開発手法に関係なく普遍的に有用な考え方が詰まっていて読んでいて損はない本かなと思いました。
Part1：ソフトウェアテストの基本
Chapter1：ソフトウェアテストとは
品質の良いソフトウェアとは、それを利用するユーザーに対してユーザーが期待している便益を提供できるソフトウェアのことを指す。
そのため、ソフトウェアテストのことを考える際には、「ユーザーからの視点」を持ち、多角的に考える必要がある。
その際、ユーザの満足とソフトウェアの品質の関係性を表に起こした「狩野モデル」に基づいてテスト対象のソフトウェアが担保すべき品質を整理することが重要となる。
狩野モデルでいうところの魅力的品質を必ずしも満たす必要がない場合においても、そのような観点を持ったうえでテストにあたり、課題点を見つけられたとしたら、次の改修に生かすこともできる。
狩野モデルについては以下が詳しい。
Chapter2：ソフトウェア開発の流れとテスト工程
テスト観点とはテストの切り口のことであり、対象となる機能の品質が十分かどうかを確認するためのチェックポイントともいえる。
1つの機能に対して、一つのテスト観点のみで十分とは限らず、複数の観点を組み合わせてチェックする必要があることも。
実装した機能に対して、どのような観点が必要かをなるべくもれなく洗い出すためには、テスト観点一覧表が有用である。
ISOで示されている8つの品質特性をもとに作成したり、インターネットで共有されている知見を基にして作成したりと、作成する方法は色々あるが、一覧化して同じ組織内で活用するためのベースラインを整備することはチームやグループ単位としての品質レベルを支えるためにもやるべきだなと感じた。
Chapter3：ホワイトボックステストとブラックボックステスト
ホワイトボックステスト
モジュール内部の論理構造がわかっている状態で、期待通りの論理構造となっているかを確認するテストとなる。
論理構造とは、期待される結果を導き出すための処理や実行順序のことを指しており、期待される結果を出すための論理構造は必ずしも一意に定まらないことも留意する必要がある。
制御フローテスト
制御フローテストとは、ホワイトボックステストの内、「命令文」「分岐した経路」「条件」のいずれかに着目して、これらすべてが実行されているかを確認するためのテストのことを意味する。
この際、着目した項目はカバレッジ基準と呼ばれる。
制御フローテストを実施すする場合は、大まかに以下の順序でテストが実施される。
- モジュールの論理構造をフローチャートに起こす
- カバレッジ基準を選定する
- カバレッジ基準を網羅するための経路を選定する
- 選定した経路を通るようにモジュールを実行する
カバレッジ基準について
- ステートメントカバレッジ
制御フローテストにおいて、 すべての命令文（分岐と処理）が通るようにテストを実施する必要がある。 - デシジョンカバレッジ
制御フローテストにおいて、プログラム内の全ての分岐（if文や条件式）の真(True)と偽(False)が1回以上実行されることを確認する必要がある。
例えば if (A > 0) がある場合、「A > 0 のとき」と「A <= 0 のとき」の両方を通る必要がある。
ステートメントカバレッジを包含したテストに必ずなる。 - 復号条件カバレッジ
制御フローテストにおいて、すべての条件における分岐それぞれにおけるパターンをすべて満たすように実施する必要がある。
例えば、変数Aと変数Bの値によって分岐結果が変わる以下のようなIF文が存在していた場合、最終的にIF文の結果が同一であっても内部的な値の組み合わせパターンとしては以下になる。
例：if (A > 0 and B > 0) の場合、
・(A>0, B>0)
・(A>0, B<=0)
・(A<=0, B>0)
・(A<=0, B<=0)
の4通りをすべてテストする必要がある。
なお、デシジョンカバレッジを包含する。
Part2：様々なテスト技法
Chapter4：同値分割テスト・境界値テスト
同値パーティションと内部構造
同値パーティションは仕様書などコードの内部実装以外の部分から内部構造を暗黙的に推察し、同値となりそうなグループに分ける思想となっている。
しかし当然ながら同値パーティションと内部構造が必ずしも一致するわけではない。ブラックボックスとして考える以上、ある程度乖離することはリスクとしてあるので、テスト仕様について開発者ともディスカッションしたうえでテスト設計を行うことが有効となる。
Chapter5：デシジョンテーブルテスト
デシジョンテーブルの基本的な書き方から、使い方までざっくりと説明しておりとても分かりやすかった。
単に作り方だけではなくて、業務にうまく導入するためのコツ的なのが差し込まれていたのがGood。こういう本が好き。
- デシジョンテーブル上の1ケースはそのままテストケースに活用できるが、同時にそれらのケースがテストの具体的な詳細が明記されているとは限らないので、都度バランスを考えてテストを実施するのが肝要、とか。
- 結局バランスということをはっきり言ってくれる本は良い本。
Chapter6：状態遷移テスト
仕様書として文字で書かれた内容を図示化したものが状態遷移図や、状態遷移表となるが、図示化することが状態遷移図を作成する目的ではない。
状態遷移図にすることで、現状の仕様書に書かれていない部分の仕様がないかを洗い出したり、抜け漏れがないかを確認するためのきっかけづくりとできるところが一番のメリットかもしれない。
そのうえで、テスト対象のシステムを利用する流れを想定した場合においてどのような状態遷移が行われるか、またどのような操作を行えば期待通りの遷移が実行されるかを整理してテストケースに落としていくことが重要かも。
デシジョンテーブルも状態遷移図の作成も、人間がテスト対象のシステムの細かいところをなるべくもれなくきちんと理解するためのフレームワークという点では同じだなと感じてきた。
テスト対象のシステムがきちんと理解できること。それが良いテストを作る最初かもしれない。文字にすると当たり前すぎるな。。。
状態遷移表の作成
状態遷移表の作成のパターンとして、「状態×状態」よりも「状態×イベント」の方が以下の点から推奨されていた。
- 状態の抽出が不足していても、関係するイベントが抽出できていれば、状態の抽出漏れに気づきやすい（このボタン押したときの状態が漏れている！？的な）
- 逆にイベントの抽出が不足していても、洗い出した状態から逆算して、イベントの抽出漏れに気づきやすい（この状態になる時のイベントはこれで全部か！？的な）
状態×状態の場合は、このような経路では抜け漏れを検知しにくそうなので納得だった。
Chapter7：組み立てせテスト技法
省略。分かりやすかった。
Chapter8：テスト技法適用チャート
これまでの章で出てきた技法をどのような場面で用いると有効化を具体例を交えてガイドしてくれる内容の章だった。
普段の業務の中でテストに関して迷ったらここ読むと次のアプローチがはっきりしそうで良いなと思った。
Part3：テストドキュメントとモニタリング
Chapter9：テストドキュメントの作成
機能動作確認一覧
テスト対象から検証すべき機能を抽出し、テストの大まかな内容のたたき台を作成するために「機能動作確認一覧」の作成は非常に有効となってくる。
機能動作確認一覧の作成の際には、Must系（できる操作）Never系（できない操作）という枠組みで洗い出すと良い。
特に、Never系は機能仕様書内では当たり前の前提として省略されている部分があったりと十分な起債がされていないことで、実装後の内容には含まれていないこともあるからだ。
Must・Neverそれぞれの観点であら出した内容に対して、Checking（仕様通りにできることを確認）とTesting（バグを出しに行くための確認）として2つの系統でテスト内容を洗い出すことで、抜け漏れなくバグを抽出できる。
Chapter10：テストドキュメントの正しい書き方
記述の粒度
テスト設計仕様書をはじめとした各ドキュメントにおいて、記述の粒度に気を配る必要がある。
適切な記述の粒度は読み手の性質によって異なるため、誰が読むドキュメントなのかによって適宜調整が必要となる。
特に、テストを実施する人とテスト設計仕様書を書く人が同一の場合、記述の粒度が自分主体によりすぎてしまう可能性が高そうだと感じた。
粒度の話もそうだが、テスト全般において複数人でテストを実施する場合における認識齟齬やテストケースの抜け漏れを防ぐための考え方など、日本語が持つ良くも悪くもあるあいまいさをどう飼いならすかという話が多いなという気がしてきた。
Chapter11：テスト実施のモニタリング
発見された不具合の件数と解決済みの不具合の件数をそれぞれ累積のグラフで比較する信頼度成長曲線の話が詳しく書いてあり良かった。
- 立ち上がりの角度を大きくするために、バグが潜んでいそうな箇所を狙い撃ちする
- 中盤はできるだけ早く角度を小さくする（バグを見つけきる）
- 終盤はグラフが水平な状態、すなわち新規の不具合が見つからない状態をめざす。
Part4：次のステップへ
割と内容が軽めだったので割愛する。
開発手法が何であれ、品質に対する考え方（満たすべき要求レベルがどうなっていて、そのために必要なテストが何か）は同一というのは当たり前のようで意外と忘れがちなので肝に銘じたい。
Discussion