「この1冊でよくわかるソフトウェアテストの教科書」を読みました
| 勝手に評価 | |
| ジャンル | テスト技法 |
| 概要 | 冒頭、要件定義～テストまでの流れについて記載されています。 冒頭以降は実際にテストを行う上での技法、ドキュメント、モニタリング、自動化について。 テストを体系的に学びたい方は読んでおいて損はないかと思います。 |
| レベル | 初級～中級 |
今まで私が行っていた明らかに間違っていた手法
現在担当しているプロジェクトでは、週2,3（小さめの機能追加）～2ヶ月に1回（大きめの機能）をリリースするアジャイル開発スタイルでフロントバック～単体テストを担当しています。
機能実装とテストコードを書く人が一緒になるので、テストを書く時は頭の中でパターンを思い描きながら記載していました。（自分の書いたコードはある程度頭に入ってるから大丈夫。と高を括っていました。）
脳内メモリ容量が多い人だとテストケースが漏れることなくテストを実装できる（最適なテストケースの定義を行うことができる）かと思いますが、
少し条件の複雑なコードのテストを書く際に、脳内メモリのオーバーフローが発生したり、単純に漏れていたりするケースがありました。
最悪な場合、テストケースの抜けに気が付かずユーザから不具合報告として挙がってきたりもありました…。
このように、少し頭を捻れば、または少し勉強すれば防げたであろうテストケースの書き方を本書籍では解説されています。
認識統一のためのドキュメント
まずはプロジェクト内でテストに向き合う際に用意しておいた方が良かったドキュメント2点
テストマップ
どの機能に、どのようにテストを行うべきであるかを定義するためのドキュメント。 プロジェクトメンバー内にテストに精通しているメンバーがいない場合、真っ先に作成した方が良いと思いました。 テスト実装前段階におけるメンバー間の認識統一に最適だと思います。
また、新規参画者のテストへの向き合い方も、このドキュメントで補えそうです。テスト観点一覧表
実装した機能をどのような観点からテストを行うべきかを定義するためのドキュメント。
このドキュメントでは、各プロジェクトが何に重きを置いているか（プロジェクトの個性）も交えながら、テストマップよりも一つ掘り下げた次元で、どのようなテスト・確認を行うべきかを記載します。
例えば、商品の在庫を管理する機能がシステムの根源としてあり、在庫商品に対するアクション（仕入、販売、確認）を行うようなシステムの場合、アクションを行った後に正しい在庫であることを確認する旨をテスト観点一覧表に盛り込んでおく。等でしょうか。
テスト工数と欠陥を見逃すリスクはトレードオフに関係にある
組み合わせテスト技法について、「オールペア法」と「直交表」が紹介されています。
9割以上の網羅率を達成できる手法だそうです。（2因子間の網羅率を数学的に組み合わせ）
大手、中堅規模のプロジェクトであれば上記2つの手法を駆使し、網羅率の高いテストケースを設計し、テストエンジニアがテストを実行（テストコードを記載する）のかもしれませんが、 数名で担当するプロジェクトではテストと工数のトレードオフ、を吟味し、限定的なテストケースを考える必要があると思います。
