Autify Podcast : テスト自動化スペシャリストが語る「リグレッションテストはなぜ必要か」
Autify Podcast、はじめました
ソフトウェアテスト、スタートアップなどにフォーカスしてさまざまなTipsや、事例などをお伝えする番組、Autify Podcast をはじめました。
初回のトークテーマは「リグレッションテストはなぜ必要か」、Autifyのテスト自動化スペシャリスト、末村氏をメインスピーカーにお伝えしています。
ご意見、感想はTwitterでメンションしてください。 twitter.com/AutifyJapan
ここからは書き起こし記事です
永淵（以下、「ぎょり」）: こんにちは。オーティファイのぎょりです。オーティファイはエンドツーエンド（以下、「E2E」）テストプラットフォームを提供しているスタートアップです。このPodcast を通して、ソフトウェアテストだったりスタートアップのことを中心にお届けしていけたらなと思っています。
で、記念すべき第1回目のテーマは「リグレッションテストはなぜ必要か」というのをオーティファイのQAエンジニアの末村さんからお話ししてもらおうと思っています。
まずは末村さんのご挨拶からお願いします。
末村 拓也（以下、「末村」）: はじめましてのみなさん、はじめまして。こんにちはのみなさん、こんにちは。
オーティファイの、QAエンジニアって紹介があったのですが、ついちょうど昨日「もうちょっといい感じの名前、欲しいよね」みたいな話を弊社CEOの近澤さんとしていて 、「テスト自動化スペシャリスト・テストオートメーションスペシャリスト」というエモい感じの肩書きを拝命しましたので、これからはそれを名乗って行こうと思ってます。
ぎょり: めっちゃエモいいですね
末村: 良いでしょ、すごいでしょ。
ざっくりこれまでの経歴みたいなやつなんですが、社会人を10年くらいやってて5年ぐらいにフォークリフトを運転したりして完全にキャリアをドブに捨てていて、その後、そこら辺の経歴を踏まえて、とある物流スタートアップでQAだったり、テストだったりっていうようなところをやっていて、そこの中でテストの自動化っていうのも業務の一つとしてやってました。テスト自動化の経験を生かして、オーティファイに、2019年、去年ですね。去年の8月にジョインして、Autifyはテスト自動化をするためのプラットフォームなので、Autify自身のコアになる部分のバグフィックスだったり、ちょっとした開発だったり。
あと一番多いのはお客様から問い合わせを受けて、それに対して答えたり、Autifyのイケてないところがあったらそこを修正して、っていうことやってます。基本的にはエンジニアという立ち位置でやっています。
ぎょり: 本当にスペシャリスト感溢れますねすごい。
末村: でも、テスト自動化そのものに携わっているのってここ2年くらいなので、2年でスペシャリストを名乗っていいんだっけ、ていう気持ちはちょっとあります（笑
ぎょり: 名乗っていきましょう！
末村: はい、名乗ります。
ぎょり: ありがとうございます。
じゃあ、今日は話題になってます、リグレッションテストは何でそもそもしないといけないんだっけっていうところ。
結構やっぱ必要だよねって言われるのはもちろんなんですけど、なんでそもそも本当に必要だったんだっけっていう根本にかえることはあんまりないかなと思っていて、この辺りを末村さんから聞けるとすごく嬉しいです。
末村: みんな結構「リグレッションテスト」っていう言葉自体は知っていたり、あるいはリグレッションテストは絶対やっぱり必要で、やらないとなんかバグが出るけれど、それの動機が「なんかちょっと不安だからやる」みたいな感じになっちゃってるところってやっぱり多いと思います。
ぎょり: はい、多いと思います
末村: リグレッションテストそのものが、出来上がったシステムに対して、ぽちぽちしていくっていうことをリグレッションテストとみなしている方もちょいちょいいらっしゃったりして。なので、そこら辺の誤解を軽くといていきたいなという風に思っています。
「リグレッション」っていう言葉自体なんですけど、これは、英語で「回帰」といわれるやつですね。「先祖返り」みたいな言い方をすることもあったりするんですけど。
つまり、元々出来ていたことができなくなっちゃうっていうことを確認するテストです。
例えばなんですけど、システム側で何か修正をした結果、ある部分の修正が別のところに影響して、システムがうまく動かなくなっちゃった、というのを防ぐためのテストです。
リグレッションテストはなぜ必要かって言うと、もう平たく言うと、リグレッションするからなんですけど。
システムってどんどんどんどん複雑になってきていて、昔からWEBの世界にユーザーとして触れていた人は結構分かると思うんですけど、例えば、90年代のインターネット始まったみたいな時のWEBに比べたら、もうびっくりするくらい複雑になっているし。
アーキテクチャ自体が、昔の素朴なWEBの時代からは完全に変わっちゃっていて。昔はHTMLだけで完結していた世界が、JavaScriptだったりCSSだったり、非同期での通信だったり、ブラウザ自体にいろんなデータが入っていたり。すごくいろいろ変わってます。
あと、一番大きいのは、いろんなシステムが繋がるようになったからですね。
リグレッションテストの中でも、特にAutifyが今やっているのってE2Eテスト、他の言い方をすると「システムテスト」とも呼ばれるところなんですが、システムが全部出来上がった段階でやるテストのところを自動化してるんです。
システムが全部出来上がるまで、個別のコンポーネントではちゃんと動いていたんだけど、くっつけてみるとうまく動かない。
あれですね、”プロジェクトX の東京タワー建設” みたいな。鉄骨が設計とずれていたので、組み上げてみたらうまく組めなくなっちゃったみたいな話があって。
あぁ、これはシステムの話だなぁという気持ちで見てたんですが… (笑
エンジニアがよくユニットテストとかは自動化したりしてるんですけど。個別の関数のレベルではちゃんと動いているはずなのに、システム全体をくっつけたタイミングでうまく動かない。あるいは外部システムのインターフェースが変わっちゃっていて、うまく動いていない、とかはよくあります。
あと、オープンソースを使っているところも多いと思うので、オープンソースの開発サイクルって自分たちの開発の流れとは違うところでうごいているじゃないですか。例えば、オープンソースの脆弱性があったからバージョンをあげないといけなくて、バージョンをあげたら、なんか知らんけど破壊的な変更が入っていて、インターフェースがガラッと変わっていて、システムがうまく動いていない、っていうことはやっぱり起こります。
なので、リグレッションテストはやらないといけないよね、どこに影響があるかわからないからね、というのでリグレッションテストはどうして必要なのか、っていう説明になります。
自分たちが想像していない箇所まで影響しているってことですね。複雑さが増せば増すほど。把握しきれていない、みたいな感じなのかな？
末村: そうですね。
もう1つは、把握できないということとは別に、テスタビリティの問題があるんですね。テスタビリティとは何かと言うと、純粋に「テストのしやすさ」のことをいうんですが。
E2Eテストの自動化ってすごく難易度が高いと言われています。どうして難易度が高いかというと、E2Eテスト自体がテスタビリティが低いからなんです。
テスタビリティが低いというのはどういうことかと言うと、例えばなんですけど、ある部分をテストしたい時に、その他の部分も含めて触っていかないといけない。要は、一連のフローとしてテストをしないといけないので、特定の箇所までたどり着くまでに操作がすごくたくさん必要になる、というところが1つ理由として挙げられます。
リグレッションテスト、別に自動化してなくても手動でやってる人たくさんいらっしゃると思います。それは、テストしないでリリースするの恐いから、当然自動化ができてなかったら誰か手動でやってると思うんですけど。
一部、例えばE2Eテストを自動化しましたって言う時に、大体のところは、自動化しやすいからやっていくんですよ。例えばですけど、デッドリンクみつけたりみたいなレベルなんですが、いわゆるスモークテストといわれるような、すごく簡単なフローを先にさらっと流して、そこにバグがあるかを確認するとかをやってたりします。
僕、前職にいたときに、テストの自動化をオープンソースのライブラリとか使って、やってたんですけど。
そのときも、一番テストしやすいところだけ、実装しやすいところだけ、自動化を進めた結果、自動化自体はできたんですけど、8ヶ月ぐらい自動テストをまわし続けて、バグが見つかったのって1回だけなんですよ。
決して、我々のチームがバグを出していなかったわけではないですよ。
バグは別のところにあった。
ここで、テスタビリティの話に戻りますけど、テストしやすい所って、手動でも自動でもテストしやすいんですよ。なので、みんな開発者もテスターもそこは見るんですよ。見なかったところにバグがあるんですよ。
例えばなんですけど、AmazonみたいなECサイトを想像してみるとして、一番バグが出やすい所って、何か統計があるわけではなくて完全に肌感で言ってるんですけど、商品を注文して、注文内容を変更するとか、注文をキャンセルするとか、フローの中の深いほうにバグがあることが多いんですね。
逆に、再現するのに時間がかかって面倒くさくってはエンジニアが見たがらないみたいなところ、僕達テスターってそういうところ頑張って見に行ったりするんですけど、
何が言いたいかと言うと、見やすい所はみんな見てるから、見づらいところを自動化すべきなんだけど、テスタビリティの低いところ、つまりテスト自体のパスが長かったり。
リグレッションテストってみんなやってると思うんですけど、結構それを自動化することによって効果を得るっていうのが難しくって。
その前に、リグレッションテストをなぜ自動化する必要があるのかっていうところの話をします。なんでリグレッションテストを自動化するのかというと、リグレッションテストって、性質上、繰り返し行うものだからなんですよ。
考えてみれば当たり前なんですけど、今まで出来てた事が、今もできていることを保証する性質のものなので。
要は、今日のリリースでちゃんと動いてることを確認できたとしても、明日のリリースでそれを確認しなくてもいいってことには多分ならないじゃないですか。よっぽど影響範囲が分かりきってるみたいなことでなければ、基本的には、最初にちょっと話した「不安だから」みたいなところに若干繋がってはくるんですけど、全部確認しないと。繰り返しになるんですが、影響範囲が分かってるんだったら別です。影響範囲もわかっていないし、影響がコントロールできない、みたいな時には、絶対、結局リグレッションテストはやらなきゃいけないから、繰り返しやる必要がある。ただ、繰り返しやるにはあまりにも重すぎる。
ぎょり: あと、やりたくない。
末村:
「やりたくないんですよ、テスト！」
ぎょり: 同じやつ、何回も何回もは本当にやりたくないです。
末村: そうなんですよ、本当に気が狂うので、できればやりたくないので、自動化したいんです。でも、自動化するにはあらゆる面でハードルが高い。
それは、例えばなんですけど、ブラウザの自動化の技術だったりみたいなのを学習するコストが高い。
ぎょり: ブラウザの自動化って何ですか？
末村: テストの自動化っていうよりは、ブラウザそのものを自動で動かして、その結果を確認するっていうような感じになるので。ブラウザオートメーション自体が結構闇なんですよ。
ぼく昔、「クロスブラウザテストの闇と闇と闇」っていうタイトルでビズリーチさんのイベントに登壇させていただいたことがあって。
Seleniumっていう、ブラウザの操作を同じインターフェースで行うことができるようにするためにの、すごく有名なオープンソースのライブラリがあって。たぶんこれを聞いてる方はみんなご存知だと思いますけど。
各ブラウザを、同じAPIで動かせますよっていうのは、必ずしも同じよう動くとは限らない、っていう闇があって。
ちょっとあまり話すとこれは闇なので長くなっちゃうのですが。。。
ぎょり: これはまた別のターンでやりましょう、すごい聞きたいです。
末村: そうですね。
ブラウザの自動操作っていう技術1つをとってもすごく重いし、かつ普通にWeb開発やる分にはほぼ使わないような技術なので、どんどん沼にはまっていくのが大変みたいなところもあったりして。結局そのリグレッションテストの中でも特にE2Eでやるところはすごく重いです。
リグレッションテストは、自動化しないと手動でテストするのはあまりに辛いんだけど、自動化するのもあまりにも辛い。
なので、みんな、こう思うんですよ。
リグレッションテストの項目が100個あります。その内の30個はそんなに自動化が難しいところじゃない、そこだけをやろう、そしたら手作業は70%まで減る。30%じゃなくて50%かもしれないし、70％かもしれない。バグが出るのって、例えば、30%自動化したら、残りの70%のところなんですよ。
言ってみて思ったんですけど、パーセントがイマイチだったのであれなんですけど…
例えば、60%、6割自動化できました、残りの4割のところを手動でやりましょう、みたいな感じでやったときに、バグが出るのって6割のところじゃなくて、4割のところなんですよ。
なんでかっていうと、自動化しにくいところは手動でも当然テストをしづらい所なんですよ。
テスタビリティが低い、っていうふうに僕はよく言ってるんですけど。
テストをしやすいところ、自動化しやすいような、例えば、テストデータを作るのも簡単だし、テストのための下準備みたいなのがいるケースといらないケースとがあると思うんですけど。
例えばなんですが、ログインのテストは簡単だけど、ユーザーの新規の登録のテストは難しいみたいな話なんですよね。
メールを確認して、コンファメーション、検証のURLにアクセスしてみたいな、いろんな手順を踏まないといけないので。なんですが、バグが出るのってそっちの方なんですよ。なんでかっていうと、開発者が開発のときに面倒くさがってそこのテストをやらないからです。
ぎょり: ユニットテストの時点でってことですか？
末村: ユニットテストレベルのテスタビリティはちゃんとできてると思うんです。
E2Eテストのテスタビリティって担保するの、すごく難しくって。
なんでかっていうとE2Eテストって、ユーザーの操作をそのまんまやるところになるので。ユーザーの操作にテスタビリティとか求めちゃいけないと思うんですよね。ユーザーは別にテストしたいわけじゃないですから。
そこは、もうUXとかの世界じゃないですか。
なので、そもそもテスタビリティというものを持ち込むようなところではないんですけど、結局テスタビリティの高いところ、低いところが出てきちゃって。
それはさっきも言った、テストデータを作ったりとかの前準備だったり、テスト自体がいろんなコンポーネントが関わっていたり。
さっき言った、ユーザーの新規登録でメールが必要になるとか。決済が必要で、決済の画面を通してサンプルのクレジットカードを入力したり、みたいな、っていうのが結構いろいろ必要になってきちゃうので。
最初に戻っちゃうんですが、E2Eテストのテスタビリティが低い所っていうのは自動化もしにくい、手動テストをやるのも大変、故に誰もテストしないのでバグが出る、みたいなケースがやっぱりあるんですよ。
もちろん、ちゃんとQAのフローを回してる会社だったりチームだったりってのは、ちゃんと当たり前なんですけどあって、誰もテストしてなかったとしても最後の最後でQAチームだったり、テストチーム的な所があって、そこがちゃんと最後にケツ持ってるので安心、みたいな感じにはなるんですけど。
気持ちとしては自動化をしていきたいじゃないですか。
ぎょり: そうですね。自動でチェックしてくれるならそれが一番いい。
末村: そうなんですよ。なぜならリグレッションテストを手動でやりたくないからなんです。
ぎょり: 全部、そこにかえってきますね 。
末村: そうなんですよ。仕事するなら楽しいほうがいいじゃないですか。
頭を使って、「ここにバグがありそうだ」と思って探したバグがやっぱり一番愛おしいので。
手順通りにやっていって、「あ、ここバグがありました」っていうのは結構辛いんですよね。
しかも、リグレッションテストってそんなにバグが出るところじゃないんですよ。
もちろんバグは出ます。出るし、結構クリティカルなものが出ます。出るときは。だからやらないといけないんだけど。
打率で言うのもおかしいと思うんですけど、エンジニアもそんなバグ出そうと思って作ってるわけじゃないと思うんで、20回やって1回出るかどうかみたいな世界だと、僕みたいな飽きっぽいやつだとそこがしんどくって。
ぎょり: あと、ペイしないですよね。それように開発メンバーとかが時間を割くと思うと。
末村: そうなんですよ。
なので、E2Eのリグレッションテストを自動化するっていうときに、テスタビリティの低いところもうまくやっていけるっていうのを個人的にはすごく考えていきたいんですよ。
それがさっき言ったメールのテストみたいなところだったり、テストデータの作成に時間が必要だったり。
さっきちょっと言いましたが、決済が発生するみたいなところとか、決済したあとにキャンセルするとか。すごく、長い長い長い長いフローが入るところをうまくやっていくっていうところに必要かと思っていて。
いろんな、テスタビリティの低いところがあったり、実装難易度が高いところがあったりするんですが、Autify自体は、今のところ、テストシナリオ自体のメンテナンス性を高めていくっていうところと、クロスブラウザでの実装というのがやっぱり難しいので、そこをうまくやっていく、Autifyを使ってテストがしやすいようにしていく。
テストの難しいところは、Autifyが先にやっておくので、テストシナリオ自体を工夫して、テスタビリティの低いところも、なるべく苦しみがなく、テストをしていけるっていうのを目指していきたいなという風に思っています。
ぎょり: すごくわかりやすかったです。今日出てきたキーワードの派生版でいろいろやりたいなってすごく思いました。
特に ”テスタビリティを高くしていくためには” みたいなところとかは、どこの会社でも開発者でも悩むところかなと思うので。
末村: テスタビリティが低いところも、テストしていくっていうアプローチが1つと、テスタビリティを高めていくっていうアプローチが1つあって、どっちも品質保証の仕事の一つなので、テストだけが品質保証じゃないんだなあという感じです。
ぎょり: 確かに。ありがとうございます。
今回のポッドキャストとしてはこの辺りで一度バイバイっていう感じにしつつ、また継続していろいろお話聞けたら嬉しいなと思います。
ぜひ、Twitter “Autify Japan” で検索して頂いて、「こういう話聞きたい」とかいう声も頂けると嬉しいですね。
末村: みんな、どしどしメンションしてね。
ありがとうございました。
.jpg)
.jpg)
