この記事はソフトウェアテスト Advent Calendar 2017 – Qiitaの2日目です。

前の投稿はpineapplecandy – Qiitaさんの独断と偏見で選んだテスト系イベント/Twitterアカウント 2017(若手向け)でした。

お疲れさまです。@yoshikiitoです。

ソフトウェアテストの会社に新卒で入ってから５年ほどテスト自動化業務を行い、色々と経験もたまってきたと思うので、今回はテスト自動化について書こうと思います。

アドベントカレンダー管理者のぱいんさんからの天啓です。

言える範囲が少ない（？）ので、自動化で「ありがちな」悩み事と、それに対する私の考えを書きます。

本題の前に

自己紹介

伊藤由貴といいます。本名です。

界隈の有名人に伊藤さんが何人かいるので、もう少しキャッチーな愛称とかあったらいいなと思いつつ過ごしています。

情報系の大学院（テスト専門ではない）を出て検証会社に入り、今年６年目です。

主な業務はテスト自動化で、だいぶ前はUFT、最近では主にSeleniumを使っています。

前は自動化ツール作ったりもしていました。

といった背景の人間が書いている、という前提で本記事も参考にしていただけると嬉しいです。

注意事項

本記事における「テスト自動化」や「自動テスト」は、主にGUIの操作を自動化することによるテストの自動化を指します。開発者が行うユニットテストや、負荷テストの自動化などは対象外とします。

テスト自動化するときの悩みやうまくいかないこと

さて本題です。

テストの自動化をしていると、悩み事やうまくいかないことがたくさん出てきます。そんな「うまくいかないこと」をたくさん経験するなかで、一言でまとめると**「集中と拡大」がよくないのではないか**、と思い始めました。

Badな集中

テスト自動化でありがちな「集中」は

  • 自動化担当者へのタスク集中
  • GUIの自動テストへのテスト集中

などがあります。

大きな組織でありがちなのが、テスト自動化の担当者（しかも他作業との兼任）を立てて自動化をさせて満足、というパターン。自動化を行うとコストがゼロになるわけではないのですが、ここを勘違いしているマネージャだったりすると大変。自動化担当者が残業して自動テストの実行＆結果確認を行って疲弊しているものの、社内では「自動化によって業務が効率化してコストダウンしています(ﾄﾞﾔ」みたいな報告が上へあがっていっている、なんて状態もあり得ます。

この状況はとても危険で、作業自体が属人化している上にその人のスキルアップも見込めず、かつ残業がかさんでいるということで、普通に考えてその担当者は辞めますよね。

そうなると、十分な引き継ぎもされずに自動テストが負の遺産に・・・という悲しい結末をたどります。

また、GUIの自動テストにテストが集中してしまうパターンも不幸。

『初めての自動テスト ―Webシステムのための自動テスト基礎』という本で紹介されている「テストのピラミッド」という考え方があります。

これは

  • UI
  • 統合
  • ユニット

の３層でテストを表したものです。

ピラミッドになっているのはすなわち下の層を厚くということなのですが、画面の自動テストというものに触れた（かつ、ちょっとえらい）ひとはすぐ「おお、じゃあこれで全部自動化だ！」となりがち。そうすると、本来ピラミッド型になってほしいはずなのに上の「UI」の部分が膨らんでしまいます。

結果的には、実行に時間がかかり壊れやすいUIの自動テストを人手をかけて実行・メンテナンスすることになり、品質向上に寄与しない自動テストへ・・・。

Badな拡大

続いて、テスト自動化にありがちな「拡大」は

  • 自動化範囲の拡大
  • テストじゃないところまでやることが拡大

などが挙げられます。

UIのテストを自動化しはじめると、「お、これならあんなことやこんなこともできそうだな」ということで、手当たり次第にいろんな方向に自動化範囲を拡大してしまう場合があります。

本当であれば、そのテストを自動化して本当に効果があるのか、品質向上に寄与するのか、を考えて自動化するテストを取捨選択することが必要なのですが・・・

そうなると、リターンの少ないテストの自動化にコストをかけることになり、自動化エンジニアの疲弊や、組織内でのテスト軽視（＝結局不具合減ってないし、ぜんぜん役に立たないじゃん！と思われてしまう）ことにつながります。

また、場合によってはテストと全然関係ないサーバの設定や日時バッチ実行や、事務処理なんかを自動化する方向に話が広がっていき、テスト自動化エンジニアがRPA屋さんのようになってしまうことも。

こうなるとテスト自動化エンジニアとしては「あれ、これってテスト関係ないよね・・・」というモヤモヤの種になり、その人がテストやQAや品質といった部分で身を立てようとしている人であればなおさら、精神的ダメージが大きいです。実はこれ私が経験あるやつで、一時期はほんとうに「自分はWindowsの操作自動化屋さんじゃない！！！！」と飲み会の場で愚痴り続けたことがありました・・・。

業務効率化とか、RPA自体はまったく悪いことではありません。が、それをテスト自動化エンジニアの作業範囲を拡大解釈して行わせるのは不幸のはじまりです。

Badな集中と拡大をやめて、Goodな集中と拡大をしよう！

ここまで、テスト自動化の愚痴悩みやうまくいかない点について「集中と拡大」というポイントで書きました。

が、集中と拡大というワード自体は何もネガティブな要素を含んでいません。何をどう集中するのかと、何をどう拡大するのかに問題があるだけです。

ということは、集中してまずいところは拡大し、拡大してまずいところは集中すればいいのです。図にしてみました。

まず、自動化担当者にタスクが集中したり、GUIの自動テストに集中してしまっている点。この点については、周囲を巻き込み、自動テストにかかわる人を拡大するのが良いです。

開発者を巻き込み、ユニットテストでできる範囲はそちらで高速に行うことや、自動テストのインフラ周りの整備やテストデータの整備などは自動化担当でないテストエンジニア・QAエンジニアやインフラ担当に協力してもらうことなど、狭い枠を超えて組織全体でプロダクトとプロセスの品質を上げる取り組みをするのが絶対いいです。

もうひとつ、自動化の範囲が拡大したり、テストじゃないところまでやることが拡大してしまう点。こちらは逆に集中することで対応しましょう。

自動化は、なんでもかんでも自動化すればいい、というわけではありません。自動化することによって効果的になるテストもあれば、逆に自動化によってコストが増えたり不具合を見逃してしまうようなテストも存在します。全部を目指すのではなく、まずは自動化が効果的なところに集中して行いましょう。

そして、できればテスト自動化エンジニアはテストの自動化に集中させてください。テスト自動化エンジニアが得意とするのはあくまでもテストの自動化であって、インフラまわりや事務作業などの自動化にはそちらを得意とする人が別にいます。適材適所でいきましょう。

まとめると結局「みんなでがんばろう」になりますね

と、長々と書いてきましたが、結局は「みんなでがんばろう」になります。

テスト担当者、ましてやテスト自動化担当者「だけ」が努力することでできることはたかが知れています。テストの自動化のゴールは品質に寄与することなので、そこに向かって全体が努力するのは当然。みんなで品質を上げる、その手段のひとつがテストの自動化、という位置づけを忘れないよう、みんなで取り組みましょう。

テスト自動化、自分も常に悩みながら勉強しながらやってて、たぶんこの先もずっとそうなると思います。一緒に自動化の話できる人いたらTwitterとかでぜひ！

参考