Autify Podcast : テスト自動化エンジニアに求められるスキルセットとは
Autify Podcast、エピソードを追加しました
ソフトウェアテスト、スタートアップなどにフォーカスしてさまざまなTipsや、事例などをお伝えするラジオ番組、Autify Podcastを公開しています。
今回は、note、cakesといったサービスを提供する、株式会社ピースオブケイクのテスト自動化エンジニア、増原さんをゲストにお迎えし、ソフトウェアテストにまつわる様々なお話を前後編でお伝えします。Autifyのテスト自動化スペシャリスト末村とのトークをお楽しみください。
本ブログ記事は前編の内容です。ぜひご覧ください。
ご意見、感想はTwitterでメンションしてください。
https://twitter.com/AutifyJapan
ここからは書き起こし記事です
末村:こんにちは。Autifyのテスト自動化スペシャリストの末村です。 今回もAutifyPodcastやっていこうと思います。
第2回となる今回は、僕の友人のピースオブケイクという会社にいる、QAの増原さんを今ここにお招きしているので、なんかいろんなことについて話していこうと思います。
増原: はい、よろしくお願いします。
末村: よろしくお願いします。すみません、増原さん。ざっくりでいいんで自己紹介をお願いしてもいいでしょうか。
増原: はい、増原と申します。今、ピースオブケイクという会社でテスト自動化エンジニアという肩書で仕事をしています。 今ピースオブケイクはキャリアの中では3社目で、前の2社でもQAっていう肩書で仕事をしていたんで、今回こういう場所にお呼ばれして、「ちょっと話してよ」と言われたので、頑張って話していこうと思います。よろしくお願いします。
末村: ありがとうございます。頑張ってください。
増原: ピースオブケイクって会社名知らない人も多いかも知れないので紹介しておくと、今、プロダクト的には大きくいうと(note)[https://note.com/]とcakesっていうのがあって、noteっていうのが今割と伸びているサービスなのかなと思います。 僕がメインで担当しているのがnoteです。自動化の導入推進、運用保守みたいのがメインですね。 はい、さらっとサービス紹介。
末村: ありがとうございます。僕、増原さんと長くもなく短くもないぐらいの付き合いを送っていると思うんですが。全然仕事の話をする機会がなくって。 なんか、増原さんが何をやっているのかが全然分かってないのですけど。
増原: でも、今の会社入ってからはPCブラウザとモバイルアプリの、エンドツーエンド(以下、「E2E」)テストの導入っていうところを、ずっとやってますね。基本的には。
末村: 増原さんは、Autifyによく似たツールを使っているっていうふうに聞いたことがあるんですけど(笑)
増原: そう。PCブラウザのE2Eテストでは入れたりしていますね、はい。
末村: ありがとうございます。 どうですかぶっちゃけ。何か、使い心地というか。今までの会社って、他のテスト自動化ツールを使ってたりするんですか。
増原 :一応、主要なページをpuppeteerを使って順に開いてみたいなのは、一応あったらしいんですけど、それ僕が入る前ですけどね、今の会社。 なんですけど、どこかのタイミングで動かなくなっちゃって放置っていう感じでしたね。
末村: なるほど。今は増原さんメインでやってらっしゃるんだとと思うんですけど。増原さんがバスにひかれた場合、誰もメンテできない？
増原: 一応、何人かエンジニアに計4回ぐらいのワークショップみたいのをやって、割と最近はデプロイで落ちたときとかも気に掛けてくれるようになってますけど、メインは僕ですね。あんまり変わってないです。
末村: なるほどですね、ありがとうございます。 ちなみにすごい余談なんですが、僕、前職でCodeceptJSというライブラリを使って、Seleniumのラッパーなんですけど、自動化やってたんですけど。3ヶ月ぐらい前に前職の同僚と飲んだら「末村さん助けてよ、もう動かなくなっちゃったんだよ」って。悲しい気持ちになりました(笑)
増原: そうですね(笑) そこはずっと、ちょうど昨日上司と、上司といっても、CTOの今さんなんですけど。今さんとの1on1で、いかにメンテを皆でやるかみたいなところは。 ワークショップとかやってるけど、皆マストというか、それやることが目標となってる訳じゃないから難しいよね、みたいな話が出てきて。個人的にはすごい使いやすいツールだと思いますけど、それでも広めるのは難しいと思う昨今です。
末村: やっぱりテストは、QAの仕事みたいになっちゃってるんですかね。
増原: いや、そこに関して話す場が。もっと話した方がいいと思うんですけど。そういうのは特にやってこなかったので。僕、皆メンテできた方がいいって思ってるの僕だけかもしれないし、皆で品質向上とか。何だろう…。QA的な活動とかは、QAエンジニアだけでは結構難しいよねって僕は思ってるんですけど、他の人はどうでしょうねって感じ。
末村: 難しいんですよね。壁がある訳ではないはずなんだけど、壁があるような気がしてしまって。
増原: そう。先週でした、今週だったっけ。”JaSS○(ジャスマル)” イベントで。 似たようなトピックがたぶんあったと思うんですよね。いかに開発メンバーを巻き込むかというところで。 開発メンバーに、テストに関わることへのメリットみたいな、関わってよかったっていう体験がないと、引き込むのは結構難しい感じはしてますね。 僕の中では上手く使うと、ちゃんとその仕組みである程度動くってことが担保できて、デプロイできると思うんで。 それは開発者にとっても自信持てるし。テストが、開発者がむきにはなると思うんですけど。それは僕が思っているだけなんで。そこに共感を持ってくれるかどうかは、ちょっと別な話ですけどね。
末村: そうですね。なんかちょっと思うのは、開発者のやっている仕事というか、普段触っているとこって自分のローカルマシンな訳じゃないですか。 そこに対してテストが動いていないと、そもそも開発プロセスの中にそれがあるっていうふうに分かってはいるんだけど、何か肌感としてそういうふうに捉えられていないから、放置しがちみたいな感じ。
増原: 単純にこう、何だろうな。触るの怖いみたいな。 だったりするかもしれないなと思ったるするのもあって。テストを自分、QAだけのものにしないようにと思って、そういうことやってるんで、どんどん皆、落ちたところを見に来て欲しいなって。
末村: 本当そうですよね。
増原: またちょっと話がずれましたけど。 だから僕も、何だろう。テストが、開発者に広まらないなっていうのは、僕の今見えてる世界でそう思っているだけだから、僕がもっと、開発者が日々どういうふうに開発していって、どこにテストとかのやりづらさみたいなのがあるとか、この辺をちょっと観察しないとなと思って。今週からちょっとしたバックログ、プロダクションフォローの修正、言ってもちょっとリンク書き換えるとか、そういうのをちょっとやり始めたんですよ。 なので、そういうアプローチに変えています。僕がもうちょっと開発を知らなければいけないのでは。
末村: 確かにね。さっき”JaSS○(ジャスマル)” の話であったんですけど「開発者がユニットテストを書いてくれないんだけど、どうすればいいですか」っていう話があって。 山口 鉄平さんという方が「逆になぜユニットテストをあなたが書かないんですか」みたいな話をされてて。「エンジニアが書かないのもQAが書かないのも同じだよね、誰も書いてないっていう話なんだから。」みたいな話だったと思うんですけど。 お互いの領域に歩み寄っていくっていうところも、最終的にはすごく必要なんだろうなっていうのを、それを聞いてて思って。 脱線しちゃうんですけど、僕今、一応ソフトウェアエンジニアとして、肩書からエンジニアって実はなくなっちゃったんですけど、一応エンジニアとして働いていて。 今までテスターとかQAとかみたいなロールでやってたところを、エンジニアっていうふうに切り替えた瞬間に、周りのエンジニアとのお話っていうのが、昔が少なかった訳ではないんだけど、今やっぱりすごく多くて。 特に、隣に座っているフロントエンドエンジニアからの学びがかなり多いんですね。そうやってそこをテストにも転用していける、テスト自動化とかにも転用していけるっていうようなところで、個人的にはやっぱり越境したことに対するいろいろやっぱり学びが深いので。
増原: そうですね。デプロイ手順とかも実は知らなかったりしたので。僕デプロイしたことがなかったから、今週まで。 なので、こういうふうにChatOpsしてやるんですけど、そもそもデプロイする権限がなくて怒られてみたいな、まずはそこからみたいな、だったりしました。 それを他のエンジニアに聞いて、ああそうなんですねみたいな。
末村: 分かります。デプロイは、ロールに関わらず1回やっといた方がいいみたいなのは前職の肌感でもある。ありがとうございました。
ちょっと次のテーマで、「テスト自動化エンジニアに求められるスキルセットは」っていうテーマを、実は用意してきたんですけど。 増原さんどうですか。今Seleniumとかを使って、自分で実装していっている訳ではなく。
増原: そうですね。前職ではメンテしたりしてましたけど。Selenium WebDriverでRspecで書いたり、ちょっとWebDriverにトライして一部だけ自動化回すようにしたりとかはありましたけど。今はツールを使ってメンテするみたいな感じですね。
末村: 結構変わります？物の見え方じゃないですけど。
増原: うん…変わる。何だろうな。 そこはツールの話になるかもしんないけど、割とシナリオを絞っているので、安定して割と動いていますと。いうとこなので、そこまでデプロイの時にビクビクするようなことはなくなったかな。それよりも、ツールを入れたからか分かんないけど、割と考えることが多いのかもしれないですね。なんでメンテに人を巻き込めないんだろうとか。
末村: 今、シナリオを絞っているっていう話がありましたけど、シナリオを絞ったりっていうところって、どういうスキルがいると思います？
増原: 僕は前職で、そのE2Eのメンテをしていた経験があるし、サービス的なドメイン知識でいうと、一番最初に入った会社のサービスが、今のnoteと似たようなブログサービスだったりしたので、そういうドメイン知識とかを元に、こういうところがデプロイとかで転けていると、「これは障害報告もんや」っていうところで。 割と僕の独断と偏見で厳選されたシナリオで運用されております。なので、本当は何をテストすべきかっていうのを、もうちょっと他の人のフィードバックが欲しいなとは思ったりはしています。
末村: なるほどですね。その独断と偏見でっていうのは、ドメイン知識を使って、前に増原さんが”ハッピーパス”っていう言葉を使っていたのをすごい覚えているんですけど。ハッピーパスだったりアンクリティカルパスだったりみたいなところを厳選して、ここはE2Eでも間違いなく担保しないとやばいところだよっていうところを、ツールにのせていくっていうような。
増原: そうですね。
末村: 僕もそこがすごく大事だと思うんですけど。 逆に何か、それでちょっと自信がないなっていう気持ちもすごく分かります。 その自信のなさは、どういうスキルを身につければ。あるいはどういうスキルセットを持った人が来てくれると?
増原: 難しいこと聞きますね。
末村: 例えば、テスト分析みたいな、QAマネジメントみたいな部分の、あるいは何だろう。ちょっと言葉が正確か分かんないんですけど、テスト設計みたいなところの話がやっぱり重要になってくるっていうことなんですかね。
増原: もちろんそうですね。
末村: 実は僕、そういうスキルを持った人と一緒に働いたことがなくて。増原さんはそういう方がいらっしゃったことはあります？
増原: いや…。でも、前職で第三者検証の人が入ったときに、まず分析からやりつつ、みたいな方がいらっしゃったんで、そういうのでやっていくところを見て、「ほーっ」て。こんな感じでやるんだみたいな。
末村: なるほど。今そういう人にいてほしい？
増原: そうですね、いてもいいと思いますね。
末村: 何か、微妙に言いよどんでいる感じがあるんですけど。
増原: 今、大してシナリオの量とかあるわけではないんで。レベルを各エンジニアに見てもらうだけでも、僕は結構価値があると思うんですけど。 そういうフィードバックを求めるにはどうすればいいかなって思ったりして。
末村: なるほどですね。 ちょっと話戻っちゃうんですけど。今、昔テスト自動化を進めようと思ったときに必須だったWebDriverだったり、あるいは、その他のブラウザオートメーションの技術っていうのはもう、QAエンジニアには必要ないパターンが出てきているじゃないですか。増原さん自身でも。
増原: うーん…でもトラブルシュートとかする時には、その辺の考え方がないと難しいかなって思ったりするけど。
末村: やっぱりツールを使うにしても、その裏で動いている技術に対する理解は必要？
増原: 必要だと思います。
末村: なるほど。
増原: あと、開発関連のツール、何かしらを使って。必要だと思うけどな。Jenkins使ったことありますっていうだけでも結構(笑) Jenkins使ってSeleniumのテストとかしたことありますっていう、そこまでやったことありますっていう人だったら割とそういうツールでも問題なく任せるし、何ならトラブルシュートも任せそうだなっていうイメージがありますけどね。
末村: なるほど。アプリケーション開発の技術って必須ですか。
増原: あった方が。あればいいに越したことはない(笑)
末村: それはもう、全てのスキルがあった方があるに越したことはない(笑)
増原: そうですね。QA、テスト自動化の人でいうと、どういう現場かにもよるんだけどな…。 実行環境の構築、テストコードの知見かがあると頼もしいのでは(笑) なぜかというと、実際運用する現場に入ると、テスト落ちましたっていうのに対処する時間って結構多いと思うので。
末村: そうですね。それは本当にそう思います。そうなんですよ。やっぱり、E2Eテストを作るの自体は簡単だけど、運用が一番難しいなっていうか。
増原: 作るのも大変ですよ。(笑)
末村: そうですね。(笑) 僕の肌感としては、作るのは結構。特に比較的作るのが簡単な部分であれば、作るの自体はすごく楽なんですよ。で、作ったはいいけど、それがある日動かなくなってしまったときに、それを。ほら、E2Eテストって開発の終わりの頃に実行するから、リリースまであと2時間ぐらいしかないんだけれどテストが落ちてて、それがテストが駄目で落ちてるのかアプリが駄目で落ちてるのかが分かんないから、人力で追証しないといけないから。 みたいなことになるので、やっぱりそこがつらいよねっていう。
増原: それは大事ですね。
末村: なのでやっぱり、頻繁に回すための運用構築どうするかみたいな話とか、そういうところが個人的には結構大事かなって。 スーパーマンが来てくれると、全てを任せられるので。これは、テスト自動化についての話なんですけど。 今おっしゃっているように、アプリ開発の知識もあれば嬉しい、Jenkinsも動かしてくれると嬉しい、テストの設計とか実行とかの知識だったり経験だったりもあれば嬉しい、自動化の経験もあったら嬉しい。 ナイストゥーハブを全て持っているスーパーマンが来てくれると最高なんですけど。
増原: 見たことないですね(笑)
末村: そう、実際には見たことないですか。じゃあ、何が少なくとも一番大事かみたいな、マインド的な部分も含めて、そこ結構悩ましくって。 例えば今、QAだったりテスト自動化エンジニアの求人を打ちましょうっていうときに、どこを一番マストにするのかっていう、すごい難しいなって思ってて。
増原: 確かに。うちまだ募集してないですけどね。もし募集出すとしたら、難しいっすね、何だろう。でも、自動テストの運用経験とかになるのかな。
末村: それは、ツール、というか、割とリッチなツールを使ってっていうことですか。
増原: 何でもいいんじゃないですかね。(笑) 長く運用してたってことは、いろんなトラブルを見ているはずなので。
末村: 確かにね、苦しいところですよね。
増原: そこを何とか運用し続けたっていうのは、価値があるんじゃないですかね。
末村: じゃあ、必須経験として「苦しみ」を入れる(笑)
増原: 苦しまなくたっていい(笑)
末村: 苦しんだけど楽しかったみたいな、マゾいやつ。 ちょっと話変わるんですが、さっき第三者検証の話ちらっと出てましたけど、今、増原さんお1人でやられてるじゃないですか。
増原: そうですね。
末村: アウトソースを入れたいとかってのは、今は思わないんですか。
増原: 今は、うちはリリース速度を重視してるっていうのはあって、今今はQAフェーズとかって、いわゆるQAフェーズみたいなのって、開発者自身が動作確認して、できたらデプロイみたいな感じなんですよね。 それで、今今、その各プロダクトラインにテスターさんみたいのを入れて、そこがどうだろう。どれぐらいその人たちが頑張れるかにもよるんですけど。あまりそこでスピード上がるかな、スピードどうするかみたいな、どこをもってスピードとするかとかちょっと全然決めたりしてないんですけど、あんまりそこはイメージがなくて。今今アウトソースの会社入れたりっていうのは考えてないですね。 というのは、どういう感じでやるかはさておき、僕の過去2社での経験でいうと、第三者検証会社入れると第三者検証会社の人のケアのために結構時間を取られるので。
末村: ケアっていうのは、いつ？
増原: どういう握りとかどういう流れでテストするかにもよると思うんですけど。いついつテスト開始予定ですって、某社さんに伝えて。 「らしいですよ」ってPMから聞いたことを第三者検証の人に伝えるみたいな。 その間のプロダクトオーナーと第三者検証の方のコミュニケーションの間に入る人みたいになっちゃうことが、結構つらくて(笑)
末村: なるほど。ちなみになんですけど、増原さんが今まで第三者検証の方と関わったのって、どういう契約形態でした？ 僕、実は全然関わったことがないんですけど。たぶん派遣で常駐のパターンだったりとか、いわゆるラボ型だったりとか、いろいろあったと思うんですが。
増原: 基本は常駐ですね。
末村: それはテスト、いわゆる、3月1日から3月末までテストフェーズだよっていうのを決めて、そこに入ってもらっている？
増原: もあるし、もうちょっとリリースサイクル短かったら、もうちょっと細かく調整して、来週1週間とか。 「それまでに開発終わっといてくださいね」って言ったら、「全然開発終わってません、無理です」って金曜ぐらいに言われる、どうしようみたいな。 経験無いですか、聴いてる皆さん？(笑)
末村: テスターとしてそこに当たった経験は頻繁にあります。 「リリース期限◯日だね、じゃあ◯日前に終わらせとこうね。お、リリース期限今日だ、けどまだあがってきてないぞ。お、プルリク出てるぞ。まだテストしていいって言われてないけどやるか！」みたいなパターンは何度かありますね。
増原: あとは、第三者検証の人をまとめる人だけ社内にいて、実行自体はリモート、とかもありましたね。
末村: リリースサイクルが早い環境にそういう契約形態を持ち込むと、死ぬのは自分な感じなんですかね。
増原: どういう話し合いとかにもよると思うんですけど、やっぱQAリソースをアウトソースする最大のメリットは、中で人を増やさずにQAリソースをスケールさせることなんで、そこはすごいいいと思うんですよ。 例えば、サイバーとかでもQAチームを最初作ったときとかは、社員3、4人とかしかいなくて。ソシャゲの新しいリリース全部QAしなきゃみたいなの、難しかったんで。 そこで第三者検証さんにお願いして、スケジュール調整しつつ、その決めた期間でやってもらうみたいな。そういうことでスケールできたっていうのはあったんで。 そこはメリットとしてはあると思いますが。その会社のリリースサイクルとかにもよる気がしますけどね。
末村: なるほど。でも、第三者検証のほうもすごく、何でしょう。そこのやり方を変えたいと思っていそうな感じがありませんか。何て言ったらいいか。 ちょっと微妙に話しずれちゃうかもしれないんですが、僕、ソフトウェアエンジニアになる前って、物流業界にいたんですよ。物流っていうと最初に何かこう、Amazonのきれいな倉庫とか想像しちゃうんですけど、あんな感じじゃなくて。田んぼの真ん中に突然倉庫が出てきたみたいなレベルの。 さておき、やっぱり人手が必要な仕事だったので、かつやっぱり繁忙期・閑散期あるんですよ。そこでどうやってスケールさせるかっていうのがすごく問題で、やっぱりそこに登場するのって派遣なんですよね。 “派遣でスケールさせるように遣う”っていうような感じになるんですけど、すごく教育のコストが掛かったり、派遣で来るは来るけど、やる仕事って毎回変わっていくから、行く先々でその派遣さんっていうのは、そこの会社の業務についてキャッチアップしないといけないみたいな感じ。
増原: それはそうでしょうね。エンジニアとかでも一緒。
末村: そうなんですよ。エンジニアもそうだし、特に客先常駐みたいな形とか、今話に出てきてた第三者検証みたいなところもそういう感じだと思うんですよね、すごく。 そこにさらにリリースサイクルみたいな。たぶん今までからすると高度な要件が入ってきて、じゃあどうしたらええねん、契約の絡みもある。 でも、我々のビジネスモデルはこれだよっていうのは、すごい難しいだろうなっていうふうに思ってるんですよ。 実際にお願いする側だった増原さん的には、その辺ってどういうイメージだったんですか。
増原: 前の会社とかでは、最後、僕が間に入らないように、プロダクトチームと何ならその第三者検証会社さんで進めてもらえれば基本大丈夫だと思うんで。スケジュールだけちゃんと、プロダクトの方に前々から、いつテスト開始するかをコミュニケーションだけ密に取ってもらえれば基本大丈夫なはずなんでっていう気持ちでやったりしてましたね。僕がボトルネックになりそうだったんで。
末村: やっぱりこう、直接話すみたいな感じになるんですね。
増原: その方が早いですね。僕にまずslackで相談されて、「うーん、なるほど」って言って、で結局それそのままPMにリダイレクトするだけなんで、「それ直で言ってくださいよ」って。 でも、たぶん、契約上は僕が監督することになってるんでしょうね。詳しく契約書は見てないですけど。
末村: ああ(笑) 何かちょっと闇っぽい話になってきそうなんで。
増原: なので、僕が駄目なことをしようとしていたんでしょうね。
末村: すごく盛り上がってしまっているのであれなんですが、ここら辺で一度、前半戦を終了したいと思います。後半また続きますので、お楽しみに。
ありがとうございました。
Autifyではこの他にも品質保証やテスト、アジャイル開発に役立つ資料を無料で公開していますので、ぜひこちらからご覧ください。
.jpg)
.jpg)
