mablのAuto-healing Testsはテストを自動修復する機能です。これによって、たとえばボタンの配置が変わったり、要素のIDが違うけど同じ要素に見えるときに、mablは「よしなに」自動修復してくれます。
Auto-healing Tests
自動修復はInsightから確認できます。Insightを開くと自動修復した画面や画面の情報を確認可能です。
自動修復の仕組みは簡単。特定の要素の情報を「可能な限りたくさん」取得しておき、それらの差分を考慮して自動修復を行います。たとえば、要素を特定する方法はたくさんあります。 タグ名、Xpath、Class、Hrefといった属性値・・・。mablはこれらの情報を記憶し、自動修復に活用しています。
自動修復によって、新しくタブを開いたときや、画面を表示するたびにIDが変わったりするケースでも自動修復によってテストのメンテナンスコストが削減できます。
例外として、要素の特定にXpathを使っている場合は、自動修復しません。これは、意図的にXpathを指定していると考え、その意思の邪魔をしないためのようです。
自動修復によってどんどんテストは自動修復されます。もし、過去の要素情報に戻したい場合はロールバックできます。
最後に、mablメンバーと話していて気がついたことがあります。日本の顧客にこの自動修復をアピールすると、よくこう聞かれるそうです。
自動修復。それは困る。ちゃんと修復が正しいか確認したい。
これを聞いてこんなふうに言っていました。
自動修復によって面倒なメンテナンス作業を減らしたのに、なんでそんな確認をしたいんだろう？
「たぶん、みんな心配なんだよ」と答えておきましたが、こういう感覚がテスト自動化の壁になりがち。そんなの気にしてたらいつまでたっても手作業ですからね。
ただ、僕は現段階の自動修復機能は不十分です。なぜなら、現段階の自動修復機能は、Insightによって自動修復を通知するだけでしかありません。できれば、知らせるだけではなく、学習してほしくないですか？
彼らにもフィードバックしたのですが、
- 自動修復する
- その判断を人間が「No」としたときに、何が「No」なのかをmablは学習する（「Yes」の場合も学習できそう）
- どんどん学習して自動修復の幅をどんどん広げていく
こうなれば、より人間が考えなくてよくなり、メンテナンスコストも下がっていくはずです。最後は実行失敗の判断までmablにゆだねてしまい、テストを作るだけでよくなり、テストすらも自動で作ってくれるようになれば・・・
遠い未来かもしれませんが、近い将来かもしれません。
旅と子育てとアジャイルコーチのブログ「世界」 