最近、スクラムチームの中でテストをする機会があり、テスト要件を挙げて、ハイレベルのテストケースを挙げて、あとは探索的にテストをするという流れを何度か経験しました。自分にとってやりやすいこととか、流れがよくないというかつながっていないところがあることに気づく、よい機会になりました。
気づきとして、テスト要件を挙げることと、いわゆる観点に該当するものを挙げることはできるのですが、それがどう関連するのか、というところがうまく見せられないことがわかりました。だから、「これで十分なのかがわからない」と言われることが多かったです。。。テスト要件だとざっくりしすぎで、テスト要件に対して観点を見せるのはなかなか難しいなぁと。。。(テスト要件単位で観点並べるのをさぼったからっていうのはわかっているんですけれど、並べたところでテストケースがイメージできる状態にならないとか。。。)
それとは別に、そういえば、テスコンチュートリアルで紹介されている「テストフレーム」をつくる演習ってあまり聞かないなぁと思い、じゃぁテストフレームを作る演習を考えるといいのかもーと考えまして・・・まずは自分で明示的にテストフレームをつくってみるかぁ・・・と思ったのでした。
テストフレーム：テストケースの構造をテスト観点で表したもの
(チュートリアル資料47ページ参照)
http://aster.or.jp/business/contest/doc/2020_OPEN_V1.0.0.pdf
やってみた結果、どうもテストフレームはテスト要件をまとめる過程でつくり、テスト要件単位で詳細に落とし込んでいくのがよさそう、という見解になりました。
テストフレームを形成する観点を用意する必要があるので、観点の列挙も含めると、こんなプロセスになるなぁと・・・
試しに、一般的なLogin処理を想定してテストフレームをつくってみました。
これをテスト要件ごとに展開してみました
入力値に対してログイン可否を判定して判定結果を出す、というところをテストしたいときは、こうなるかな？と思いました。
一方、いろんな条件でログインに成功することを確認したいとき(組み合わせテストを想定している場合)は、↓のように変わってくるなぁと思いました。
更に、エラーになる条件に対してエラーメッセージを表示することを確認したいのであれば、どこにエラーの条件があるかを洗い出して展開されます。この場合はServerの状態やNetworkの状態に注目がいくはず。
そして、テストアイテムを適切に設定する必要があることもわかってきました。テストアイテムの抽象度が高いと、テスト要件に落とし込んだときに必要ない(単一条件でも必要がない)観点が存在してしまう。そうなったらテストアイテムが適切ではないと疑ったほうがよさそうだな、と思いました。例えば画面単位でテストアイテムを設定すると、パーツが混ざっていることでごちゃごちゃしたテストフレームが出来上がってしまいます。他には、UIの処理とシステムの処理は分けたほうがよい、など。
自分の頭の中で処理していることって相当あるんだなぁというのが正直な感想です。
これを都度やるのは面倒臭いなぁ・・・でもツールを活用することで面倒臭さは解消されるかもしれないなぁ・・・と思うので、ツールを使ってうまくできないか試していこうと思います。
