18.テストケース実行 その①
※Test Railの話はこのブログの下部にあります。
テストケースの内容
たまに正常系の確認しかしていないテストケースがあるから注意が必要だぞ！
仕様書をただ写すと大体そんな感じだ！
よく仕様書を聖典のごとく扱う人がいるが、仕様書は大抵例外部分が抜け落ちている。
企画は「どうすればユーザーが楽しめるか、便利に使えるか」を考えて作っている。
よって基本的には正常系が詳しく書かれることが多く、例外に関しては「出会ってから考える」がデフォルトである。
対して我々は「それについてこんな使い方をしても大丈夫か？」といった感じで、イレギュラー系の操作の着眼点が多い。
仕様書レビューからしっかりと行い「この場合はどうなるのだろう？」を企画にも伝え、テストケースにも落としていかないと……その部分がすっかり抜け落ちたプロダクトとご対面することとなる。
エクセル、スプレッドシート、テストケース昔話
プログラムを書いている人は大体エクセルにやたら詳しいと思われているんだ！
なので「いやエクセルの関数は知らない。VB？書いたことない」と言うと「ハトが豆鉄砲を食らった」ような顔されちゃうぞ。
閑話休題。
テストケースの歴史のお話です。
今は昔。
エクセルで書かれたテストケースは各自ローカルで実施、帰る前に提出。リーダーがマージ（みんなのテストケースをまとめる）作業を1時間くらいやっていた。
もちろん途中の進捗も自己申告制だった。
そこから進化し、エクセルを共有サーバーで共有しながら行っていた。
リアルタイムでは結果は出ないけど、更新すればデータは反映されていた。
が、どういうわけかデータが飛ぶ。
日常茶飯事レベルでデータを吹っ飛ばし、リーダーが泣きながら1時間くらい復旧作業をやっていた
そこからスプレッドシート。
サーバー上で行い、全員の結果がリアルタイムで現れる。この辺でようやく管理コストが減ったのであった。
テスト管理ツール
お金はかかるけど、エクセルから離脱した（したい）会社が行き着くところ。
自動的にデータをまとめてくれたりメトリクスが取れたりしてラクチン！
ただ、導入はとってもハードルが高い。
まずは社内エクセル信奉者の壁が立ちはだかるであろう……。
「そんなの見にくいじゃないか！ エクセルがあれば何でもできる！」
「今まで慣れた手法から変えると教育コストが管理コストがアレコレが……」
とりあえず猛烈に反対されるので気合いで頑張りましょう。
そのあとは上司。
「月々19万？ え、それエクセルで良くない？」
生半可な理由を持っていこうものなら、月々の利用料を払う理由が見つからず速攻でアウトだ！
テスト管理ツールに関しては以下が分かりやすくまとめられている。
Test Railの話
Test Railのメリット・デメリット
作者はTest Railでのテスト管理を行っています。
個人的に思っているTest Railのメリットとデメリットを簡単に記載しておきますね。
メリット
- テスト実行についての正確な記録（実施者、時間、ログ）
- テスト実行結果を関係各位にURLで共有ができる
- バグトラッキングシステムとの連動機能
- 作成したテストケースの再利用
- テストケース実行、探索的テスト結果を一元的に管理できる
デメリット
- テストケースを俯瞰しにくい（Excelなら一覧で見れたが、Test Railだとそれぞれの項目を開く必要がある）
- 上記によりレビューがしにくい
- テストケースの中規模以上の改修が行いにくい。（俯瞰しにくいことに由来）
- テストケースがたまってきた時にまとめにくい。（ベースラインという仕組みがあるが、より細かくまとめたいときなどもある）
＊＊＊
何よりも、貯まったエクセルのファイル管理をしなくてもよくなったことが導入してよかったと思えるポイントのひとつでした。
後は探索的テストのログ（作者はセッションベースの探索的テストを多用しますが、それはまた今後のテスターちゃんの話でｗ）がテストケースと一緒に管理できるのもよいです。
あとは説明責任が楽になりました。
こういうテストを行いました、と結果のURLを張り付けるだけです。
（前までメールにエクセルを添付して送っていたけど、結局見てもらえなかったり）
あとは、全体のテストケースを作っておいて、各イテレーションで実装される機能だけをそこから抜き出して、そのイテレーションのテストにしたり。
スモークテストをしたいときはテストケースの優先度が高いものだけを抜いてテストを作ったり。
エクセルで切り貼りしていたものが簡単にできるようになった、といったところです。
デメリットももちろんあります。
一番思っているのが「テストケース全体を俯瞰しにくい」です。
エクセルだったときは上から下にずらーっと目を通せば、ステップ、期待結果まで見ることができました。
Test Railだと、項目を開かなければステップと期待結果が見られません（設定があったりするのかな…？）
そうなってくると大変なのがレビュー。
一つ一つ開く必要があったり、流れが読み取りにくかったりすることが多々あります。
あと意外に大変なのが、テストの中規模程度の修正です。
他の項目を開かないと分からなかったりして、項目数が多いテストケースだと「あれ、これあったっけ……」と探すのが大変だったり重複したり。
この辺は「インポート機能」で近頃は修正していますが、そうすると管理が2か所になるというデメリットも。
できるだけそういったことを防ぐために「TitleにStepsと同じ内容を入れる」という回避策を私はとっていますｗ
