この記事を書いている時点ではやくも１ヶ月経ってしまっています（）が、mabl Japanさんのコミュニティウェビナーにゲストとして呼んでいただき、話をしてきました。

人類よ！これがテスト自動化だ！ | AIによるQA&テスト自動化サービスmabl - connpass

（※ちなみにタイトルの「人類よ！」については、私の１回前のリナさんからついてて、シリーズ化しています。）

当日の動画はこちら

イベント記事・レポートはこちら

会のスタイルとしては、ポンポン質問を出していただいて、私が考えを答えつつmabl藤原さんとその場で話す、という形式で行われました。

質問事項は事前に頂いていて、私も一応準備をして臨みました。もちろん、準備した回答を読み上げることはせず、「何がいいたかったか思い出せなくなったらアンチョコとして見よう」くらいの位置づけだったので、（たぶん）事前のメモと当日喋った内容が若干違うはず、です。

（もちろん、全く違うことを言ったとかではなく、表現の違いや、メモにはないことを言った＆メモにあることを言わなかった、があるということ。）

せっかくなので、事前にメモしておいた内容を、見せられるレベルに加工してだそう！というのがこの記事です。

Q&A内容

Q.伊藤のキャリアについて

  • 実はびっくりするくらい、紆余曲折がない
  • 今の会社に新卒で入って、新人研修のあとで配属になった初めての現場でテスト自動化ツールの内製をしており、自分が担当することになった
    • ちょうど担当していた先輩が辞めたこともあり。ブラック等ではなく、何か夢を追いかけたという噂。
  • そこから「テスト自動化できるやつ」と認定してもらい、いろいろなプロジェクトでテスト自動化を担当し、だんだんと導入のアドバイスをしたり、ひとに教えたりするようになった

Q. テスト自動化エヴァンジェリストとはどんな仕事か

  • （IPAが決めているとかではないので）定義はない
  • 自分が行っているのは「テスト自動化の普及活動」が主
  • 社内では技術教育や、自動化の技術的なアドバイス
  • 社外、業務でかかわる他社のお客様に対しては、技術的なQ&Aとか、コンサル的なお仕事
    • 「世の中では、他社ではどんなもんなんですか？」とか「ツールいっぱいあってわからないんですけど、どうやって選んだらいいんですかね」とか

Q. テスト自動化は広いが、UTからE2Eまで？

  • E2Eがほとんど。これは今いる会社のビジネスの主なターゲットがそこだから
  • UTも、例えばユニットテストフレームワーク使いましょうとか、CIやりましょうとか、そういう話や方針検討はする
    • UTを代わりに書くのはしない。外の人間が代わりに書くのはあまり意味がない気がするので。

Q. 自動化で工数は削減できる？

  • ケースバイケース、だけどここではそういう答えは求められていないので、なるべく私見を述べるようにします
  • 「工数」とは一体何の工数なのか
    • 聞かれた場合には「なんの工数のことですかね？」を確認する。
    • 聞いてくる方の何割かは答えに窮するので、「なんとなく工数がかかっている【気がする】」だけで、実はどんな工数がどのくらいかかっているのかの定量値を把握していない
      • それでは工数は削減できない。
      • 計測できていないものは、改善できないはず
  • そうは言っても実際どうなの、というところ
    • テスト実行工数、は削減できる部分はある
    • E2Eのテストを夜間実行するとか、並列に実行するとかで、多少「時間」を減らせる部分はある
    • APIテストを毎回コマンド手打ちでやってます、みたいな場合は自動化によってテスト実行工数は大幅に減る
      • でもこれって「そもそも無駄なことをやっていた」だけなので、自動化で工数削減というよりはやっと普通になった、という話かと
  • よく説明する内容
    • テスト実行の工数が減る
    • 自動化の工数がかかる
    • 結果トントン、ということもよくある
    • 一方で、自動化によって、コードを書いてから不具合が見つかるまでの時間を短縮することができ、結果としてコードの修正にかかる時間が減り、プロジェクト全体の「工数」で見たときに削減効果が期待できる、と説明する
      • もちろんこれもプロジェクトのどこにどのくらい工数がかかっているかによって変わってくる
      • やはり「＊＊＊という工程にこのくらいの工数がかかっていて、自動化で減らせますかね？」のレベルで会話できるのが理想

Q. 自動化で品質は上がる？

  • 上がる、と言いたい派
  • 体重計のメタファ
    • 体重計に乗ると体重がわかる＝テストをすると品質がわかる
    • 体重計に乗っても体重は減らない＝テストをしても品質は上がらない
  • 自動化をしたからといって品質は上がらないが、レコーディングダイエットというダイエットがあるように、自動化によってそもそもの開発プロジェクトが改善されて結果的に品質があがる、はありえる
  • 風が吹くと桶屋が儲かるくらいの距離感で、品質があがると信じている

Q. E2Eの場合、WebDriverとSaaSではどちらが強いか

  • 最近はSaaS強いなと素直に感じる
    • 自分はコード書くのが好きなのでWebDriverで自動化するのは嫌いじゃない、好き
  • テストSaaSが使える環境で、やりたいテストが十分SaaSで実現できる、という場合には、あえてWebDriverに行かずに素直にSaaS使うのは有効
  • WebDriverに限らず、コードを書くタイプの自動化ではよく「環境構築でつまづいた」とか「メンテができなくなった」という話を聞く
  • SaaSは上記のリスクを軽減できる。悩んだり頓挫したりしてせっかくのテスト自動化が止まってしまうのは勿体ないので、そうなるくらいならおとなしくSaaS使うほうが良い。「自動テストが継続的に動かせている状態」を実現するのが最優先。

Q. ツールは手段でしか無いと思うが、ツールを使うことが先行する場合もあるのでは？

  • ある
  • 自分が説明するとき・・・
    • 対会社：ツールは手段なので、目的をはっきりさせたうえでツールを選びましょう
    • 対個人：なんでもいいからとりあえずエイヤでツール選んで始めちゃえばいいんですよ
  • テスト自動化未経験の方に「テスト自動化とは」を一生懸命説明するよりも、「とりあえず画面動かしてみようぜ」のほうが伝わりやすい
  • 未経験の人はそもそも「テスト自動化に関する発想」がない。この状態で「目的を～」とか「自動化する対象をよく検討して～」と言っても、無理。まず手段であるツールを触って「テスト自動化」を体験して、武器を手に入れる。そうすると「この武器を使ってあんなことやこんなことができそうだぞ！」という発想が生まれる
  • こうした効果が期待できるので、あえてツール先行で入るというのもアリ

Q. アジャイル開発と自動テストの関係性。アジャイルテスターは存在する？

  • 自分の中のアジャイルテスター＝テストに限らず臨機応変にアジャイルチームの中で立ち回れるすごいひと
  • 自動テストはアジャイルでは必須なので、「全員できます」が理想
  • アジャイルテスターは、存在するものの、なにか違った肩書を名乗っていそう。スキルとしてアジャイルテスターを充足している人はいると思う。

Q. ずばり、テスト自動化がうまくいくのはどういうケースか

  • うまくいく＝継続的に成果を出せること、というのが自分の解釈
    • 1000ケースを自動化できたら成功、じゃない
  • 開発プロジェクトの始めから「自動化できるテストは自動化するもの」と思って物事をすすめるのがうまくいくパターンと考える
  • あとは人と時間と金をちゃんとかける

Q. QAが自動化するのと開発が自動化するのとどちらがよいか

  • テストレベルに応じて変わる
    • UTは開発、APIはQA、E2EはQA、など
  • チームによって「理想の形」があるはず
    • スキルセットや、人数比あたりは特に影響しそう

Q. 自動化の比率はどのくらいが適切？完全自動化はありえる？

  • 正直答えを持っていない
  • 既に手動テストがあるので、今やってるテストを自動に置き換えたい、といった（あまり理想的ではない）シチュエーションにおいては、E2Eテストの3,4割くらいが多い印象
    • 6割自動化できてます、だと「おー、がんばりましたね」って思う
  • 率、の話になると、いくらでもいじれてしまう
    • 極端な話、データ駆動テストで、やっても意味ないようなケースを増やしまくることで、見かけ上の「全ケース中の自動化率」を100%方向に近づけることができる
    • ただ、こんなことをしても全く意味がない
  • 完全自動化も、目指す分には止めないが、基本的には無いと思う
    • 目的を見失う危険のほうが大きい

Q. 自動化のコスパはどうか

  • もちろんうまくやれば良い
  • 「うまくやれ」るようになるまでの過程はコスパ悪く見えてしまいそう

Q. どこから自動化すべきか

リーン開発の現場
posted with ヨメレバ
ヘンリック・クニバーグ/角谷信太郎 オーム社 2013年10月
楽天ブックス
楽天kobo
Amazon
Kindle
7net

Q. マニュアルテストを自動化していけばいいか

  • 積極的にはおすすめしない。テスト自動化、は、手動テストを自動テストにコンバートすることではない
    • Checking&Testing
  • 一方、現実問題手動テストを自動テストにコンバートする作戦をとることも、ある
    • 最良ではないと皆がわかったうえで、「しかし、やむをえないから、やろう」と決めたのであれば、アリ
    • コスト的には大きくなってしまうが、一旦既存のテストケースを自動化して、チームの皆が「なるほど自動化ってこんな感じになるのね」を掴んだうえでもういっぺん検討しなおそう、とか
  • 理想的には、テスト設計以前から「自動化する」つもりでテストプロセスをすすめるほうがよい
    • 一方エヴァンジェリスト的な動きをするのであれば、こんな正論だけでぶん殴っても、自動化が普及できなくなってしまうので、バランスとろう

Q. 自動化のゴール設定は必要？

  • あったほうがよい
  • 自動化率とか工数削減率とかは危険な香りがする
  • 某社（複数）がカンファレンス等で発表していた内容では、たとえば「週に１回リリースする」という目標を設定して、そのためにはこれだけのテストをこの期間で行う必要がある→じゃあここからここまでは自動化せねば、といった流れで考えていた

Q. ずばり、テスト自動化が失敗する秘訣は

  • 成功の裏返しなので、人と時間とお金をかけずにやろうとすると失敗する印象
    • つまり「片手間で」というやつ
  • テスト自動化をなにか新規の取り組みとして始めようと思ったら、専任担当者は必須
    • 自動化に限った話ではない
    • そもそも片手間でやってできるようなものなら、とっくにできているのでは

Q. テスト自動化エヴァンジェリストになるために必要なスキル

  • どのような組織でエヴァンジェリストをやるのかによって変わってくる
    • 自社プロダクトを開発している会社なのか
    • テストや品質向上のお手伝いをする会社なのか
  • 後者の環境であれば、扱うプロダクトは組み込みもWebもモバイルもWindowsもアレもこれもと幅が広いので、様々な環境でのテスト自動化を知っている、が必須だと考える
    • そのうえで、共通する考え方と、個別の考え方と
  • 自社プロダクトがあるような会社の中で自動化エヴァンジェリストをやろうと思ったら、やはり自社の技術スタックに特化していく方向になるのでは
    • 私のような環境よりも、狭く深くが求められそう
    • WebならWebでめっちゃ詳しい、に

Q. 自動化エヴァンジェリストから見た手動テスト

  • 手動テストは無くならない、は前提として合っている想定
  • いまの「テスト自動化」は仰々しくなりすぎている
  • うまく表現できないものの、手動テストと自動テストの垣根、今はすごく大きな隔たりを感じられてしまっている部分が、だんだんなくなっていく方向に変化していくのでは