TEST Study #2での質問に答えます　その１

6/30にForkwell・Autifyさん共済のイベント、TEST Study #2「ソフトウェアテストにおける自動化」にて発表をしてきました。

その場でsli.doというツールを使って質問を受け付けていたのですが、時間の都合もあり答えきれませんでした。

運営の方から許可を得て、ブログ記事の形で質問にお答えしていこうと思います。

全部「要はバランス」「ケースバイケース」と言ってしまわないよう、なるべくちゃんと書きます・・・！

日本でのソフトウェアテスト業界はエンジニア単価が海外と比較して低いため自動化テストの需要はあまり多くないと考えるが、どのような利点・需要で自動化テストが普及できると考えていますでしょうか？

コンテキストを正確に捉えられているか自信が無いのですが、エンジニアの単価が低いから、人海戦術でやってしまえる（≒自動テストの需要はあまり多くない）、ということでしょうか？

そうですねー・・・テスト自動化に限らずですが、コンピュータリソースより安いエンジニアっていないはずなので、基本的には自動化できるところは自動化したほうが安くて速いだろうと思います。

ほかには自動化する利点の一つに「正確性」が挙げられることがあります。繰り返し同じテストをする場合に、担当者による判断のブレやミスがなくなることにも一定の価値があると考えます。

結合以降、例えばe2eの自動テストやる場合、製造・改修コストを考えるとどこまで自動化するか知りたいです。

例えば発表中で紹介した自動化対象のテストを選択するAngie Jonesの方法では、グリーンのところ＝Scoreが70以上のものまで、にしておくと、コストをかけすぎずに自動化のメリットを一定得られると思います。

もっとROIをちゃんと計算したい、という場合にはCost-Benefit Analysis of Test Automation（PDF）や、これについても触れられている大田さんの連載「テスト自動化のROIを計算してみよう」関連の最新ニュース・レビュー・解説記事まとめ - ITmedia Keywordsなど見ていただくと参考になるかもしれません。

経験則で結構ですので、アプリE2E試験自動化はAndroidとiOSのバージョンいくつからが妥当ですか？

これは、ユーザ向けにサポートOSバージョンを決めていたりはしない、ですかね？決まってるけどテストはそれより狭い範囲をやる、でしょうか。

えいやで決めるときは「メジャーバージョン3世代」とかにしてしまいますが、実際にはもう少し丁寧めに見ます。

例えば「モバイル　OSバージョン　シェア」などで検索すると概要情報が出てくるので、それを見て「9割カバーするのはここまでだな」と線引する、などですね。

さらに真面目にやる場合は、

OSのシェアに関してデータを販売している会社もあるので、そこからデータを買って判断
実際の利用者のデータから割合を判断

かと思います。

短時間化のコツを教えていただきたいです。

E2Eテストの場合は特に、並列化かと思います。CIツールなどを使って実行環境複数にテストを割り振って実行させると、単純計算でN並列でテストを行えば時間は1/Nになります。実際そう単純にはいきませんが・・・

単純にいかない理由でよくあるのは以下かと。

テストケース間の依存関係
テストデータの準備にどうしても時間がかかる
実時間が絶対にかかるもの（月次バッチをはさむテストなど）

依存関係とかテストデータの準備などは、並列化しつつ、効率のよい順序を考えるパズルみたいになると思います。

月次バッチをはさむようなテストも経験がありますが、テスト環境のシステム日付をいじりながら5日間かけてやってました。これは短くできなかった・・・。

手動テストへの自動化の導入方法を知りたいです。

おそらく講演＆パネルディスパッションで触れたところかなーと思うのでさらっと。

自動化したいところを選んで、ツールを見繕って一部分をトライアルします。うまくいきそうなら範囲を広げます。

昨今のモバイルブラウザの使用シェア率を鑑みると3番手～5番手のSamusung Internet, Opera, UC Browserを自動化でカバーするのはなかなか厳しいなと個人的に感じていましたが、E2Eでカバーしないブラウザとのテストにおけるよい付き合い方、考え方があればご教授いただきたいです。

Samusung Internetあたり意外と無視できないくらいの割合で切り捨てられないですねー。

あまり良い答えではないかな、と思いつつも、実際にやっていた考え方は「ブラウザ固有の不具合が上がってきたら対応検討」でした。自分がモバイルブラウザのテストをしていたときは、アプリケーションの性質なのか、Chrome/Safari以外のブラウザに固有の不具合というのは出てこなかったので・・・

自動でのE2EテストはChrome/Safariをざっと流して、他のブラウザに関してはごく限られた基本ケース（優先度Sのもの、のような基準で）だけを手動でさらう、ような運用でした。

QAは、プロジェクトのUT / IT / STのボリュームを知っておくべきですか？

「QAは＊＊＊を知っておくべきですか？」という質問に対してはすべてYesになりますね。という半分冗談はさておき、ボリュームを知っておくこと自体が本質ではないと思います。

UT/IT/STで「何をしているのか」「それぞれが何を担保しているのか」を知ったうえで、開発サイクルをもっと短くする等の改善活動を行う際には、QAとしてそれぞれのボリュームを把握して、ということもあるかもしれません。

バグフィルターわかりやすいです😀

ありがとうございます！（私が作ったわけではないのにドヤる

自分たちがどのピラミッドを目指すべきか、どうやって決めればいいですか？

綺麗事としては「試しながら改善を続けましょう」になるのですが、おそらくそういうことを聞きたいわけではないと思うので・・・

一つハードルの低いやりかたとしては、類似のモデル、例えばテストトロフィーにおいては3 Reasons to Win the Testing Trophy - DZone Open Sourceのように「トロフィーのほうが良いぜ！その理由は・・・」と書いてある記事などを読みつつ、その「優れている」と言っている根拠が自分たちにマッチするものを選ぶ、が良いと思います。

チームによって最適な形は異なるので、「自分たちのテスト対象や状況に近い人達が一番良いと言っているものをまず真似してみる」作戦ですね。

手動テストや自動テストのコストが高いテストケースというのは、具体的にはどのようなものなのですか？

これもいろんな要素がありますが、例えば以下かと

実行のための事前準備・事後処理が沢山必要
- データを登録して変更して裏でバッチ処理流して・・・など準備のステップが多い
- 必要なテストデータがそもそも多い
- 普段のオフィス以外の環境でテストする必要がある　などなど
テストの手順が長い

もし「聞きたかったのはそういうことではなくて～」と思われた場合は追加で質問お願いします。

リスクは、プロジェクトが抱えるリスクと、自動化によるリスクの両方ですか？

詳細はAngieのスライド参照ですが、リスクは

Probability：顧客の使用頻度
Impact：もし壊れた場合に顧客に与える影響

とされています。

なので、その２択だとプロジェクトが抱えるリスク・・・に近いでしょうか。

e2eを関にして、リファクタリングは、ちょっと危ない気もします。

ちょっと危ないですね。無いよりは良いと思いますが。

資料中でご紹介されていた参考書籍、一覧をいただけないでしょうか、、、？

こちらです！