先日、結合試験用に作成を続けていたテストシナリオが完成した。その前に作成の終っていた各画面単位のテスト仕様書とDBダンプ作成のための画面単位のDB確認書をもとに結合テストを実施してもらう手はずであった。つまり結合テストを実施するうえでの仕様書は以下のようにまとまっている。
- 結合テスト用シナリオ
- 各画面単位のテスト仕様書
- DB確認書
ボリュームとしてはこんなもんだろう、という印象。不明な点は詳細設計書やテーブル定義書を確認してもらえばよい。
今更遅いのだけど、もっとシナリオを作成する段階で画面単位に作られたテスト仕様書をよく確認しておけばよかった。というのも、いざ結合テストが始めってみてわかったのだけどとにかくテスト仕様書に不備がめっちゃ多いのだ。
ボタン名称が違うくらいならまだかわいいが
- 確認項目として挙がっている項目が「そもそも存在しない」
- 画面遷移の手順が誤っているので、テスト実施手順通りに進まない
- あり得ないデータを入力値として定義している
- テスト実施手順が誤っているので、確認項目と一致しない
主にこの4点がまんべんなく各テスト仕様書に書かれているため、都度、「実施できないのですが・・・」とテストチームからアラートが上がってくる。そのたびに結合テストの確認者として存在している私がそのテスト結果および実施内容の妥当性をチェックしている。
「このテストは実施不可能なので飛ばしてください」「この手順は誤りなので、このように実施しなおしてください」「このデータだと入らない?仕様書が間違っているのか確認しますね」「すいません、誤記なのでテスト仕様書を修正します」「すいません、すいません...」
最近毎日こんな感じでちょっと死にそうだ。
シナリオ作成時にテスト仕様書の中身についてきちんと確認していなかった自分にも非はあると思う。なぜ、他人が作ったテスト仕様書が完全に正しいことしか書かれていないと思い込んでしまったのか。なぜ自分が作ったテスト仕様書に不備がないと自信満々だったのだろうか。レビューも一切されていないテスト仕様書になぜ誤りがあると1mmも思わなかったのだろうか。
今後もしテストシナリオを作成するようなときがあるならば、テスト仕様書にもきちんと目を通してしっかりしたシナリオを作成したいと思う。まさかテストチームの面々もレビューの一切通っていないテスト仕様をもとにテストをすることになっているとは思わないだろう。本当に申し訳ない気持ちでいっぱいだ。
ここまでテスト仕様書の不備に始まる、テストチームへの申し訳なさ。あとは、プログラムバグや設計バグに始まる各種バグが色々と出てきていて、プログラム的な部分にノータッチである自分にはなにもわからないので不安。
テストを消化することでバグが検出されて、いずれ収束に向かうというのがよくあるものだと思うけども、「基本設計から見直した方がいいかもしれません」とかいう文言がRedmineに上がっていたのでちょっと心配である。基本設計・・・?
今たくさんテスト結果のエビデンス(画面のハードコピーとDBのダンプ)を取ってもらっているが、おそらく、たぶんほぼテスト結果のレビューはしないんだろうね。しないよね。テスト項目の消化だけを見てるんだよね。
本当に大丈夫かな。これが終わったら総合テストが始まるんですけど・・・。
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)
- 作者: 渡辺修司
- 出版社/メーカー: 技術評論社
- 発売日: 2012/11/21
- メディア: 単行本(ソフトカバー)
- 購入: 14人 クリック: 273回
- この商品を含むブログ (69件) を見る
Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで
- 作者: 谷本心,阪本雄一郎,岡田拓也,秋葉誠,村田賢一郎,アクロクエストテクノロジー株式会社
- 出版社/メーカー: 技術評論社
- 発売日: 2017/04/18
- メディア: 大型本
- この商品を含むブログを見る
実践Javaコーディング作法 プロが知るべき、112の規約と21の心得
- 作者: 森崎雅稔
- 出版社/メーカー: 日経BP社
- 発売日: 2014/12/19
- メディア: 単行本
- この商品を含むブログ (1件) を見る