この記事は 弁護士ドットコム Advent Calendar 2019 の24日目の記事です。
TL;DR
導入して
習慣化するまで
ワンセット
はじめに
みなさん、テストしていますか？
クラウドサインではこのたび mabl という e2e (end to end) テスト SaaS を導入しました。
本記事では、 mabl 導入〜習慣化までやったことについてご紹介します。
背景
どんなサービスであれ致命的なバグを出すわけにはいきません。
そのためにもテストは必要不可欠です。
Unit テストや Integration テストは行っているのですが、どうしても e2e の部分がネックとなっているのが現状でした。常に変わる画面、逐次リリースされる機能、IE11 、その度に発生するリグレッションテスト、IE11 、マルチプラウザ対応、 IE11…
やらねばなりませんが、体力を結構消耗してしまってました。
このしがらみから開放されるべく、e2e テストツールの導入を検討していたところ、「mabl がいいぞ」という声があったので軽い気持ちで mabl を試してみました。
mabl
軽い気持ちでトライアルを始めてみましたが、なかなかどうしてかゆいところに手が届く感じでした。
- 画面操作のみで e2e テスト定義ができる
mabl Trainer という chrome extension を使い、画面操作のみでテストを記述することができます。
言ってしまえば mabl の使い方さえわかれば誰でもテストを書ける 状態に持っていくことができます。 - IE11 に対応している
プロダクトの特性として、 IE11 にも対応する必要があったので重要視していたポイントです。
これもでかいです…何度 IE11 に泣かされたことか… - 導入実績がある
背景にも書きましたが、実際に導入している会社から紹介され、
実際にトライアルを行ったところ、聞いたとおり良かったのもポイントです。
上記を始めとした諸々のメリットがあり、導入に踏み切りました。
導入してやりきった気になっていましたが、
実のところ、ここからが導入プロジェクトの始まりだったのです。
習慣づける、ということ
実は mabl 導入以前から e2e テストに対する取り組みは行っていました。
Cypress や BrowserStack + Selenium など取り組んできました。しかしそのどちらのテストもコードを記述する必要があり、エンジニアの稼働が上がってしまうとどうしてもテストコードのメンテナンスが疎かになり陳腐化してしまったという末路を辿ってしまいました。エンジニアの怠慢なのでは？ と言われたら申し開きようがありません。
いずれも、習慣化しなかった ことによって陳腐化してしまったのは言うまでもありません（反省）。
同じ轍を踏まないためにも、導入後の対応も必要でした。
習慣化しない理由
Unit テストや Integration テストはみんなできているのに、e2e テストだけなぜ習慣化しなかったのか。
私はその理由を探るためアマゾンの奥地へと足を踏み入れました。
私見ではありますが、以下に起因するかと思います。
習慣化する「もの」が難しすぎる
どう使えばわからない、習得するまでコストがかかってしまう、というものです。
専任チームがあれば乗り越えることができるとは思います。ただ、専任チームがいない状態で本来持っているタスクと一緒にやりきるというのは難易度がさらに上がる、または習得まで長い期間を要してしまう（その間に別な方法が出てきたりとか…）、という状況になりがちです。
結果、使いづらい→使いたくないのコンボが発生し、陳腐化します。
情報が閉じてしまう
知っている人だけで情報が共有されてしまい、開発メンバーのキャッチアップできる情報が減ってしまう状態です。情報が閉じてしまうことによって、知らないメンバーが作業をやるにしても腰が重くなってしまいますし、作業自体が難しいと見なされてしまうようになります。
そして段々と情報を持っている人しかやらなくなってしまい、属人化を招きます。
細々と続けることはできるかもしれませんが、担当者がいなくなってしまったとき、いよいよ手がつけられなくなります。
方針がわからない
使い方はわかるけど何をどうすれば、の「 How 」の部分の共有不足です。方針がないと着手しづらくなり、作業を忌避したくなります。結果として先述したものと同じように属人化の結末を辿ってしまいます。
習慣化させるために
そのためにどのような対策をとったか。
その対策を探るためにアマゾンの奥地へと足を踏み入れました。
一部仕掛中のものもありますが、以下の対策をしています。
習慣化する「もの」が難しすぎる、の対策
mabl がデザイナーやディレクターといった非エンジニアでも操作可能なサービスなので、テストの作成はそこまで難しくないと考えられます。実際にディレクターの方がテストを作成し、開発の現場でそのテストを活用しています。
テストの実行については、mabl をそのまま使うのもありましたが、より親しみやすい slack と連携し ChatOps 化することでハードルを下げました。mabl で作成したテストにはラベルをつけることができ、そのラベルをまとめて実行するような形にしました。
こんな感じで、slack から A 機能にまつわるテストを全実行できるようにしています。
情報が閉じてしまう、の対策
情報をオープンにするため、 mabl ハンズオンを行いました。
エンジニアだけではなく、開発メンバー全員 （エンジニア、デザイナー、ディレクター、PO 、SM) に対して行いました。ここでも mabl の操作のしやすさが生きてきました。
実際ハンズオンの中で開発メンバー全員がテストを記述することができ、開発メンバー全員が e2e テストを書ける土壌ができたかなと考えています（引き続き情報発信は続ける必要はありますが…）。
また、事業部だけではなく、全社のエンジニアにも共有を図っています。
方針がわからない、の対策
「 e2e テスト書いて」ではなく、「この操作のこういうところだけを作ってほしい」という伝え方をすれば mabl の利用ハードルが下がるかな、と考えております。
そのためにも e2e テスト方針を固めること、チケット化して開発メンバーが拾いやすいようにすること、を進めているところです。
今どうなの？
上記で書いたとおり、まだ道半ばです。
ただ、コード修正→確認用の環境に上げる→ slackbot でテストで確認というのが自分の手元だけで実現できるので 満足度はとても高い と思います。実際感動します。
将来的には「この操作抜けてたから mabl でテスト作っておいたわ〜」ですとか「じゃあ俺コード書くんでテスト書いて〜」「いいよ〜」といったように 開発メンバー全員で e2e テストをかける 環境に持っていきたいですね。持っていきます。
まとめ
- mabl はいいぞ
- 導入までで燃え尽きそうになった
- 習慣化してまでで導入完了だよ
- 今後も継続してやっていき
