はじめに
これまでに様々なテストの自動化を実施してきました。その中で自分が遭遇した、とある「あるある話」をご紹介したいと思います。
RPA を入れたがコーディングがベストと気づく
テストを自動化したい！そうした時に真っ先にハードルになるのがコーディングです。 Python など様々なスクリプトがありますが、コーディングスキルに自信がない。そうしたとき、RPA に代表されるローコード、ノーコードソリューションは魅力的です。
RPA による自動化は、使いこなせるととても便利ですが、使えるようになるまでのハードルが意外と高かったりします。いざ機能を使おうと思ったら追加のライセンスが必要だったり、また使い始めると欲しい機能がなかったりなど。
また複雑なテストをしようとすると RPA 内で結局コードコードを書く必要がでてきたりします。それが独自言語の場合学習コストが高く、いろいろと検討した結果やはり Python などのスクリプトが良いという結論になるあるあるがありました。
コーディングに没頭し脇道にそれる
RPA がダメならスクリプトということで、コーディングを始めると楽しくなってきて、いろいろなことをしたくなってきます。すると本来の目的である自動化を忘れてスクリプトそのものに没頭するパターンがあります。
例えば自動化した結果をログに書き出す際、自分の好みのフォーマットで書き出すような関数を作ったとします。するとそれを一般化してみようとクラスにしたり、他の関数で使おうとデコレーターにしたりなどなど。
またはすでに用意されているモジュールが気に入らず、自分独自実装のモジュールを作ったり、rich などを使って妙に表示にこだわってみたり。そうこうしているうちに自動化が大幅に遅れるというあるあるがありました。
そして完成した自動化が解読不能で結局使われず
そうこうしているうちに、本来の自動化を思い出し、凝りに凝ったコードで自動化を完成させます。するとあまりにもコードが凝り過ぎていて難解なコードとなります。
自分では芸術作品を作ったような気持ちになりますが、他の方からするともっとシンプルに書けば良いものをと思われたりします。そしてカスタマイズが難しくなり自分が担当から外れた途端に使われなくなる、というあるあるがありました。
終わりに
こうした経験から、テスト自動化ではシンプルなツール、柔軟性のあるツール、属人性を排除できるツールがとても重要だと思っています。T-DASH はこれまでに何度か試用したことがありますが、GUI ベースの日本語ローコードソリューションのため、こうした懸念が少ないソリューションだと思っています。今後 T-DASH のようなソリューションがさらに普及すると良いなと思います。