Taste mabl which provides ML-driven test automation service

Lately, ML related technologies step into industry section and many engineers challenge to integrate them into their services.

The movement also comes into test/quality industry. I also have some ideas to use them though.

A few weeks ago, I found a service which named mabl which provides ML-driven test automation service. The service run tests using ML technologies, not test ML technologies itself. I try the service recently and put some results and thought here.

URL: https://www.mabl.com

The target URL is simple, https://www.google.co.jp

I don’t do anything except for input the URL into a particular area. Then the journey started and I just wait for a while.

The site looks crawling the target site and checking all links. The followings are the results. I can see some error message which may be broken links.

Screen Shot 2018-02-27 at 10.22.02

Screen Shot 2018-02-27 at 9.34.37

In test section, we can see some test cases and its results. Their test cases are generated automatically. According to the titles and some logs, the test aims to collect available transitions, it means available links and some data.

Screen Shot 2018-02-27 at 10.21

We also can see train section. I guess the section is a teacher in ML world. So, we running test iteratively, then the ML logic learns the test target and they will be able to conduct automated test efficiently.

Screen Shot 2018-02-27 at 10.22

Screen Shot 2018-02-27 at 10.23

I believe if we run test iteratively and collect test data, cases and results, the ML will be more inteligent and they can run test automatically effective.

Anyway, it looks promising and I’d love to try my thought using ML technologises.

Advertisements

[ML]Backtesting and Cross-validation

This article is a memo to me reading https://eng.uber.com/omphalos/

This article is a backtesting tool which used in Uber to validate ML related thing.
I’m not sure some words and I’d like to memorise them in my brain. Thus, I’ve published this article.

Backtesting is a term used in oceanography, meteorology and the financial industry to refer to testing a predictive model using existing historic data. Backtesting is a kind of retrodiction, and a special type of cross-validation applied to time series data.

I haven’t known the word even I’m in Test/Quality world…
Similar concept is applied in our Kage, which is

a model validation technique for assessing how the results of a statistical analysis will generalize to an independent data set.

Have a good testing!

Appiumのテスト失敗時の修正をちょっとわかりやすくする

こんばんは。Selenium/Appium Advent Calendar 2017の15日目の記事です。

多くのエンジニアの方々は、テスト失敗時の問題修正に時間を使っていることかと思います。それはテストコードの問題なのか、製品コードの問題なのか、はたまた別な問題なのか。

そのため、例えばテスト失敗時のエラー情報から、再度テストを実行することなく、どのように修正すれば治るのか、どうなおせば良いのかを教えてくれるとその時間を減らすことができますね。(これに似た話は色々と目にしますね)

今回は、Appiumを使った時の、そんな修正を便利にするちょっとしたアプリを共有します。

リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer

テスト失敗時に取得する情報は何を取得する?

多くの場合、Appiumのようなツールを使う人はテスト失敗時にテスト対象のスクリーンショットを取得するかと思います。また、人によっては動画を取得する場合もあるでしょう。Appiumに限らず、GUIが関係する場合は特に、そのような情報を失敗時の情報として取得するでしょう。

では、テストを修正する人はその情報を見ただけでどのように修正すればテストがOKになるか判断することができますか?

表示されている文字だけを見ているのであれば修正できる可能性はあるでしょう。ただ、例えばAndroidだと resource-id 、iOSだと accessibility identifier を使うことが普通になっている場合は、スクリーンショットを取得したとしても該当しそうな箇所をその表示のみから追うのはキツいのではないでしょうか。ソースコードを確認し、再度繰り返し実行し、調整していくことも多いのではないでしょうか。

とても時間が勿体無いですね。 どこが失敗 し、 どう修正すべきか を教えてくれるテスト結果であれば、この時間は短縮でき、楽に問題を修正することができるでしょう。

Sourceも取得する

どこが失敗 し、 どう修正すべきか を知る手段として、テスト失敗時の情報として page_source の情報は1つの役立ち情報でしょう。例えば以下な感じのXMLです。

<AppiumAUT>
  <XCUIElementTypeApplication type="XCUIElementTypeApplication" name="UICatalog" label="UICatalog" enabled="true" visible="true" x="0" y="0" width="375" height="667">
    <XCUIElementTypeOther type="XCUIElementTypeOther" enabled="true" visible="false" x="0" y="0" width="375" height="667">
    ...
    ...
    </XCUIElementTypeWindow>
  </XCUIElementTypeApplication>
</AppiumAUT>

GoogleのEspressoやEarlGreyはテスト失敗時にそのように画面のヒエラルキー情報を出力してくれますね。そのおかげで、修正者は要素がそもそもないのか、ある場合はどのような情報を付与するとそれを特定できるのか、はたまた別な要素である必要があるのかを判断することができます。(XCUITest自体は残念ながら取得できないです(できなかったですよね…?))

スクリーンショット x source

sourceだけの場合、そのXML情報を想像できなければ結局は表示内容を確認することになるでしょう。

そこで役立つのがスクリーンショット。ただ、sourceとスクリーンショットを自分の目で照らし合わせることはそれはそれで慣れが必要です。

そんな時、例えばAppium-Desktopのようなツールを利用できたらどうでしょう? 視覚的にスクリーンショットから該当するsourceの要素を確認できる ようになり、だいぶ問題を見つけることが楽になるのではないでしょうか。

オフライン x スクシーンショット x source

便利だろうということで作って見ました。Appium Desktopを参考に、オフラインで使える形にしてみました。

sourceのXMLを読み込み、任意の要素をクリックすると、該当する要素がハイライトされます。逆に、スクショの任意の要素をクリックすると、該当するsourceのXML要素がハイライトされます。

sample

再度、リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer

これを用いると、

例えばAndroidだと resource-id 、iOSだと accessibility identifier を使うことが普通になっている場合は、スクリーンショットを取得したとしても該当しそうな箇所をその表示のみから追うのはキツいのではないでしょうか。ソースコードを確認し、再度繰り返し実行し、調整していくことも多いのではないでしょうか。

に対して、失敗した情報からどのように修正すれば良いのかという内容を、より楽に見つけることができるでしょう。要素を特定する為にAppiumが必要とする情報がだいたい見られる為です。XPathのコピペは確か実装していないですが、XPathは不安定なこともあるので個人的には問題になってはいません。

使い方はREADMEに書いているのですが、 releaseからバイナリを取得して、macOSの Application ディレクトリに .app を移動し、アプリを実行してください。そこに、スクリーンショットへのパスと、sourceへのパスを指定、画面をreloadすると使うことができます。

著者の環境がMacなのでmacOSしか試していません。。。が、一応はElectron製なのでWindowsやLinux系列でも動くものをビルドすることはできるでしょう。(どなたか…)

最後に

というわけで、テストの失敗は、どう修正すればそれが治るのかということも知ることができるととても嬉しいです。その為に、ちょっとした便利アプリを必要なところだけ抜き出して作って見ました。

[Erlang][Software Test]Property-based testing/QuickCheck Testing

I often see Property-based testing recently, and the following article is useful to understand what property-based testing and quick check testing is I’ve read for a few years.

PropEr Testing
http://propertesting.com/

I use QuickCheck testing in my work, and it works fine against functions especially stateless ones.

Classification Treeの歴史

知らなかったので、メモ

[iOS]What’s new Testingを見た

What’s new Testingを見た。

https://developer.apple.com/videos/play/wwdc2017/409/

見ている途中でいくつかメモしたので、その記録として…


  • multiple appのテスト、URLを引数で与えることできるのね

20170612035154_img20170612-17-2kk0z7_480

  • Accessibility Dataのところで説明しているsnapshot、WebDriverAgentが使っているやつぽいな
  • おー。いちいちsnapshot取得する必要がなくなるのか。実行時間改善しそう

20170612035308_img20170612-16-1ng7xs0_720

20170612035501_img20170612-14-zvr8i3_720

  • 要素の検索で全捜査でなくて最初にマッチしたものだけさっと返すようにした、という話だけれど、ようやくという感じ。

20170612035637_img20170612-14-nebl01_480

  • ここら辺は元からそうなのでそうよねという感じだ。
  • ここはどこまで厳密に書くかはどれだけ内部実装と結合を強くするかの問題ですね。Espressoでも同じ問題をもつ。

20170612040244_img20170612-19-18xc35w_720

  • 地味に嬉しい

  • Activity styleの書き方、Cucmberとかイメージすると良さそう。stepsにいろんな処理を入れて、シナリオはstepsを並べて記述するような感じが使い方として近そうだ。

  • 非同期の奴も良さそう。XCTestなので、XCUITestでも使えるし。
  • snapshotのところはほんといろんな3rd partyも恩恵受けるだろうし、良いことづくしな気がする。けれど、これはXcode8でないと使えないOSテストするときは恩恵受けられないので、完全に恩恵を教授できるのは数年後かな…

Xcode9のいくつかの機能、Xcode9以前でも使えると恩恵大きくて良いな…

Watch “Test-Driven Development on Android with the Android Testing Support Library”

pick and past some key images to the following.

  • A famous test pyramid

20170519024718_img20170519-17-x25i39_720

  • Development Lifecycle for UI Component

20170519025016_img20170519-11-107pbac_720

  • Development Lifecycle for non-UI, especially unit level, Component

20170519025038_img20170519-17-1lny2qd_480

  • Robolectric

20170519030006_img20170519-14-1lgebza_720

  • Espresso’s lifecycle

20170519031440_img20170519-17-wz5rvd_480

  • Boundaries between M level and L level

20170519031901_img20170519-17-hireh1_720

Previously, I’ve published blog for test strategy for mobile.
This video is similar to the article 🙂

[design]inclusive design(My 4th day)

This post is memos for 30 days of accessibility testing.

https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing

4th day’s mission is researching inclusive design. So, I attach some articles in this post.