はじめに

どうも！

ユニファ株式会社でQA（品質保証）エンジニアをしています、高田です！

気づけば、満開の桜は早々と葉桜になり、GWも終わりに差し掛かろうとしてる今日此の頃。

皆様、いかがお過ごしでしたでしょうか？

大型連休にレジャーなどのアクティビティを経験した方など、色々といらっしゃったと思います。

かくいう、私、高田は、

そして、

と、「普段通りに、過ごして」いました！

さて、アラフォーの孤高（？）なGWの過ごし方はさておいて。高田がユニファに入社してから、半年くらい経過した今。

この半年ちょっとの時間の中で、テスト自動化導入に対して「各メンバーが、正対（正面から向き合う）して事にあたっていた」ように思っています。

テスト自動化のツール選定、検討会のMTG、トライアル、さまざまな発見や苦悩、困難、再出発と目まぐるしく動いていました。

テスト自動化導入にあたって、今回は備忘録も兼ねて、「ユニファQAでの、テスト自動化奮闘記」を書いていこうと思います。

とはいえ、ダラダラ長いこと書くのを避けて、コンパクトにまとめていきます。

※前回の投稿の反省を踏まえつつ、書いていきます。

もしかしたら、「物足りない！」と思われると思いますが、長文にしてかえって何が何だかわからなくなるよりかは良いかなと。

とにかく、要点を押さえて今回は書いていきます！*1

早速ですが、エピローグからお話したいと思います。

テスト自動化の本格導入に至った、最初のキッカケ。

それは、「ある危機感」から、始まります。

始まりは「ある危機感」から

「限られた時間でしか、回帰テストを実行できない」

去年12月に開催した、テスト自動化検討のMTGにて出た問題提起から、始まりました。

回帰テスト*2は、ソフトウェアの変更・修正があったときに「既存の機能にデグレ*3があるかどうかを確認する」テストであります。

そのため、新規機能のテストとは別軸で、定期実行することによってそのテストの効果を発揮するのが、回帰テストになります。

ユニファQAでは、その定期実行する回帰テストに割く時間・人員が確保出来ないまま過ごしてきた経緯があります。

上記の問題提起の背景には、過去に新機能の開発案件にリソースを割くのがやっとで、回帰テストにかけられる時間は減っていき、リソース不足でテストを一部断念してきたことがありました。

その一部断念したケースで、不具合が再発することが何度かあり、開発・テストの手戻りや既存機能の品質担保を保証できないこともありました。

他にも、「改善活動やその他の業務をしたいけど、割ける時間が無い」などありました。

これでは、品質が伴わければユーザーの方々に安心して使ってもらえない。

また、日々開発してプロダクトを拵えてくれている開発メンバー、Biz側のメンバーにも同様に言えます。

そんな上記のような強い危機感から、各メンバーがテスト自動化への一歩目として踏み出すきっかけと、なりました。

ツールの選定とROI試算

さて、そんな危機感から去年来から本格的に「テスト自動化の導入に向けた活動」に入りました。

まず最初に行ったのが、ツールの選定でした。

ツールの選定には、以下のツールを検討しました。

mabl
Autify
MagicPod

選定した基準には、「ノーコードでテストケースを作成する」ということにあります。

ユニファQAのメンバーのほとんどが、コーディングに慣れていないということからです。

mablについては、高田が入社する前にトライアルを実施しており概ね使用感がわかってきたところで、2社目としてAutifyが挙げられました。

早速、Autifyに問い合わせて営業担当の方と下記の内容を共有し、MTGを重ねて来ました。

トライアル対象のプロダクトとテストケースの選定
ROIの試算*4
トライアル日時の調整

また、テスト自動化の導入に先立って、2/24の記事の「ユニファQAの姿」の内容を、目的・手段・方向性の一案としてメンバーに展開しました。

上記を展開した理由としては、「ユニファQAの姿というものを、その行動指針から思い描いてテスト自動化の導入の活動にあたってほしい」というところから来ています。*5

対象となるプロダクトはルクミーフォトとルクミードキュメンテーション、共通基盤システムで決まり、トライアルするテストケースについても回帰テストのテストケースをベースにし、実際にAutifyをトライアルする際も既存の回帰テストケースを、どれくらいテストケース化出来るかという視点で見ることにしました。

ROIの試算において、既存の回帰テストケースから、自動化対象のプロダクトのテスト実行時間を、以下の3つのパターンを算出しました。*6

最速
標準
最遅

テスト実行見積もりの応用で上記を算出し、Autifyの営業担当の方に共有し、各テスト実行時間タイプ毎にROIを算出いただきました。

2〜3週間ほどトライアル期間を設けて、テスト自動化検討に携わっているメンバーそれぞれが、回帰テストケースをベースにAutifyのトライアルを行いました。

ドキュメントも豊富にあり、最初の環境構築もそんなに手間もなく、順調に進み、すぐにテストケース作成に入れたことが、最初の印象です。

テストケースの作成についても、直感的に操作が可能で、学習コストをそんなにかけずにサクサク作成できました。

わからないことがあった場合の問い合わせについても、返答がすぐにいただけたりと、サポートについても良い印象でした。

その他、ノーコードだからかメンテナンスコストもそんなにかからずに工夫次第で改善できることも、トライアルのなかで判明したこととして挙げられます。

ただ、ダウンロード確認やカレンダーから日付を選択する操作といった、細かいところでAutifyでは難しいこともわかりました。

そんなこんなで、トライアル結果からAutifyを導入する方向に概ね決まり、途中、ケース重複などにより対象のテストケース数に調整が入り、再度ROIを算出いただきました。

そこでの結果は、次のように営業担当の方から告げられました。

"現状ではコストインパクトは小さく、ただリグレッションテストケースを自動化するだけでは効果が薄い"

"問い"が、無い

Autifyの営業担当の方からFBいただいた内容は、以下の3点になります。

自動化のメリットである「実行頻度の向上」「カバレッジの改善」といったことが含まれていないと、現状ではコストインパクトは小さい
QAプロセス・開発品質の改善といった目標を置くことが可能であれば、インパクトは大きくなるだろう
短期的ではなく、中長期を見据えたことを考慮して考える必要がある

ここまでお読みになって、薄々お気づきかと思います。

それは、「ユニファQA側に、問い(Issue)が無い」というところです。

「何が問題 / 課題で」「どこに問題 / 課題があって」「どうやって問題 / 課題を解決すべきか」。

そしてそれは、「答えを出せる問題なのか」。

「回帰テストをしたい」というところにフューチャーしすぎて、本質的な問題や課題を導出できていなかったこと。

更に、Autifyを導入したいという目的に変貌し、手段と目的がごっちゃ混ぜになり、目指すべき目的を見失っていたこと。

また、個人的に調べたことから判明したことですが「回帰テストをただ自動化するだけでは、"素朴なテスト自動化"となり、自動化する意味がなくなってしまう」ということです。

この"素朴なテスト自動化"は、末村拓也さんが著したテスト自動化実践ガイド継続的にWebアプリケーションを改善するための知識と技法に掲載している「手動テストと自動テストの悪いところ取りになっている、テストの品質が落ちて開発者の助けにもならないもの」*7として紹介しております。

その他いろいろなFB*8を得て、以下の問題をチーム内で挙げました。