[テスト自動化の落とし穴]テストシナリオ実装は2段階ある！

こんにちは。SODAでクオリティエンジニアをやっているokauchiです。
今回は、テスト自動化でのハマりポイント、ステークホルダーとのコミュニケーションでの落とし穴を紹介します！

テストシナリオ作成完了=運用開始可能？

E2Eテスト自動化の仕組みの導入が進み、作成すべきテストシナリオも抽出が出来、「よーし、ここからはひたすらにテストシナリオを作っていくぞ」というところまで進みました。ノウハウや共通処理がない中でも自分達が手動でやっていくものが自動化されていく様はなかなかに爽快です。ちょっと長めのテストシナリオを作ったら誰かに自慢したくなったり、５つぐらいテストシナリオを作ったら、この処理は共通化出来そうだと共通処理を開発したり。新しい操作が出てくれば多少詰まる所はあれど毎週のようにテストシナリオは増えていきます。ここまでは良いんですよ。

シナリオはあるのに、運用には使えない？

ステークホルダーにもデイリーやウィークリーの進捗を共有して、じゃあStep1の20項目が完成したので、運用開始しようと。そうすると気づくんですね。数回の実行に耐えられても5回、10回、それ以上の実行には耐えられない設計、実装なんだってことに。

例えば、運用を考えると以下のようなことをテストシナリオで考慮する必要があります。
・データを作成し続けて上限に引っかかることがないか
・事前条件を満たす方法が何かしら仕組み化されているか
・リトライが発生した時に事前条件が復旧されるか
・他の作業でテストデータが破壊されることがないか
・同じ検索結果が得られるキーワードを入力しているか
・環境によって検索結果に差が出ないか
・同名のデータを作成した際にバリデーションエラーにならないか
（これ以外にもありそうだけど、ここまでにします）

なかなか導入したての組織では最初からそこまで設計、実装、レビューができるわけじゃないので、運用に耐えうるテストシナリオにするというフェーズが出てきます。でもステークホルダー的にはハテナなんですよね。「だってシナリオ作成全部完了したって言ってたじゃん！あれ、ウソだったの？」「いや、ウソではないんですけど、かくかくしかじか」で通じるようなら良いんですけど、ステークホルダーの理解度によっては納得してもらえないこともありそうです。

基本実装と運用実装

この問題の背景は、運用まで意識したテストシナリオ設計が出来ていなかったということになります。とはいえ経験が浅いのであれば運用させてみないとわからないこともありますね。ただテストシナリオは作成完了していると報告してしまったし、説明がなんとも難しいですね。自分が当時のシチュエーションにまた遭遇するのであれば、自動化の実装は2段階あることを事前に説明していたのかなと思います。基本実装（最低限の1回の実行に耐えうる実装）と運用実装（何度どの環境で実行しても耐えうる実装）の2段階です。それが事前に伝わっていれば「確かに実際に運用する環境でのキャリブレーションが必要だよね・・」ということの理解も取れ、進んでいるんだか進んでいないんだかを変に疑われることもなかったんだろうなぁと。

作業を分割して名前をつけるとプロセスになる

昔、どなたかに聞いたのですが、ソフトウェアテストのプロセスでテスト設計というものが一般的でなかった時代。すべてがテストというプロセスの中でテスト設計、実装、実行までも行なっていたそうです。そこで「いや、準備もなく実行も出来ないでしょ！テスト準備のプロセスが必要だ！」と分割して名前をつけたところ、その組織ではテスト準備と呼ばれるものが一般的なプロセスとして認知されたそうです。一般的でなかろうが自分達がやっていることをすべて一括りにせず、ある程度の塊に分割し名前をつけることができると、コミュニケーションはグッと楽になりそうですね。