mablはmablでmablをテストする〜 QA自動化プラットフォームが実現するDevTestOps #mabljapan

先週、QA自動化プラットフォーム「mabl」のイベントに参加・発表させていただきました。後円があって3日間いろいろお話を伺うことができ、自分自身発見が多かったので、ここにまとめておこうとおもいます。テーマは「QA自動化プラットフォームが実現するDevTestOps」です。

DevTestOpsとは何か

DevTestOpsとは何かは誰かが決めればいいと思いますが、この言葉の意味あいとして、よく紹介させてもらっているDan Ashbyさんのこの図がぴったりだと思います。

簡単に言うと、アジャイル開発やDevOpsのためには、もうずっとテストするしかなくなってしまったということ。

「じゃーいったいどうすんの？」という点がぜんぜん前に進まなかったけれど、ここ数年になって、具体的な答えを試行錯誤しているのが、最近活発なテスト自動化業界のように感じています。

そしてより具体的な解を見せてくれたのが mabl や Autify のようなサービスなのではないでしょうか？

そんな彼らの話が面白くないはずありません。

考えれば当たり前なのですが、mablは自分自身のサービスをmablでテストしています。秋に STARWESTに行きたいなと思っているので、詳しくはそのときに見せてもらうと思っていますが（ボストンのオフィスも見てこよう）、50に満たないシナリオしかないそうです。

CEOのIzzyさんはエンジニア出身。考え方がとてもロジカルな彼と日本のソフトウェアテスト業界について意見交換したときに感じたのは

という点。

これはソフトウェア検証フォーラムでの発表資料『輝く未来を抱きしめて。アジャイル・DevOps時代の品質組織づくり』のときにも感じていたことですが、マニュアルテストを完璧に自動テストにするという行為そのものがムダなのではないかということ。

人間の行為を完璧に自動化するのは手間がかかるし、マニュアルテストでは自動化ならではのメリット（APIを使った時間短縮、並列化など）が活かせません。

でも、日本の顧客（少なくとも僕の周り）は、そこを気にしちゃって「実現性はどうか」とか「どこまで自動化できるのか」ばかり心配してしまうようです。

どれだけ人間に似せるか？テスト自動化でしたいことってそれでしたっけ？

また、たくさんあるマニュアルテストをどんどん自動化するとか、これまでのようにSpreadsheetやExcelにまとめたテストケースを自動化に落とし込むとか、はじめからたくさん大きく作ろうとするのも間違いかもしれない。

「はじめからたくさん大きく作ろう」って、アジャイル開発の思想にもマッチしないですよね。だからこそ mablのイベント内で各社が事例として共有されていたように

のがQA自動化プラットフォーム利用のベストプラクティスと言えるのでしょう。

それ以外だと、CXマネージャのReedさんから教えてもらった以下が役立つかもしれません。

特に「本番で実行する」は、いろいろ壁があるかもしれないけど、mablを活かすならやるべきアクションだと感じています。

いいことしかない。

ちょうど今の仕事でテスト自動化も支援する場合があり、スマホアプリはまだいいかんじのツールが見つかっていませんが、Webであれば mablやAutifyをすすめるようにしています。最近、mablのドキュメント翻訳をやっているのも、お客さんに聞かれて調べた結果だったり。

サービスを売りたいmablと、mablをうまく使って開発を成功させたいクライアントとをつなぐ仕事も増えてきそうなので、今後も注目しながらフィードバックしたり、翻訳やイベントを支援したりしたいなぁと考えています。

発表資料

発表資料は↑を参考にどうぞ。最後に引用した言葉は『未来を読む AIと格差は世界を滅ぼすか』からの引用で、本書では、今後どんどん仕事が自動化されてしまい、大量の「役立たず階級」が創出されると示唆しています。

しかし、別の学者は以下のように述べています。

デジタル経済とは何か。自分の働く領域において、「規模の経済」を築く方法を見つけなければならない、ということです。

「自分の働く領域において、規模の経済を築く」ためには、自分自身をスケールさせる必要があります。これまでは自分は「人間1名」でしかなかったため、時間や体力といった制約がありました。

しかし、デジタル化された経済においてはスケールが可能になってきました。機械に大量の仕事をまかせ、自分自身にしかできない領域をスキルとして磨いていく。

もしかしたら mabl が提供してくれるサービスは、品質やテストではなく、個人のスケールかもしれません。