ソフトウェアのテスト技法 4日目

ユースケーステスト（昨日の続き）

例題を確認。
定義をした後に、実際にテストケースをどうやって抽出するかのお話。
トランザクションに注目するということで、例外処理のパスをどうやって通すかに言及され、ツールが紹介されていましたが、アクセスしたらNot Foundでしたよね……
ツール探しは別途必要。
また、実際の業務と比較しての反省は、境界値テスト、デシジョンテーブルに時間を多く割き、ユースケーステストがほぼ正常系のみに終わっているということに気が付いた。
本来はここも時間取ってケースを考えて取捨選択すべきなので、時間がとれる仕組みづくりを考える必要アリ。

ホワイトボックステスト技法

パスに注目する制御フローテストと、データフローテストがあるというお話。
制御フローテストのことしか覚えてなかったので、勉強しなおし。

制御フローテスト

コードカバレッジにだけ注目するのは危険だということをきっちり説明されていて、ここ反省。
ではどうやってフローを決めるかということで、「構造化テスト/基礎テスト」で取り方を知った。
今はほとんどブラックボックステストしかしてないし、コードを読むときもあるけど、変更箇所を重点的に読むにとどまり、「プログラム内部のフローに対するアプローチ」が徹底的に欠けていると気付いた。
RSpecで書かれている内容のチェックがコードカバレッジのみになっているので、テスト担当者がホワイトボックステストにどこまでアプローチすべきか、やはりここも仕組みを考えたい。
テスト担当者でなく、実装者にやってもらうことになるだろうけど、それならば実装者にどのように保証を貰うか。
品質保証の担当部門の位置づけにも関わってきそう。

データフローテストもちょこっと読んだけど、少しだけなのでまとめは明日。
やはりきちんとまとまった本を読むと、業務は手癖で作業していることが多いのに気が付き、ひたすら反省。
理想と現実の乖離の埋め方は永遠の課題なんだろうなぁ、お正月明けに相談したいところ。