先日、面白い話題がtwitter上で繰り広げられていたので載せます。
普段のこんなところから、テストエンジニアは考えを巡らせていると知ってもらえればと。
テストエンジニアの日常
「境界値分析で最小のテストケースはいくつか。」にしか見えなかった(^_^;)
— Takeshi Uemura (@takeshi01564584) 2016年2月15日
この場合は、有効同値クラスは以下で、
1、5、6、10、11、30、31、100
無効同値クラス
0、101
が最小テストケースになるのかな。 pic.twitter.com/QO2KIuEHRT
101が無効同値クラスかも怪しい。再右列が価格なら、101は期待結果が曖昧。もし同じルールが繰り返し適用されるなら、101番は100円。すると価格がさらに上がる111番はテストしたい。 RT @takeshi01564584 … pic.twitter.com/n3eJhy0gft
— YasuharuNishi (@YasuharuNishi) 2016年2月16日
- こういうドキュメントにも思考を巡らせてしまいます。*1
- 動くものだけがテストの対象ではありません。
テストをすることへの誤解
「テストをする＝開発物が出来てから初めてテストのことへ頭を巡らせる」と思われていないでしょうか。
少なくとも、周りの開発者は（社内、社外関係なく）そういう思いを持っている人が多かったです。
しかし、JSTQBのシラバスによると、テストの目的として以下の4つが書かれています。
- 欠陥を摘出する。
- 対象ソフトウェアの品質レベルが十分であることを確認する。
- 意志決定のための情報を示す。
- 欠陥の作りこみを防ぐ。
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14
この記事の最初に書いた内容は、欠陥の作りこみを防ぐことにも繋がると思っています。
「この場合はどういう挙動になるんだろう？(101辛以上はどうなるんだろう？)」という、仕様書には書かれていないことを開発者に伝えることができます。
こんな工数を減らしたい！（無くしたい！）
- 実装したけど、リリース日前日に大幅な修正が入った
- 実装したけど、出来たものは利用者のやりたいことと違っていた
- 実装前に想定できたことを考慮せずに実装してしまった
こんな工数はもったいないです。
これらを実装前に指摘するためにも、テストエンジニアがいると思ってます。
最後にちょっと宣伝
今回の話題として使った同値分割・境界値分析と同じブラックボックステストの設計技法である、ドメイン分析の勉強会が今週土曜日にあります！
興味を持った方は是非参加してみてください！*2
