Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア（Automation Architect）のブログです。

エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話2/3

前回の続き

ちょっとしたカイゼン物語をエンジニアコミュニティに送り出す

　身の回りのちょっとしたカイゼンの話を見つけたら、次はどんな勉強会で、どんな構成で発表するか考えるだろう。でも、エンジニアコミュニティでの発表って、ちょっと敷居が高いと思われているかもしれない。

　実際、JaSST'18 Tokaiの発表スライドとDevOps Days Tokyoの発表スライドを作っていているときも、エンジニアの僕は無意識にやっていることでも、人事の相方は「？？？」となる、エンジニアコミュニティ独特のお作法がいくつかあった。

　ここでは、人事の相方と一緒にスライドを作る中で気が付いた、エンジニアコミュニティ独特のお作法を、これからエンジニアコミュニティでの発表を目指す人向けに４つのポイントとして紹介しようと思う。

①発表の位置付け

　自分の発表が、コミュニティや今までの技術の発展の中でどういう位置付けなのかを明確にすることは、発表の意義をみんなに知ってもらう上で一番重要だ。こう書くと難しいことのように感じるかもしれないけれども、要は、「みんなXXについて課題を感じているよね？そのXXについての解決方法YYを考えて実践してみました」っていうように、自分の問題意識とアプローチを明確にするってことだ。

　ここでいう問題意識は、「アジャイルや自動化をチームに導入したいけど色々大変」とか、「自動化を進めたいけどチーム間でのコラボレーションが大変」といったような身の回りでありがちなもので最初は十分だ。いま自分が困っている課題は、実は世の中の多くの人が同じ課題感を抱えている可能性がある。その課題を実践的に解決する話は、きっとエンジニアコミュニティの他の人たちにとっても価値がある。

②発表内容のエンジニアリング的な納得感

　お作法ってほどではないけれども、「もうすでにコミュニティの中で正しいと信じられていること」から実践してみたり、発表スライドを始めてみたりするのはオススメのテクニックだ。エンジニアリングコミュニティの中では今までの歴史や積み重ねの中で、なんとなく「エンジニアリング的に正しい」と信じられていることがある。

　もし、そういう事柄があるのならば、発表スライドの一番最初にその話を紹介すると、「ああ、あの（みんなが正しいと信じてる）プラクティスを実践したのね」「ああ、あの（みんなが正しいと信じてる）手法を発展させたのね」と納得感を得られやすい。（例：いきなり「ブルドーザー」と言っても「なんじゃそりゃ」とビックリするけれども、いったんみんなの知っているFearless Changeをはさむことで、納得感が生まれるw）　

③発表内容の新しい価値とオリジナリティ

　もしあなたの発表内容が、例えば教科書に書いてある手法をその通りにやってみただけであったとしても、その実践内容や結果を発表することはコミュニティにとって大きな価値がある。どういう条件の時にうまくいくのか、いかないのか、事例として共有されると、その手法についての実践知がたまり、より深く理解するきっかけとなる。

　でも、僕個人としては、そんな事例の中にも少しオリジナルのアイデアがある方が好きかなあ（笑）。教科書的な部分て堅苦しい面があるけれど、「ブルドーザー」みたいなオリジナルのアイデアってやっぱワクワクするのよね。

④その手法はいつでも誰でも実践可能か

　もしあなたのカイゼン手法が、誰にでもどんな場合でも実践可能なものならば、多くの人がその手法を実践してみるだろう。より多くの人にとって実践可能な手法はコミュニティにとっても価値が高い。でも、カイゼン手法を誰でも実践可能なモノに落とし込むには少なからず手間がいる。

　手法の原因や結果などを構造化したり、ステップバイステップの手順を書き起こしたりすると、より多くの人が簡単に実践できるものになる。パターン化は、より定義された構造化の方法だ。また、その手法を使ってうまくいく・うまくいかないケースの条件なんかも、その手法を実践してみようとする人にとって貴重な情報だ。

「人事がDevOps研修を作っちゃった話」の上記４つのポイント

　今回の発表の中で、上記の４つのポイントをどのように作り込んでいたのかを参考までに書いてみる。

  JaSST Tokaiの場合 DevOps Daysの場合

発表の位置付け
  • 「"アジャイル"や"自動化"などの新しいプラクティスを組織に導入する」際に必要な文化的な変革の事例
    • ソフトウェア開発に置いて、特にテストの分野ではアジャイルや自動化を導入することが業界全体として急務の課題となっている
    • 上記課題に対して、技術的な解決方法はいくつか提案されているが、文化的な側面の解決方法および事例は少ない
  • DevOpsの文脈で重要な文化的な変革の１つ、研修の促進の事例
    • DevOpsの分野では、コンウェイの法則で知られるように、自動化などの技術的な側面だけでなく、文化的な変革も重要と言われている
    • 上記課題に対し、どういった研修が重要か？どういう風に研修を広めると効果的か？といった議論はほとんどされていない

発表内容のエンジニアリング的な納得感
  • 新しいプラクティスを組織に導入する手法・事例として「Fearless Change」と「変革の軌跡」を参照
  • 実践した手法・結果について、Fearless Changeをベースに振り返る
  • 新しいプラクティスを組織に導入する手法として「Fearless Change」を参照
  • 実践した手法・結果について、Fearless Changeをベースに振り返る

発表内容の新しい価値とオリジナリティ
  • 組織に研修を広めていく際に効果的だった行動が、フェアレスチェンジとも合致していたことを示す
  • また、フェアレスチェンジのカバーしていない部分を、オリジナルのパターン”フェアレスブルドーザー”として提案
  • 組織に研修を広めていく際に効果的だった行動が、フェアレスチェンジとも合致していたことを示す
  • また、フェアレスチェンジのカバーしていない部分を、オリジナルのパターン”フェアレスブルドーザー”として提案

その手法はいつでも誰でも実践可能か
  • あくまで事例の紹介であり、手法の再現性を保証するものではない
  • ただし、手法の振り返りにフェアレスチェンジをベースとして用いることで、パターンランゲージが保証する範囲での再現性を担保する
  • フェアレスブルドーザーの再現性を担保するには、別途再現性をパターンなどで担保する必要あり
  • あくまで事例の紹介であり、手法の再現性を保証するものではない
  • ただし、手法の振り返りにフェアレスチェンジをベースとして用いることで、パターンランゲージが保証する範囲での再現性を担保する
  • フェアレスブルドーザーの再現性を担保するには、別途再現性をパターンなどで担保する必要あり

 

次回に続く

エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話1/3

講演活動 DevOps

モチベーション

　先日DevOps Days Tokyoというイベントで「人事がDevOps研修を作っちゃった話〜恐れ知らずのブルドーザー改革〜」という内容で、人事の担当者と共同発表した。これは、DevOps研修を作るにあたって壁となるコンウェイの法則を乗り越えるため、様々な部署のたくさんのエンジニアをブルドーザーのように巻き込んだ、という人事視点のちょっとしたカイゼン物語をエンジニアの技術コミュニティで発表したものだ。

www.slideshare.net

　このブログエントリーでは、この発表が作られるまでのエンジニア視点のアナザストーリーを書いてみようと思う。ここに書く話が、まだエンジニアコミュニティで発表したことがないけど迷っている人や、身の回りのちょっといい話をどうやって育てていこうか悩んでいる人にとって、次のステップに進むためのヒントになったらいいなと思う。

身の回りのちょっとしたカイゼン物語を見つける

人事の相方をエンジニアコミュニティでの発表に誘ったら

　今回、ノリノリで発表してくれた人事担当の相方だけど、エンジニアコミュニティでの発表を最初に誘った時は、実はものスゴく後ろ向きの反応だった。「私はエンジニアじゃなくて人事だし、私のやってることなんて大したことないからエンジニアに話してもつまらない」と。（←これ、JaSST' 18 TokaiやDevOps Daysでのブルドーザー発表を見た人にとっては信じられない話かもだけどもw）

スゴイ研究者や偉いエンジニアじゃなくたって…

　「エンジニアコミュニティの発表ってスゴイ研究者や偉いエンジニアがするもの」って漠然と思っている人って多いよね。たしかに、スゴいエンジニアの、例えば5年後のエンジニアリングに変革をもたらすような話は面白い。AIを活用することで既存のQAの形を劇的に変えるようなイノベーションの話なんかは、僕も大好きだ。

　でも、「自分はスゴイ研究者や偉いエンジニアじゃないから」って理由で、エンジニアコミュニティでの発表をためらう必要はない。世の中のエンジニアコミュニティが一歩でも前に進む内容なら、実績とか立場とか関係なくどんどん世の中に発信した方が、コミュニティにとっても自分にとっても価値が生まれる。

現場のちょっとしたカイゼンの話は特に価値がある

　特に現場のちょっとしたカイゼンの話は、多くの人から共感を得られるし、聞いてくれた人に課題解決のヒントをもたらすことがある。僕の中では、この人事視点の物語がたくさんのエンジニアたちからの共感を得られるって確信があった。エンジニアと人事という立場や手法の違いはあれど、チームをよりよくするためのカイゼンをアジャイルに回していくっていう本質は同じだからだ。

　だから、発表することに対してあまり自信がなかった人事の相方を一生懸命説得した。「この人事視点の話をJaSSTで話すことで、アジャイルやテスト自動化で苦労してるたくさんのエンジニアたちが、自分たちのカイゼン活動を見つめ直して新しい解決のアプローチを考えるきっかけになる」って。そうしたら、「なんか騙されている気がするけど…w」と言いながら、一緒に発表することを承諾してくれた。

色んな現場に色んなちょっとしたカイゼンの話が埋もれている

　今回、僕は人事視点のちょっとしたカイゼンをたまたま見つけたのだけれども、色んな現場にまだまだたくさんのちょっとしたカイゼンが埋もれていると思う。それは、もしかしたらあなたのチームにあるかもしれないし、あなたの隣のチームにあるかもしれないし、今あなた自身がやっているカイゼンかもしれない。そういう「ちょっといい話」を見つけるのってすごく大事だと思う。「でもこれはそんな大した話じゃないし」なんて尻込みせず、「世の中のエンジニアリングがちょっとよくなるかも」と、そんなちょっとしたカイゼンの話がどんどんエンジニアコミュニティで公表されたらいいなあ。

 

次回に続く

f:id:kokotatata:20190418091458p:plain

 

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年バージョン

講演・執筆活動

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

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

執筆関連

勉強会での発表

勉強会企画

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

資格

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

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研修を育て上げてきた吉田さんと一緒に、アジャイルやテスト自動化導入の文化的・技術的な事例を紹介しました。

www.slideshare.net

f:id:kokotatata:20181210150955p:plain

アジャイルにおけるテスト自動化の役割

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

 

 

 

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

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

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

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

 

アジャイルもテスト自動化も当たり前？！ ~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. フィードバックループの精度を向上させる
  2. テスト終了作業の一部を自動化する

必要がある。

　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を効率的にテストプロセスの中で利用するためには、テストプロセスの中でのフィードバックループの構築が重要になる。テストのフィードバックループの構築には、少しずつテストを繰り返すアジャイルの導入と、繰り返しテストを実行するためのテスト実行の自動化は必須となる。

参考文献

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

講演・執筆活動

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

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

執筆関連

勉強会での発表

勉強会企画

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

資格

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