スポンサーリンク

自動化はテスター撲滅の夢を見るか?JaSSTで語られたテストの未来、品質の未来 #JaSST

テスト自動化におけるもっとも大きな課題とは?

藤原:次の質問からは、自動化の課題とその対策の話をさせていただきますが、ここで全部紹介するのは無理なので、パネリストへのインタビューの中でおもしろいトピックがあがってきたものを選んでいます。

課題については、Automation Pattern Wikiというサイトがあって、自動化の課題パターンがまとめられているので、あとでぜひ調べてみてください。その課題を日本語訳にして、整理して、みなさんに回答や投票していただきました。%は投票率と考えていただければとおもいます。

まずはじめの課題がこちら「テストが失敗したわけではないのに別の要因でテストに失敗してしまう」というものです。これは一番多かった課題で、投票率も80%と高くて、20戦士のアンケートでも60%を超えて高いものでした。類似の課題で、テスト用サーバーが少ないとか、ネットワークが弱いとか、環境が悪くて不安定というのも多くみられました。

ここで松尾さんに伺いたいのですが、環境の課題がトップを占めています。ご自身のご経験でもありましたか?

松尾:あるときは成功するのにたまに失敗するとか、いわゆるネットワークのような外的要因が原因というのは多いと思います。

今回のパネルが指す自動テストの範囲が、UTからE2Eを対象としていますが、何も考えずに実環境においてE2Eを組んだ場合、たとえば東京近辺の混雑する時間帯でネットワーク遅延が起きるとかあったりして、その時間にたまたまテスト実行して失敗するとか。

そういう本当にテストスクリプトの外的要因、それをひっくるめたE2Eテストなので、目的を持ってやるべきものなんですが、失敗したけどリトライして成功とかありますよね。意図して書いたスクリプトが変わらなくとも、その外的要因(考慮していた要因、考慮不足だった要因)が原因で失敗するのはたくさんありました。

僕はクックパッドでとくにモバイルアプリの自動化をやり続けてきたんですけど、テストの実行基盤がどれほど安定して運用できるかがポイントでした。なので、ユニットテストなり、E2Eとテストなり、大抵はテスト基盤をどれほど保全できるかが、不安定さをへらす大きなものになります。

Headspinにうつったのも、モバイルアプリのテストは、実行環境とかをエミュレータとかシミュレータにしない限りはまだいろいろ不安定だったり、端末を管理しなければならなかったり、そういう外的な失敗要因をだんだん減らして、失敗が少ない安定した環境を提供したかったからです。さらに、実環境に近い環境やメトリクスの提供を安定して提供できるする必要があると感じていました。

テストが失敗する原因はいろいろありますが、その軽減として安定したテスト基盤が必要不可欠で、とくにモバイルの世界、さらには実端末の世界では、すごくむずかしい段階だなと感じています。

藤原:たしかに。メルカリもアプリの会社ですけれども、テスト環境の安定化が運用のほとんどになっている現状があります。

この環境の問題が一番にでてきたのですが、テストコーチ、アジャイルコーチとして百戦錬磨の山口さんにぜひ伺いたいのですが、こういう課題っていろんなところで出てくると思うのですけれども、どう避けられてきましたか?

山口:やはり、この手の安定性ってすごく大切で、そもそも安定しないとテスト自体の信頼性がゼロになってしまいますし、実際、安定しないから「自動テストをやらない」になりやすいので、コーチとしてテストを書いていただく立場でたち振る舞っているので、極力、そういう課題を先まわりして提供して、回避をしていく形をとっています。

逆に、そういう外的要因が発生しにくい部分からテストを積み上げていき、安定しないテストがどでてきたところで「じゃ、どうしようか?」と考えたりもします。もちろんそうなる前に安定させられるのであれば、極力安定させていくんですけれども、どうしても実端末とかで制御しきれないところはあるので、外的要因が起きにくい部分からテストをはじめるのもやっておりました。

実際、そこでつまづかなくても、自動テストのメリットが享受できるエリアは多いので、そこでやめてしまうというのは僕からしたらもったいないと思っているので、そこじゃないところからきちっとやればいいんじゃないかとよく伝えていました。

藤原:そのあたりが流石ですね。コーチとか教える立場でいて、できるだけ課題を想定して動かれていますよね。だからか、直面した課題にチェックとか、山口さんほぼつけてないんですよね。「ほんとかよ!」と思ったのですが(笑)、実際に話を聞いてみると、そうならないように、どこからやるかとかをちゃんと考えられていたので、僕もアジャイルコーチとかしていた時代があったので、本当に勉強になりました。

テスト自動化チームの立ち上げと人材獲得

藤原:次の課題に行きたいと思います。2番目は「テスト自動化チームがいない、または、立ち上げが難しい。人材がいない、または少ない」が多かったです。

大園さん、Line Fukuoka で自動化チームを立ち上げされましたが、このへんの課題についてはどうでしたか?

大園:私に関して言うと、立ち上げに難しいというのは正直なかったですね。まぁ、がむしゃらにやっていたと いうのもあるんですけれども、むしろ今、拡大フェーズに入ってきて、もっとチームを拡大したいんだけれども、なかなか採用が難しいというのがちょっとあるかもしれないですね。

先程、お話がでましたけれども、僕の中ではE2Eテストってシステムを作るのとかわらないと思っているんですよね。そのシステムを作るにあたって、基礎的なエンジニア力は必要ですし、自動テストを単に書いているだけだと、ちょっと難しいというのもあるので、エンジニア採用とあんまり変わらないかなと思っております。

藤原:ありがとうございます。スケール段階を迎えているということで、逆に山口さん、自動化チームのスケールについてどうおもわれますか? ヤフー結構でかいですよね?

山口: そうですね。だいたいモノづくりにたずさわっているのが、今3000名ぐらいいるんですけれども、そこに対して、SETチームや自動化チームで対処するのは、気持ちはわかるけど現実的ではないんですよね。

むしろ、各チームごとでやっていくのが必要になってくると思っていて、そうなると、各現場で自動テストを書けるようになる、作れるようになる、E2Eシステムを作れるようになるっていうのが必要になってきます。

だから、人を増やすというよりも、その人達ができるようになっていく形に切り替えていかないといけなくて、自動化チーム自身、立ち上げですとか、人材いないというとかあるんですけれども、そこを強化するよりもその先をめざして、実際のサービスの現場に自動テストを伝えたり、教えたり、一緒に動ける人が増えるようにしなければならなくて、実際にできる人をきちっと配置、起用することが必要かなと思っています。

藤原:できる人のポイントはありますか?

山口:先程、大園さんもおっしゃっていたんですけれども、やっぱり、結局の所、自動テストシステムを作っているので、その観点はある程度必要かなと思いますし、テストをなるべく無駄なく効果的にやりたいので、その点も必要になると思います。

ある程度の理解や知識、経験が必要かなと思っていますが、いずれにしても自動テストって一夜で全部ができない世界です。徐々にできてくるので、それにあわせて学べる人、学び続けて動ける人がいればいいのかなと思います。

テスト自動化の見積もりと計画づくり

藤原: 次の課題どんどん行きたいと思いますが、「何を自動化の対象にするか、どのテストを自動化するか、スコープや計画や準備がきちんとできていない」が50%となっており、20戦士アンケートも58%とけっこう多かったです。たくさんの方が計画や準備といった、どこをどうやるのかという点で苦労されているみたいです。

ここでもいくつか質問があるのですが、LIFULL木住野さん。えいやーとテストを作って失敗された話をインタビューでされていたとおもいますが、その経験を教えていただけますか?

木住野: はい。私達のシステムテストは、2012年くらいからスタートしていて、とにかく当初、常識というかセオリーというのがなかったので、まずテストカバレッジを増やす。増やせば品質が担保できると考えて、そのときは進んでいました。結果としてとにかく機能を洗い出して、とにかくそのテストを実装したので、1000ケースほど実装しました。

しかし、このテストで何を守りたいのかを不明確なまま進めてしまい、不明確なままで運用を続けていった結果、さきほど週4回リリースと話したのですが、当時は週2回リリースで、その都度リリース前に自動テストを当時のQAチームが実行していました。

その自動テストを運用している人が4人いて、その4人全員がまる1日使って、テスト結果を確認して、メンテナンスを行う・・・といういわゆるアンチパターンにおちいっていました。その後、リリースが週2回から4回に増えたんですけれども、開発プロセスを改善して週4回リリースに高速化するときに、それがボトルネックになってきたんですね。

そこからテストを減らす、テストを最適化する話になっていくのですが、どうやって最適化したかというと、テストの対象が明確ではなかったので、単純にテスト計画を作りました。QAやテストをやっている方から見ると当たり前の話だと思いますが、私達の自動テストにはそれがなかったので、それを行いました。具体的にはテスト対象をしぼりました。これも当たり前の話だと思います。そして、手動テストと自動テストで、どちらのテストで何をカバーするんだっけ? を明確にしました。

そのあとも、自動テストでカバーすべき範囲がまだ不明確で大きかったので、そのなかさらに、どういったテストを対象にするかを2つの方針を決めました。ひとつが「ビジネスにおいて壊れてはいけない機能は絶対守りましょう」、もうひとつは「過去に障害が起きてしまった機能は絶対ケアしましょう」です。

さらに、ビジネスにおいて壊れたら困る機能ってなんだろう? という定義をより明確にしていく必要があって、そのために、取得しているログをGoogle Analytics(以下、GA)で解析し「このページはどのくらいPVがあるか」や「ページの価値」を調べ、そこからページの優先度を決めて、そのページにある機能は優先度高いと決めて、テスト対象をしぼっていきました。

藤原:ページの価値をPVとかで見ているのって面白いですね。数値化しているってことですね。

木住野:GAには、PVとページの価値という2つの値があって、それをかけ合わせてページの価値を定量的にはかっていく形になります。その内容をテストに落とし込んでいった結果として、今、SETグループ3人なんですけれども、長くて1〜2時間程度で確認が終わるようにまでプロセス改善できました。

藤原:おなじく大園さんも作り直しを経験したんですよね。それはどういう失敗だったんですか? 何が足りなくて失敗されたんですかね?

大園:はい。もうスクラッチから、スクラッチから、スクラッチから3回ぐらいやりましたね。今おっしゃっていたこととほとんど本質は同じだと思うんですけれども、本当になにも考えずにどんどんスクリプトを作ってしまったというのが、多分一番の失敗の原因だと思います。そこで、何をロギングするか? 何を評価するか? というプロセスがすぽんと抜けて、とりあえずテストいっぱい回したよ。すごいでしょ! みたいなそういう雰囲気を一番最初にやってしまった感じですね。

つい最近、立ち上げ時からぼくと一緒にやってくれている相棒と、僕らどんな失敗したっけというのをホワイトボードにどばーっと書き出したんですけれど、一面ぜんぶうまりましたw

藤原:ホワイトボードなのにホワイトな部分がなくなったんですね(笑)。

大園:はい。ホワイトボードなのにぜんぶ真っ黒にうまりました(笑)。それぐらい失敗した数は多かったと思います。でも、それのおかげで何が大切かを学ぶこともできましたし、必要な失敗だったと今は思っています。

藤原:ありがとうございます。あとは根本さん、我々もメルカリで失敗というか、自動テストを作りまくった経験がありますよね。どうでしたか?

根本: そうですね。本当に一緒で、一番最初にえいやーと手動でやることを自動化していたんですけれども、課題になっていたのはテストケースで、新しい機能がふえたときなどに更新されてなかったりとか、自動化エンジニアがケースを確認したときにどういう意図でこれが作られたのかっていうのが誰もわからなかったりとかしました。

あとは、新しくケースが追加されたときに、それがちゃんと自動化されるまでのプロセスにはいってなかったりとかも問題になりました。作り直した経緯としては、テストケースを新しく作り変えましょう。それにあわせて自動化も作り直して、プロセスを作っていきましょうという形でした。

マニュアルテストを自動化してしまうアンチパターン

藤原: この課題は次の課題にもつながるんですけれど、同じく50%で「手動のテストケースをそのまま自動化してしまって、テスト効率が悪い」という課題もあるようです。

僕自身も手動テストの自動化や、そのメンテをしているんですが、結構この課題ってアンチパターンじゃないかなと思う部分があります。なぜなら、手動テストって手動のためのものなので、自動テストのようにパーツを共通化したりとか、自動ならではの省略をしたりとかができていない。

どうでしょう、松尾さん、マニュアルテストをそのまま自動化すると失敗する確率が高くなるのではないかなと思うんですけれども。

松尾:そうですね。具体的にいうと、たとえばアプリのUIテストをするときに、手動テストだと、システムの設定をonにして、こういうふうにして、これを実行する・・・みたいなケースを書いたとします。その設定は、いくつかのUIを経由して設定画面に行って行う必要があるとすると、手動テストではそれを愚直に書いて、その手順通りにやっていく。これを自動化用シナリオにするのは、とてももったいない。無駄が多いですね

というのも、とくにAndroidとかだと楽なんですけれども、そういう設定をオン・オフできる方法は、裏側でスクリプトを動かしたり、Helperアプリを作ったりするとできるんですね。それを短縮せずに自動化プログラムを組んでやると、UIのアニメーションによる失敗が発生したり、さきほどもあったテストが不安定になる環境に遭遇しやすくなります。

藤原:メルカリでもこの問題が大きくなっていて、マニュアルテストを更新した人と自動化する人の間でも確認に時間がかかるんですよね。だから、最近はいきなり自動化用テストケースを作ったほうがいいんじゃないかと思い、方針を変えようと思っています。

さらに、きしのさんとのインタビューでおもしろかったのですが、自動テストケースをつくったときにマニュアルケースがなかったんですよね? だから、いきなり自動ケースを作る必要があったと。そのとき困った点はありませんでしたか?

木住野: 当時(8年ほど前)はデグレなどがとても発生していて、それが障害につながってしまう状況になってしまっていました。そして、テストにかける工数をQAも開発チームも取れない。手動テストケースに起こしたところで手動で実行もできない。アンチパターンも考えずに自動化するしかないという状況でした。

藤原:なるほど。最近だと、自動テストをいきなり書き出すケースもあると聞いているので、結構これはアンチパターンではないか思います。まだチャレンジしているところなのでわからないんですが、結果がでたら共有させていただきたいなと思っています。

テスターは自動テストを書くべきか?

藤原:次の課題は「テストを実行する人が自動化用テストケースを書けない」です。テスターがテストコードをメンテナンスできない問題ですね。大園さんと木住野さん、もともとQAエンジニアから自動化エンジニア、SETというキャリアをつまれていますが、今スクリプト書けてますよね。苦労とかありませんでしたか?

木住野:そうですね。僕自身はプログラミングできなかったという苦労はなかったですね。なぜかというと、私はQAチームに所属していたんですが、当初からそこに自動テストシステムがあって、プログラムを学ばざるを得ない部分があったので、苦労はなかったです。

別の苦労になりますが、「テストスキルがそもそもなかった」のが僕自身一番苦労したところで、先程失敗した例でもありましたけれど、何をテストすべきかというのはその当時わからなかったので、大園さんもおっしゃっていましたけど、テストを自動化すること自体が、ブラウザが自動で動くこと自体が楽しいというハイに陥ってしまうと、もうわからなくなって、ああいう失敗に陥ってしまうので、テストスキルを学んで、自動テスト以外にもQAのテストにちゃんとかかわって、計画を作り、設計も書いて仕様に落としこむ・・・。ここまでできるようになるのに一番苦労したかなと思っています。

藤原:大園さんも同じくSET、自動化エンジニアになられてますが、苦労はなされましたか?

大園:なかったと思います。QAからのロールチェンジと言うと語弊があるというか、QAを半年もやってないんですね。だから、テストに精通してたというわけでは特になくて、もともと科学演算とかをやっていたという流れで、ソフトウェア自体にはちょっと明るかったところもあったので、そんなに苦労はなかったかなと思います。

藤原:Line Fukuokaさんの自動化チームに入ってこられる方はエンジニアが多いですか?

大園:僕のチームは今もうほとんどエンジニアですね。

藤原:メルカリも同じです。エンジニアの方が多くて、海外の人は特にQAエンジニアから自動化エンジニアというキャリアの方が多いですね。

テスト自動化推進の組織的な理解

藤原:次の課題に続きますが「テスト自動化チームがマネジメント層やテスター、他の関係者から十分なサポートをもらえない」が20%と低いんですけれども、一応課題としてやっぱ出てくる部分もあるようです。このあたりで根本さんは苦労されていますか? まぁ、一応、私、あなたのマネージャーですけれども。いいんですよ。言ってくれて(笑)。

根本: マネージャはありがたいんですけれども(笑)、実際には(開発を担当する)エンジニアだったり、QAエンジニアと働いてますが、結論から言うと一番仕事しやすいのは、品質だったりとか、生産性に責任がある人。メルカリだと特にTech Leadと呼ばれる技術的責任を持っている人やエンジニアリングマネージャ。そういった方とはすごく働きやすいなぁと思います。

サポートする立場でいうと、短期的な施策の中で、テスト自動化で価値を出すのはとても難しいと思います。なぜかというと、その人が次のプロジェクトに移ったり、責任から離れてしまったりするときもあります。

プロジェクトが佳境を迎える中で、テスト自動化大事ですよっていってもなかなか難しい。砂漠の中で食べ物や水がない人に向かって「森って大事ですよね」といっても伝わらないじゃないですか。ほしいのは水や食料ですから。

藤原:ありがとうございます。じゃ、次に山口さんに伺いたいのですが、こういった課題はご自身のコーチ経験の中でありましたか? どんどん現場に入っていく仕事ですよね。

山口:はい。ヤフーの仕事のやりかたを少しご説明しないと、このへんは話せないかなと思うのですが、基本的にヤフーの中において、明確に上から仕事がやってきて「必ずこれをやらなければならない」とか「これ以外はやってはいけない」とか、そういった仕事のやりかた、サービスづくりしている人はいないです。

ある程度の自由度があり、もちろん厳しいルールや条件にはさらされているんですけれど、「何かをしてはいけない」というような仕事をしていないので、僕らが社内に行くときには、実際にプログラム(コード)を書いている人にアクセスしていて、困っている人のところに行くという形でやっています。そうすると、その人が「自動テストいいな」と思えば、それをその人のマネージャやチームメンバーに伝えていけば伝わっていくので、サポートもらえなくて困るってことは僕の中ではないですね。

逆にトップダウンで入れたほうが良いときもあるので、それはもちろん、効果とかをマネージャや経営層に伝えて、上からトップダウンで施策を進めますが、そういったときはこっちから自動化を仕掛けていく形なので、「サポートをもらう」というより「サポートをください」なので、今のこの課題とは違うかなと思います。

藤原:かっこいいですね! 「サポートもらえなくて困ったことない」って言ってみたいですね。こういうアプローチが許される環境というのは、すばらしいと思います。

私もマネージャとして施策を考えるときがあるんですけれども、成功する秘訣はわからないんですけれども、だいたい失敗するときって「カバレッジを正確にもとめてくるやつが現れたとき」とか、そういうときはだいたい失敗するんですよね。もとのケースが悪ければ、カバレッジ上げるだけでは効果が大きくならないし、トラブルもおきちゃいます。指標の説明は難しいのですが、人的、お金的なリソースとかの補助とかはしていただきたいので、その意味や意義を理解してもらうための説明も大切だなと感じています。

ここから業務連絡なんですけれども、ちょうど45分ぐらいで順調です(笑)。この調子でお願いします。

>>パネルはいよいよ後半戦へ。テスト自動化のための理想の体制とロールとは?

タイトルとURLをコピーしました