テスト自動化の向き・不向き

大まかにテストの種類を紹介しましたが、テストにもいろいろな種類があるのを理解していただけたかと思います。それらの中で自動化に向いているテストの特徴は、以下の通りです。

・繰り返し行う
・検証項目が多い
・手順が決まっている

先ほど紹介したテストの中で挙げるなら、「リグレッションテスト」（回帰テスト）が当てはまります。仮にそういったテストを手動で行おうとすると、アジャイル開発ならスプリントごとに膨大な手間と時間が必要になってしまいます。

開発サイクルを速く回したいのにテストがボトルネックになって進まないという課題が浮き彫りになったことで、「スピードと品質を両立させるためには自動テストが不可欠」という考え方が広まりました。その流れにテスト自動化ツールである「MagicPod」が少なからず貢献できていることは、とても喜ばしく思います。

一方、自動化に向いていないのは先ほどの特徴と逆の特徴を持つテストです。例えば「使う機会が少ないテスト」「変更が多いテスト」などが挙げられます。

「使う機会が少ないテスト」を自動化した場合は設計する労力、「変更が多いテスト」を自動化した場合は修正する労力がかかり、手動よりも高コストになってしまうかもしれません。

また、テストの中には、サイトやプロダクトの使い心地をユーザー視点で確かめる「ユーザビリティテスト」といった“人が実施するからこそ効力を発揮できるテスト”もあります。

近年注目されているAIの活躍にも期待したいところですが「想定していないバグを事前に察知するゴッドハンドのような人」の代わりができる日は、まだまだ先のことでしょう。

ちなみに、私が参加していた「テスト自動化研究会」というコミュニティでは以下のような「テスト自動化の8原則」というものを公開しているので、参考までに紹介しておきます。

1. 手動テストはなくならない
2. 手動でおこなって効果のないテストを自動化しても無駄である
3. 自動テストは書いたことしかテストしない
4. テスト自動化の効用はコスト削減だけではない
5. 自動テストシステムの開発は継続的におこなうものである
6. 自動化検討はプロジェクト初期から
7. 自動テストで新種のバグが見つかることは稀である
8. テスト結果分析という新たなタスクが生まれる

※参照︰テスト自動化研究会

自動テストのコード作成は“誰もやりたがらない領域”だった

私が専門的にソフトウェアテストと関わるようになったのは、10年ほど前です。

当時から「プログラムを書かずにブラウザ操作を記録し、自動で繰り返すようなツール」はありましたが、どうにもかゆいところに手が届かず、「何だかんだ言っても人間がテスト用のコードを書くのが正しい」という考えが主流でした。

ただ、自動テストのコードはちょっとしたデザインの変化や実行環境の違いで動かなくなってしまうことが多く、メンテナンスがしづらいという傾向があります。

そのため、普通のテスト担当者からするとコードを書くのが大変、開発者からするととにかく面倒で楽しくない、“誰もやりたがらない領域”という印象でした。

テスト自動化ツール「MagicPod」の開発

前職ではいろいろな会社で自動テストの導入コンサルをさせてもらいました。

どれも貴重な経験でしたが、だんだんと「田植えばかり繰り返している」ような気がしてきて、「農耕器具のように作業が楽になって、生産性も上がるテスト自動化ツールをつくりたい」と思うようになりました。

そんなときに代表の伊藤から「こういうものをつくろうと思っている」とMagicPodの構想を教えてもらったのですが、正直「先にやられた！」と思いました。

しかし、実際にMagicPodの開発が始まって「一緒にやりませんか」とお誘いをいただいた際は、私なんか見向きもされないと思っていたので「誘ってくれるんだ。ラッキー！」と思いました（笑）。

あれから4年ほど経って、自分がつくれると思っていた以上のところまできている気がします。ノーコードでテストを自動化できるということは重要ですが、そのせいで開発のエンジニアにとって使いにくくなってしまっては本末転倒だというのが、MagicPodに触れるまでの懸念でした。

昔から“コードを書くか、自動記録するか”という対立があり、「自動記録すると簡単に自動化できるけどメンテナンスしにくい」「コードを書くと最初は難しくてもメンテナンスしやすい」という、それぞれにメリット・デメリットがありました。

MagicPodは双方のいいとこ取りをしたイメージです。

※YouTubeでMagicPodの紹介動画を公開しています。ご覧いただけると嬉しいです。