2019-05-01

DevOps時代のテストエンジニア採用面接

DevOps

背景

　社内外のテスト自動化チームの人たちと話すと、テスト自動化エンジニアの採用は難しいという話題がよく出る。どこのチームもテスト設計が出来て、自動化も得意で、CI周りの構築もやって、といったパーフェクトなテスト自動化エンジニアを求めているが、実際には採用はなかなか進んでいないようだ。

　このブログポストでは、このテスト自動化エンジニアの採用にまつわる問題を「候補者の得意領域、不得意領域の話を引き出す面接を意識すること」を軸に少し一般化し、僕自身が気をつけていることについて書く。

テスト自動化エンジニアの採用が大変な理由

多岐に渡るテスト自動化のスキルセット

　テスト自動化エンジニアの採用が大変な理由は、一言で言えば、DevOpsが当たり前の昨今では、多岐に渡るスキルセットを評価する必要があることだ。

　例えば、ソフトウェアテストの資格試験であるISTQBでは、ソフトウェアテストの「Core」のスキルとしてテストマネージメント、テストプロセス、テスト技法、ソフトウェア品質特性などを挙げられている。また、「Specialist」のパスとしてアジャイルテストやテスト自動化エンジニアが示されている。

　これらに加え、XPやTDD、継続的デリバリーなどにみるアジャイルでのテスト自動化への考え方、Jenkinsなどのパイプライン自動化、DockerやKubernetesなどのインフラ自動化なども周辺技術としてある。

採用面接におけるありがちな罠

　はっきり言ってしまえば、これらの多岐に渡るスキルや知識を評価することは想像以上に難しい。候補者の得意・不得意なスキル領域について客観的な評価ができなかったり、うまく話が引き出せない可能性があるからだ。下記に採用面接における例を示す。

f:id:kokotatata:20190430092937p:plain — 面接における認知バイアスの例

　この例での面接官のAさんのスキルをみてみる。スキル領域①〜⑤を通して特に苦手な領域もなく、特にスキル領域①で高いレベルを持っている。

　候補者のBさんとCさんのスキルセットをみてみる。BさんはAさんと同様のスキル領域①が得意だ。一方で、Cさんはスキル領域①は苦手だが、スキル領域③と⑤で高いレベルを持っている。

　この例の場合、Bさんの方がCさんに比べ評価されやすいと僕は考えている。認知バイアスがかかるため、Aさんは自分自身が高いレベルをもつスキル領域①を重視して評価しやすいからだ。人間は自分が努力をして手に入れたものに対して、より多くの価値を見出す傾向がある。そのため、自分自身の得意な領域と不得意な領域について、客観的な目で評価するのは難しい。

　また、面接官は自分が得意な領域について、より多く、深く質問してしまいがちだ。プログラミングについて詳しい面接官は、ついついプログラミングについての質問をしてしまう。しかし、面接は面接官の得意な領域について質問する場ではなく、候補者に得意な領域、不得意な領域について話してもらう場だ。候補者から得意、不得意な領域な話を引き出せるように面接を組み立てる必要がある。

テスト自動化エンジニアの採用で気をつけていること

スキル領域を定義する

　異なるスキル領域について客観的に評価するためには、事前にテスト自動化エンジニアに求めるスキル領域とスキルレベルを定義することが必要だ。例えば、僕個人は

テスト要求分析スキル（機能要求、品質要求含む）
テスト設計およびテスト優先順位づけスキル（テスト設計、リスクベーステストなど）
プログラミングスキル（構造体、アルゴリズム、エラーハンドリングなど）
自動テストの設計スキル（Keyword Driven Tesing, Data Driven Tesing, PageObject Patternなど）
問題解決スキル（自動テストの保守性、Flakyテストなどの問題をどのように解決するか？）

をテスト自動化エンジニアに必要なスキル領域として定義している。事前にスキル領域を定義することで、質問や評価が特定の領域に偏るリスクを軽減できる。

　また、それぞれのスキル領域の得意なチームメンバーと、質問や回答についてのレベル感について合意しておくことも重要だ。前述のように、スキルAが得意なメンバーとスキルBが得意なメンバーでは、スキルAが得意な候補者の評価が割れやすい。事前にメンバー間でレベル感について議論しておくと、スムーズに結論を導き出せる。

面接の冒頭にチームを紹介

　候補者から、得意・不得意なスキル領域の話を引き出すためには、面接の冒頭でチームを紹介することも重要だ。募集しているポジションのチームがどんなチームで、どんなスキル領域が得意なテスト自動化エンジニアに来て欲しいかを丁寧に伝える。すると、候補者は面接の質問に対し、自分のスキルセットや今までの経験について的確にアピールできるようになる。

　例えば、「開発者しかいないチームでテスト専門スキルの高いエンジニアにチームに来て欲しい」場合、それを伝えれば候補者は今までの経験の中でも、特にテスト要求分析やテスト設計の経験についてアピールしやすくなる。

　単純にテスト自動化エンジニアのポジションと言っても、そのチームは様々だ。開発エンジニアとテストエンジニアが一緒のチームもあるだろうし、独立したテストエンジニアのチームもあるだろう。Scrumでバリバリやってるというチームもあれば、ウォーターフォールでやっているチームもある。また、もう既に何十万件のテストケースを自動化したチームもあれば、これからテスト自動化を始めるチームもある。

　自分たちのチームがどんなチームで、どんなエンジニアにチームに来て欲しいかを伝えることで、候補者もそのチームに対しよりポイントをついた話をすることができるようになる。

候補者の得意なスキル領域を引き出すオープンクエスチョン

　候補者の得意なスキル領域の話を引き出すため「あなたの得意なスキル領域はどこですか？」とダイレクトに質問する方法もあるが、一般的なオープンクエスチョンから候補者の得意なスキル領域へ質問をシフトしていくのもオススメの方法だ。

　例えば、僕はしばしば「あなたが今まで経験したバグの中で一番大変だったものを教えてください」というオープンクエスチョンをする。この質問の面白いところは、「一番大変」と感じる領域が候補者によって完全に異なることだ。そして、この質問の回答に候補者があげる領域は、本人が自信のある領域である場合が多い。

　バグを発見した苦労話を聞かせてくれるエンジニアは、テスト技法について自信があるだろう。バグの根本原因を特定した苦労話を聞かせてくれるエンジニアは、インフラが得意だったりする。バグ修正の苦労話を聞かせてくれるエンジニアはプログラミングに自信があったりする。

　エンジニアは大体みんなバグで苦労をした経験がある。そのバグに対して「大変」と感じる視点の違いを、一般的なオープンクエスチョンから引き出すことができる。

スキルレベルを判断するための質問

　候補者から得意・不得意な話を引き出した後には、それぞれのスキル領域についてのスキルレベルなのかを判断する必要がある。

得意なスキル領域は実務で活用できるレベルなのか？
不得意なスキル領域も、ある程度の知識はあるのか？

「知っている」ことと「出来る」ことには大きな差があるため、この違いを見極める必要がある。

　僕がしばしば面接で実施するのは、異常系がごっそり抜け落ちている仕様に対してプログラムを書いてもらい、続けてそのプログラムのテストを実施してもらうというものだ。本来の目的は「異常系の仕様の抜け漏れを見つけてもらう」ことなのだが、そのことは候補者には隠した上で、２〜３行の正常系の仕様に対しプログラミングとテストを実施してもらう。

　プログラミング自体はシンプルなので５分程度で終わる。しかし、テスト駆動開発やエラーハンドリングなどのテクニックを使いこなすエンジニアは、ここで異常系の仕様がごっそり抜け落ちていることに気付く。また、テストの実施の最中に、境界値分析などを用いてテスト設計をすることで仕様の抜けもれに気付くケースもある。

　この問題は、こちらから特にスキル領域やテクニックの指定はしないので、候補者が普段どんなスキルを使いこなして業務を遂行しているのかを知るのに役立つ。特に、テスト駆動開発や境界値分析など名前くらいは知っているというエンジニアも多いが、そういうレベルではこの問題の仕様の抜け漏れを発見することはできない。

　稀にプログラムを書く前段階ですべての異常系の仕様の抜け漏れに気付くエンジニアもいる。そういうエンジニアは数百人に一人にしかいないので貴重な存在だ。

まとめ

　テスト自動化エンジニアの採用戦略について「候補者の得意領域、不得意領域を引き出すこと」を軸にみてきた。テスト自動化エンジニアのポジションに必要とされるスキル領域は多いため、優秀なエンジニアの採用はなかなか大変だ。しかし、チームと候補者のスキル領域がうまくマッチすると、劇的にチームが改善される可能性のある重要なポジションだ。

2018-12-17

個人の経歴2018年バージョン

講演・執筆活動

勉強会企画

書籍関連・インタビュー・ブログ記事など

「アジャイルもテスト自動化も当たり前？！ ~AIがテスト設計をする日が来るかも~ - Test Automation」(個人ブログポスト, 2018)
「特集2 "素早い"テスト実践法」（日経SYSTEMS８月号,2017）
「ITエンジニア新図鑑：テストエンジニアについてのインタビュー」（日経SYSTEMS ５月号, 2017）
「DevOps時代のテスト要求分析」（個人ブログポスト, 2016）
「DevOpsについてのインタビュー」（日経コンピュータ2016年11月10日号）
「DevOps事例提供」(エンタープライズアジャイルの可能性と実現への提言, 2016)
「Rakuten DevOps Evidence January」(2016)
「DevOpsインタビュー：第１回楽天さんのDevOpsについて聞いてみた」 (2015年)
「"グローバル化"と"コミュニケーションとアジャイルとテストエンジニア"」（Ultimate Agile Stories Iteration 5, 2015）
「アジャイルテストのテスト設計の話」（個人ブログポスト, 2015）
「継続的システムテスト」（個人ブログポスト, 2014）

資格

JSTQB Advanced Level テストアナリスト (2017)
JSTQB Advanced Level テストマネージャー (2015)
JCSQE 初級 (2014)
JSTQB Foundation Level (2014)
プロダクトオーナー(2014)

2018-12-11

JaSST'18 Tokaiが楽しかったw話

カンファレンス参加レポート講演活動

モチベーション

　このブログエントリのモチベーションは、ソフトウェアテスト#2 Advent Calendarを完走することです。今現在（2018年12/10）6つの枠が空いてるので、それぞれの空き日当日になっても空白だったら、どんどん埋めてきます。

qiita.com

JaSST' 18 Tokai

　2018/12/07 (金)に愛知県刈谷市で開催されたJaSST' 18 Tokaiに講演者として参加してきました。カンファレンスは、講演としては平鍋さんの基調講演と我々の特別講演があり、その他にもポスターセッションやチュートリアルなど盛りだくさんで、最後には参加者同士で意見交換する情報交換会もありました。

　このブログエントリでは、JaSST'18 Tokaiで楽しかったところを挙げていくことにします。

JaSST' 18 Tokaiの楽しかったところ

楽しかったところ①:オープニングスピーチの委員長

　オープニングスピーチの委員長のスピーチがエネルギーいっぱい、駄洒落いっぱいで面白かったです。いろいろ話を聞いてみると、委員長のスピーチはJaSST' Tokai名物で毎年恒例のものらしいです。

　その場のノリとアドリブで盛り上げている感じのスピーチなのですが、後で「実は、そういうスタイルのスピーチに見えるように、前日カラオケで練習している」というお話も伺いましたが真偽のほどは分かりません。

èªåä»£æ¿ããã¹ãã¯ããã¾ããã

楽しかったところ②:平鍋さんの基調講演

　平鍋さんの基調講演でのメッセージで印象的だったものとして

プロダクトだけでなく顧客も開発するしチームも設計して育てる
アジャイル開発では、ウェブサービスは内製化が進んでるし、ベンダーはアジャイル開発拠点に参加するようになる
プロジェクトの見える化/透明化が重要。カンバンなど。

があります。特に最初の「顧客も開発する」については、きっとアジャイルの導入やチームへの新規ツールの導入、またOSSの開発など、チームや市場にどんなニーズがどれくらいあるか分からないものについては、みんなアジャイルにやってくのがいいのだろうなあと思いました。

　あと、後で平鍋さんから「１０年間同じ内容で講演している」という話を伺いまして、なるほどこういう情熱を持っている方が持続してメッセージを発信し続けることで日本のアジャイルは発展してきたのだなということを肌で感じました。

　平鍋さんの基調講演の内容については、平鍋さん自身がブログを書かれてますのでそちらもご参照ください。

anagileway.com

楽しかったところ③: 特別講演

　特別講演では、この半年間一緒にDevOps研修を育て上げてきた吉田さんと一緒に、アジャイルやテスト自動化導入の文化的・技術的な事例を紹介しました。

Jasst tokai18-rakuten-20181207 from Kotaro Ogino

www.slideshare.net

f:id:kokotatata:20181210150955p:plain — アジャイルにおけるテスト自動化の役割

　講演内容についてはスライドを参照いただくとして、ここではtwitterでの感想を紹介します。

テストの自動化はチームへのフィードバックするための仕組みの一つ #jasst_tokai_2018 #jasst
— 川喜多智信 (@yuimaster1982) December 7, 2018

後でついてきたもの。“この人とやればできる、と思われるようになる” -改革楽天ブルドーザー吉田彩奈さん #jasst_tokai_2018
— Kenji Hiranabe (@hiranabe) December 7, 2018

#jasst_tokai_2018
今日は良い刺激を頂きました。
ありがとうございます。

自分が会社に戻ってからやりたい事が少し整理できました。

楽天さんのノンフィクション#カイゼン・ジャーニーからは
勇気を頂きました。

自分なりのアプローチで
継続的なTRYをしたいと思います
— うじぽん (@RApFBzuGLJgrxAn) December 7, 2018

Fearless Changeの楽天の話が一番気づきが多かった
文化をかえることができるってあれくらいしなければいけないのか#jasst_tokai_2018
— takeshi@子育て3人からのTOEIC300点→600点達成 (@takeshi198310) December 8, 2018

　一緒に発表した吉田さん。実は社外発表は初めてだったのですが、ブルドーザー的なパワーで全部かっさらっちゃいまして、その後の情報交換会などでも吉田さんの講演内容の話題で持ちきりでした(笑)

楽しかったところ④: 情報交換会＆打ち上げ＆飲み会

　情報交換会、打ち上げとその後の飲み会とすごく盛り上がりました。このあたり、シンポジウムの主催者の方達が、会を一方向のものにしないで、双方向のものにしようという気遣い・努力がすごいなと思いました。

　やっぱりこういう社外のシンポジウムでは、普段お話する機会がない方たちといろいろお話できるのがいいですね。少しビックリしたのが、東海の方だけでなく東京や関西から参加されている方がいらっしゃったり、あとエンジニアだけでなく人事の方なんかも参加されてました。この辺、JaSST' Tokaiは懐が深いシンポジウムなんだなーと感じました。

　あと、シンポジウム後の飲み会では平鍋さんとたっぷりお話する機会と、素敵なカード（ハガキじゃないよ）を頂きました。ありがとうございます！

f:id:kokotatata:20181210200449j:plain

楽しかったところ⑤: JaSSTで「アジャイル」という単語を使ってもいいんだと確信した

　完全に個人的な偏見ですが、JaSSTには長らく「アジャイル」をキーワードとして使うことに対する暗黙の禁句的ななにかがあったように思います。完全に個人的な偏見ですが、JaSSTで「アジャイル」というキーワードを出すと、参加者から拒絶反応が返ってくると思ってました。なので2014年に初めてJaSSTで発表した時も、出来るだけアジャイルという言葉を使わずに自分たちの取り組みを説明することに苦心しました。

　ですが今年2018年、「アジャイルとテスト自動化について」前半にはJaSST'18 Tokyoでパネルディスカッションの依頼を頂き、後半には今回のJaSST'18 Tokaiで特別講演する依頼を頂き、流れは変わってきたなあと。

　特に今回、講演後の情報交換会で、参加者のみなさんもアジャイルの導入を始めたりもうすでにいろいろと導入してるお話を聞きました。話の方向性として「アジャイルめっちゃ楽しい」よりも「アジャイル大変」成分が多めなんですが、それでもみんなアジャイルについて話したい、話すことが好きなんですね。

最後に

　今回JaSST' 18 Tokaiに参加させて頂きとても楽しかったです。お呼び頂きまして、企画者のみなさまありがとうございました。インタラクティブな会を作ろうとしているのがすごくよくわかりましたし、あと日本の東海地方には東海地方独自のアジャイルがあるんだということが発見でした。ぜひ、また参加してみたいシンポジウムの一つですね。

f:id:kokotatata:20181217183911p:plain

f:id:kokotatata:20181217183924p:plain

2018-12-06

アジャイルもテスト自動化も当たり前？！ ~AIがテスト設計をする日が来るかも~

はじめに

このエントリは、ソフトウェアテスト #2 Advent Calendarの６目の記事として書いています。

qiita.com

モチベーション：JaSST'18 Tokyo 振り返り

　JaSST' 18 Tokyo のクロージングパネルでは、実は当初予定していたモノから内容を少し変更してお届けした[1]。GoogleのJohn Miccoさんによる基調講演の際に、Googleのような「アジャイルの導入も100%のテストの自動化も、もう当たり前」という考えと、JaSSTの参加者の多くの「アジャイルの導入もテストの自動化も道半ば、もしくはこれから検討する」との現実の間に、大きなギャップを感じたからだ。

　このブログエントリでは「アジャイルやテスト自動化は当たり前」と考えている人たちが、次の自動化としてどのようなことを考えているのか、なぜアジャイルやテスト自動化はもう当たり前なのかについて簡単に紹介してみたいと思う。

現在のテスト自動化の対象領域

　下記にいわゆるテストプロセスと、その中での現在のテスト自動化の対象領域を示す。

f:id:kokotatata:20181206124037p:plain — 現在のテスト自動化の対象領域

一般的にテストプロセスの中には

テスト要求分析
テスト設計
テスト実装
テスト実行
テスト終了作業

が含まれる。このなかで現在の自動化の対象領域になっているのはテスト実装とテスト実行だ。SeleniumやAppium、またCucumberなどのテスト自動化ツールは、テストコードとして記述したテストの実行を自動で行う[2][3][4]。また、MagicPodのようなツールでは、テスト対象の要素認識やテストコードへの自動変換など、テスト実装の一部を自動化することができる[5]。

　一方、テスト要求分析、テスト設計、テスト終了作業の自動化はあまり行われていない。これは、分析や設計などの判断を伴う作業は単純に自動化することは難しく、人間が判断をする必要があるからだ。では、AIを用いればこれらの判断を伴う作業も自動化ができるのだろうか？

AIとテストエンジニアの共通点

　実は、AIとテストエンジニアはその学習モデルに共通点が多い。次にAIとQAの学習モデルを示す。

f:id:kokotatata:20181206125325p:plain

　AI（この図ではロボットになっているが）は、環境との相互作用から事前知識のない環境について学習する。例えばブロックを扱うロボットの場合、ロボットはブロックに対して触ったり持ったりするアクションを実行する。そのアクションによって引き起こされた結果を、画像や触覚などの様々なセンサーからフィードバックとして受け取る。AIは自分のアクションに対するフィードバックから、環境についての知識を獲得する。このアクションとフィードバックを繰り返すことで、事前に知識がない事象についても学習することができる。

　テストエンジニアも探索的テストにおいて、これと似たプロセスをとる。テストエンジニアはテスト対象システムについての完璧なテスト設計を持たないところからテストを実行し、テスト対象とテスト設計について学習する。UIのボタンをクリックしたり、フォームに文字を入力したり、また強制的にシステムをシャットダウンするなど様々なアクションをテスト対象に実行する。そのアクションによって引き起こされた結果を、システム応答、画面上のメッセージ、エラーなどからフィードバックとして受け取る。テストエンジニアはこのアクションとフィードバックを繰り返すことで、テスト対象システムについての理解を深め、少しずつテスト設計を改善する。

　こうしてAIとテストエンジニアの学習モデルを比較してみると、どちらもアクションとフィードバックを繰り返すことによって対象の知識を獲得していっていることが分かる。

次のテスト自動化の対象領域

　上で見たように、テスト対象に対する理解を深めテスト設計を改善していくためには、アクションとフィードバックのループをテストプロセスの中で構成する必要がある。1回のテスト実行（アクション）が終了しテスト結果が出たら、そのテスト結果をテスト要求分析にフィードバックし学習する。次のテスト実行ではそれにもとづいて改善されたテスト設計を使いテストを実行する。

　このフィードバックループをテストプロセスの中に作ることが出来れば、同じ学習モデルでAIもテスト設計について学習する枠組みを作ることが出来るようになるだろう。これは、将来テスト要求分析やテスト設計をAIを利用して自動化していくことに繋がる。

　しかし、このフィードバックループを作るためには

フィードバックループの精度を向上させる
テスト終了作業の一部を自動化する

必要がある。

　1.は、AIが学習で利用するデータの品質が、AIの品質に直接影響するためだ。例えば、毎回テスト結果の異なるFlaky Testが学習データに大量に含まれていると、AIは効率よく学習することができないだろう。

　2.は大量のテストを高頻度で自動実行している環境では、テスト終了作業を手作業で実行していては追いつかなくなるためだ。実際John Miccoはパネルディスカッションの中でも、「数百万件のテスト結果を人間がすべて確認するのは不可能だ」と話していた。

f:id:kokotatata:20181206134303p:plain

　AIの台頭の中で、テスト実行だけではない、テスト設計やテスト終了作業の自動化がにわかに盛り上がってきているのである。JaSST'18 Tokyo のJohn Miccoさんの基調講演は、テスト終了作業でFlaky Testを自動判別し、テスト結果のデータベースをキレイにするための取り組み出し、例えばFacebookなどもバグ修正の自動化の取り組みを行っている[6]。

次のテスト自動化を始めるためには

　この「次のテスト自動化」を始めるために必要なのがアジャイルとテスト実行の自動化だ。

　テストプロセスの中に学習のためのフィードバックループを作るには、小さなテスト活動を何回も繰り返し回していく必要がある。一度きりの大きなテスト活動では、学習のフィードバックループは回らない。小さなテストを回していくためには、開発自体もアジャイルにする必要があるし、テストもアジャイルに進めていく必要がある。

　もう一つはテスト実行の自動化だ。テスト実行が自動化されていれば、テスト実行にかかるコストがほぼ0になるので、より高速、高頻度でフィードバックループを回すことが出来るようになる。自動化さえしていれば、たとえテストケースが数百万件あろうともこのフィードバックループを数週間から1日で回すことが可能になるのである。

　なので、次のテスト自動化に取り組んでいる人たちは、アジャイルもテスト自動化も当たり前と考えているのだ。

終わりに

　このブログエントリでは、テスト自動化における次の自動化対象領域について紹介した。現在のテスト自動化の多くはテスト実行に集中しているが、テスト設計やテスト終了作業の自動化への取り組みももうすでに始まっている。これらの領域を自動化していくにはAIの利用は必須だろう。AIを効率的にテストプロセスの中で利用するためには、テストプロセスの中でのフィードバックループの構築が重要になる。テストのフィードバックループの構築には、少しずつテストを繰り返すアジャイルの導入と、繰り返しテストを実行するためのテスト実行の自動化は必須となる。

参考文献

[1] アジャイル・自動化時代のテストの現場のリアル, JaSST' 18 Tokyo クロージングパネル
[2] Selenium - Web Browser Automation
[3] Appium: Mobile App Automation Made Awesome.
[4] Cucumber
[5] Magic Pod
[6] Finding and fixing software bugs automatically with SapFix and Sapienz - Facebook Code

2017-12-31

個人の経歴・プロフィール2017年バージョン

講演・執筆活動

カンファレンス講演等（日本）

「アジャイル開発におけるメトリクスの活用（パネルディスカッション）」[発表スライド]（SQiP 2016）
「DevOpsから見たテスト自動化と価値の見える化」（JaSST' 関西 2016）
「三位一体の自動化で壊せDevとOpsの壁」（デブサミ2016）
「継続的システムテストについての理解を深める為の開発とバグのメトリクス分析（再演）」（SQiP 2015）
「継続的システムテストについての理解を深めるための開発とバグのメトリクス分析」（SQiP 2014）
「システムテストの自動化による大規模検索プラットフォームの開発工程改善」（JaSST' Tokyo 2014）

カンファレンス講演等（国外）

「Metrics Analysis on Continuous System Test」（ASQN 2016）

執筆関連

「変革の軌跡世界で戦える会社に変わる"アジャイル・DevOps"導入の原則」へのDevOps事例「楽天のDevOpsエンジニアのストーリー」の寄稿 (2017)
「楽天でのエンタープライズアジャイルとDevOps」（情報処理学会デジタルプラクティスVol.7 2016）
「安心なサービスの品質改善を実現する為の継続的システムテスト」（IPA 先進的な設計・検証技術の適用事例報告書2015年度版）

勉強会での発表

「~ilities Test Automation」(ICST2017 Unofficial Meetup 【共著】, 2017)
「オフショアテストチームが、テスト自動化チームとして生まれ変わった物語」（第４回Seleniumユーザーコミュニティ勉強会, 2016）
「楽天の品質改善を加速する継続的システムテストパターン（再演）」（エンタープライズ勉強会 2016年2月セミナー）
「楽天の品質改善を加速する継続的システムテストパターン」（システムテスト自動化カンファレンス2015）
「Rakuten and Microsoft talk DevOps in Real World 」(楽天テクノロジーカンファレンス2015)
「誰がテスト自動化をするべきか？」（楽天テックカンファ前夜祭, 2014）
「継続的システムテストについての理解を深める為の開発とバグのメトリクス分析（再演）」（第21回カフェソフトウェアクオリティ, 2014）
「Data Driven Development」（システムテスト自動化カンファレンス2013 LT）
「リーンキーワード駆動型漫才」（DevLove現場甲子園2013完結編）
「Software Engineer in Test @ 楽天の検索基盤開発の現場」(DevLove現場甲子園2013）
「検索基盤開発のための結合テスト環境の自動化」（第６回テックヒルズ, 2013）

勉強会企画

書籍関連・インタビュー・ブログ記事など

「特集2 "素早い"テスト実践法」（日経SYSTEMS８月号,2017）
「ITエンジニア新図鑑：テストエンジニアについてのインタビュー」（日経SYSTEMS ５月号, 2017）
「DevOps時代のテスト要求分析」（個人ブログポスト, 2016）
「DevOpsについてのインタビュー」（日経コンピュータ2016年11月10日号）
「DevOps事例提供」(エンタープライズアジャイルの可能性と実現への提言, 2016)
「Rakuten DevOps Evidence January」(2016)
「DevOpsインタビュー：第１回楽天さんのDevOpsについて聞いてみた」 (2015年)
「"グローバル化"と"コミュニケーションとアジャイルとテストエンジニア"」（Ultimate Agile Stories Iteration 5, 2015）
「アジャイルテストのテスト設計の話」（個人ブログポスト, 2015）
「継続的システムテスト」（個人ブログポスト, 2014）

資格

JSTQB Advanced Level テストアナリスト (2017)
JSTQB Advanced Level テストマネージャー (2015)
JCSQE 初級 (2014)
JSTQB Foundation Level (2014)
プロダクトオーナー(2014)

2017-12-11

テスト自動化プロジェクトでExcelを使わない１０の理由

モチベーション

　この記事はソフトウェアAdvent Calendar 2017の11日目のブログエントリとして書いています。

　昨日参加したシステムテスト自動化カンファレンス2017で、「もう２年以上、テスト自動化プロジェクトの中でExcelを使ってないなぁ」ということを思い出した。

　２年半前にガチのExcelファイルで書かれたテスト設計ドキュメントを初めて見て、このやり方ではテストが成長できなくなるということを痛切に感じた。その時の考えを２次元の表によるテスト管理の限界 - Test Automationというブログエントリにまとめてから、うちのチームではExcelをテスト自動化の中で使っていない。

　前回のエントリより２年半経って、Excelを使ってない理由についての考えがより鮮明になってきた、ここでは、それらExcelをテスト自動化で使わない理由をつらつらと書き連ねていく。

テスト自動化プロジェクトでExcelを使わない理由

理由①：Excelはユーザー環境の互換性や移植性が低い

　Excelの問題の１つ目は、開発者や運用エンジニアなどを含めたテスト自動化プロジェクトの大半のステークホルダーの環境で期待通りに動作しないことだ。Windows上で綺麗に整形されていたり、職人技の関数芸やVBA芸でまとめられたExcelファイルは、残念ながらMacやLinuxでは期待通りに表示されない。僕が今年見た一番ひどいExcelファイルでは、１回データを入力するごとに僕のMac上ではエラーが表示される。

　開発エンジニアや運用エンジニアに人気のOSであるMacやLinuxでまともに動かないツールをテスト自動化プロジェクトで使うことは、エンドユーザー向けにWindows Phoneでは動くが、AndroidやiOSではバグだらけのアプリをリリースするようなものだ。

理由②：テストケースに対するスケーラビリティが低い

　Excelはデータサイズのスケーラビリティが低い。まず、仕様が最大約100万行、最大約2万列と、一般的なテスト自動化プロジェクトで取り扱うテストケース数を考えると少なすぎる。また、実際には数万行を超えたくらいから動作がもっさりしてくる。Excelで表現できるテストケース数はせいぜい数百から数千だろう。

理由③：テストエンジニア/クライアントに対するスケーラビリティが低い

　Excelはユーザ数に対するスケーラビリティが低い。ファイル共有について、メール、共有ファイル、オンライン版など、どれを使うかにもよるが、そもそも数百人が同時にアクセス＆編集するユースケースを想定しているものではない。多分、同じタイミングで一つのファイルを編集する人間は一人か、せいぜい声を掛け合える範囲の数人を想定しているように思う。

　この問題はExcelファイルにアクセスするのが人間でなくテストクライアントの場合、顕著に起こる。テスト実行時間が長くなってきた場合など、テストクライアントを複数並べ平行に実行するようにすることでテスト実行時間を短縮する。数十から数万のテストクライアントが同時に１つのExcelファイルにアクセスした場合、ここがボトルネックになってしまうことは明白だ。

理由④：テスト実行頻度に対するスケーラビリティが低い

　Excelはテスト実行頻度に対するスケーラビリティが低い。同じテストをプロジェクト中に一回、または年に数回程度実行するだけならばExcelでも十分だ。しかし、ほとんどのテスト自動化プロジェクトの目的は柔軟なテストの実行だ。一年を通して毎日継続的に実行したり、場合によっては1日に何百回も実行することもあるだろう。

　テスト実行頻度が増えるにつれ、例えば、テスト結果ドキュメントの数も増大する。Excelでテスト設計を管理すると、数万に及ぶテスト結果との対応関係をとっていくことが難しくなってしまう。

理由⑤：テストケースの最新性の低下

　ExcelファイルがローカルPCと共有ファイルサーバーで２重管理される場合、テストケースの最新性が低下する可能性がある。共有ファイルサーバーにあるファイルが最新なのか？最新のファイルが誰のローカルPCにあるのか？などのデータの最新性の問題が簡単に起こる。加えて、複数のメンバーがローカルのファイルをどんどんと更新し続けたため、あとで変更を１つのファイルにマージするのが大変になるなんてのも、よく聞く話だ。

　これらの問題は、継続的インテグレーション(CI)のような、継続的にファイルをマージしていくフローを作ることで防ぐことが可能だが、ExcelユーザにはCIのような文化がそもそもない

理由⑥：テストケースの差分管理が煩雑

　Excelは２次元でデータを表現するため、行指向でデータを管理するSVNやGitで差分管理しようとすると煩雑になる。極端な例で言えば、１列追加しただけでもすべての行に変更が入るため、データ更新履歴としてはすべての行が対象となってしまう。そのためPullRequestのレビューで、ソースコードとテストケースの変更箇所の比較を行ったりすることが煩雑になってしまう。

理由⑦：テストコード設計の表現力が低い

　テスト設計の成果物であるテスト設計ドキュメントは、その次のアクティビティのテスト実装の入力になる。テスト自動化プロジェクトの場合は、テスト設計ドキュメントを入力として自動実行可能なテストコードを実装する。ここで問題になることは、２次元の表形式のテスト設計は、オブジェクト指向設計などのプログラム設計の手法を用いたテストコードの設計を表現できないことだ。

　例えば、テスト設計では個々のテストケースがテストに必要な情報を網羅する完全性が重視されるが、テストコード設計では、重複する部品を再利用可能なクラスとして定義することが重視される（今年のアドベントカレンダーのこれとかこれとか）。

理由⑧：テストケースの表現の煩雑さが増す

　１つのテストケースは、事前条件、テスト対象、テスト手順、テスト条件、期待値、環境など様々な情報によって表現される。これは、テストケースを表現する軸は多次元であることを意味するが、Excelの表では２次元で表現することになる。

　人間は多次元のデータ操作が苦手なので、多次元のテストケースを非正規化しExcelで表現することにも手動テストの場合には一定の価値がある。しかし、コンピュータもデータ操作するテスト自動化プロジェクトの場合、多次元のデータを２次元で表現するとデータモデルが煩雑になり自動化が難しくなってしまう。

理由⑨：テストケースの保守性<テスト項目の追加>

　Excelの凄いところは、データサイズがそれほど大きくない場合、データの追加や変更のみならず、スキーマやデータモデルの変更も簡単に行える点だ。データベースなどではスキーマ変更などを伴う変更も、列を追加したり変更したりするだけで出来る。

　しかしこの簡便性は、データスキーマの一貫性とトレードオフの関係にある。データベースの煩雑なテーブル定義の制約は、一方でスキーマの一貫性を保証する役割を担っている。しかしExcel自体はスキーマ変更を保証しないため、例えばExcelファイルのテストケースに新しい項目を追加する場合、人間がすべてチェックす必要がある。数十万、数百万のテストケースすべてに対しスキーマの一貫性をチェックするのは困難だ。

理由10：テストケースの保守性の低下<リファクタリングが困難>

　テストケースが増えてきたとき、テスト設計をリファクタリングしたくなることがある。テストカバレッジが下がらないことを保証しながら、テストスイートのグルーピングを変更したり、テストの実行順序を変更したり、テストケースを削除したりする作業だ。定期的にリファクタリングすることで、テストケースを継続的に保守可能な形に保つ。

　テスト設計をリファクタリングするためには、多次元のテスト設計を様々な２軸に射影することが不可欠になるが、もともと２次元の表で表現されている場合、この写像が困難だ。そのため、大胆なリファクタリングを行って大量のテストケースを削減することなどができなくなる。

まとめ

　テスト自動化プロジェクトでExcelを使わない理由をつらつらと書いてきた。もちろんExcelは素晴らしいツールだし、場合によってはテスト自動化プロジェクトでも使っていい場合もあるかもしれない。例えば、チームにあったテスト設計のアプローチを議論する際には、数百くらいのテストケースをExcel上で操作しながら話し合うのはいいかもしれない。また、テストレポートに掲載するグラフのドラフトバージョンを作成したりするのにもExcelは簡便なツールだ。

　一方で、テスト自動化プロジェクトに組み込むためには、Excelには制限が多すぎる。特に、テストケース数やテストエンジニア/クライアント数に対するスケーラビリティの問題は、テスト自動化にとっては致命的と言える。また、繰り返し実行することが前提のテスト自動化プロジェクトでは、２次元の表でテストケースを表現することはテストの保守性に深刻な影響を与える。