書くのが遅くなったけど、先週行ってきたテスト勉強会の感想を。
今回の勉強会はCFD(Cause Flow Diagram)法について。
CFD法はこんな図。
作成手順
- 仕様書から原因と結果を見つける。原因は□、結果は○で記載する。
- 同じ種類の原因はまとめて、□の中に□を入れるような形で記載する。（図参照）
- まず結果を先に書く。それぞれの結果から逆に線を引く。
- 図を書いたら、その図の内容からデシジョンテーブルを作成する。
一つ目の条件で結果が決まる場合、二つ目の条件は通さない(箱の外側に線を引く)。
上記図だと、ユーザIDが不一致だったら、パスワードの条件に関わらずログインNGになるので、ユーザID不一致であれば、パスワードの箱の外側に線を引いて、ログインNGにつなげる。
デシジョンテーブルも同じ条件で記載する。（ユーザIDがNであれば、パスワード条件は-とする)
感想
結果から書くのが意外に難しかった。
普段の仕事でテスト項目考えるときは、原因→結果の順で書いてたんで、結果から書くのはあまりやったことなかった。これはケースバイケースな気もするけど。
あと、紙の右側に結果を書いてから、原因を左側に書くのが順番として書きづらい。原因を書き込むスペースをどれだけ空けたらいいか分からないので。
とは言っても、紙とペンさえあれば簡単に書けるので、その点はメリットかなと思った。
今回の技法の使いどころは、テスト項目の抽出というより、仕様や処理順序の整理目的で使った方が良いかな、と思った。処理順序を実装前に整理しておけば実装が無駄に複雑になることを防げそうだし、処理フローの代わりと考えても、図が単純なので変なフローより書きやすい。条件やデータの集合を意識させる効果があるのもポイントかと。
テスト項目の抽出方法としては微妙な気がする。特に自分以外の人間が実装したプログラムのテストの場合は。出来上がるデシジョンテーブルは処理順に依存したものになるけど、想定した処理順通りに実装されているとは限らないだろうし。
自分が実装した箇所のテストなら使えるかな？
最後に告知をば。
10/12(土)に、TDDBC 仙台 the 3rdという、テスト駆動開発のイベントが仙台であります。まだ席に空きがあるようなので、興味がある方はどうぞ～。
