JaSST Tohoku実行委員ブログ

JaSST Tohoku実行委員のあれこれを載せていきます、たぶん、きっと。

JaSST東北流ワークショップの作り方

こんにちは!JaSST東北実行委員のMayです。

JaSST'18 Tohokuは2018年5月25日(金)にHAYST法をテーマに、ワークショップを開催します。

2年前のJaSST'16 Tohokuで初めてワークショップづくりに挑戦し、その大変さと得るものの多さを実感し、隔年でワークショップを作ろうという方針になりました。今回のブログでは、その舞台裏をご紹介します。

JaSST東北流ワークショップの作り方

テーマ決め

テーマは企画メンバーが「学びたいこと」を出し合って決定します。と言っても、JaSST東北では「テスト設計とはなんぞや」という疑問を常に胸に抱いておりますので、選択肢はだいたい決まっています。

まずは各自で勉強

書籍や公開資料をもとに、基本的な理解を深めます。使われる用語や手法をあらかじめ理解しておくことで、議論に入りやすくなります。今回参考にした書籍はこちらです。

honto.jp

www.kinokuniya.co.jp

みんなでやってみる

ワークにすることは置いておいて、実際に手法を使ったテスト設計をやってみます。頻度は月1で、土日のどこかを使って集まっています。今回は、JaSST'17 Tohokuが終わった2か月後、7月から始めました。12月で5回目になります。

実際にやってみると、たくさんの疑問が沸いてきます。疑問点はスプレッドシートにまとめておきました。解決した疑問は、躓きポイントとして記録しておきます。

教えてもらう

今回のワークショップを開催するにあたり、HAYST法の生みの親の一人である秋山浩一さんにご協力いただけることになりました。やってみた中で見つかった疑問点をメールでご回答いただいた他、講師として仙台にお呼びして、直接教えていただきました。

秋山さんにお越しいただいた9月の勉強会では、実行委員みんながモヤモヤし続けていた「Whomの謎」「有閑マダムの謎」が解消されて、HAYST法の後半のプロセスに進むことができました。基調講演も含めた、JaSST東北当日のだいたいの流れも見えてきました。

持ち帰ってもらいたいことを決める

ワークショップを通して、「誰に何を持ち帰ってもらいたいか」を決めます。現在進行形なのは、まだ決まっていないからです。HAYST法は複数のアクティビティで成り立っており、テスト設計には多くのステークホルダが登場します。おおよその方向性は決まってきましたが、「これ!」と決まるまではもう少しかかりそうです。

ワークの内容と時間配分を決める

実際に自分たちでワークをしながら、どんな内容をどのぐらいの時間でやるのか、決めていきます。テスト対象のすべてのテスト設計をするとなるとボリュームが大きくなるため地域ジャスト初の2日開催も検討しましたが、集客を考えて1日で収まる範囲に絞ることにしました。HAYST法の全体像が見えることを保ちつつ、ポイントを絞っていく方針ですが、濃密な1日になりそうです。こちらも詳細が決まるのはもう少しかかりそうです。

プレゼンテーションとモデレートの練習

ワーク内容に集中してもらうため、「何をすればいいのか」「どのぐらい時間を使っていいのか」などの指示は明確にしておきます。また、時間が限られた中で、手が止まったりやり直しになってしまってはもったいないので、実行委員がサポートできるようにしていきます。

VSTePをテーマに開催したJaSST'16 Tohokuは、テーブルごとに班としVSTePによるテスト開発を行いましたが、班ごとに実行委員を1人つけました。あくまで主役は参加者なので、こちらから答えを提示するのではなく、みんなに考えてもらえるようにしなければなりません。参加者が躓くポイントは、ワークを作っていく中で実行委員自らが体験していることが多いです。事前に一覧にまとめ、開催前に振り返りを行いました。

班決め

グループワークをする場合、班を構成するメンバーがワークの結果を左右することがあります。様々な背景を持つ人が集まるJaSST東北では、「同じ会社の人は違う班に分かれる」というルールに従って席についていただくようお願いしています。

1つの班に同じ背景を持った人がいると、暗黙知の説明がないまま話が進みかねません。そのため、あえて背景の異なる人同士で集まってもらうようにし、質問しやすいようにしています。参加者にとっても、普段接することがない方々と話すことで、会社や立場の違いによる気づきも得ることができると考えています。

開催日当日

ここまでの準備でやってきたことを信じて、やるのみです!モデレーターが自信を持たなければ、参加者が不安になります。自信を持って対応することが、成功への鍵だと思います。

まとめ

ワークショップを作るポイントは、

  • 作り手が内容を十分に理解すること
  • 参加者が迷わないようにすること

が挙げられると思います。これは経験則から導いたものなので、他にもあったらぜひ教えてください。

作り方のほとんどは、2年前、JaSST'16 TohokuでVSTePをテーマにしたときに、VSTePの生みの親である にしさん から学んだものです。開催1か月前に「みんなが参加者に持ち帰ってもらいたいものはなに?」と問いかけられて、全員の回答が一致しなかった時には絶望しました(笑)詳細はまたいつか、ブログで紹介できたらと思います。

みんな来てね!

こうやって作ったワークが、2018年5月25日(金)に仙台で日の目を見ます。みなさんのご参加、お待ちしています!

 

ペルソナのコツ

こんにちは。東北実行委員アドバイザの@nemorineです。


皆さんは開発やテストでペルソナを作ることがありますか?
作っているとしたら、どうやって、どこまで作りこんでいますか?ガイドラインはありますか?今回は自分が思うペルソナの作り方について考えていきたいと思います。

それでは最初にペルソナ定義を見ていきましょう。

ペルソナ(心理学)~ Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%9A%E3%83%AB%E3%82%BD%E3%83%8A_(%E5%BF%83%E7%90%86%E5%AD%A6)

ペルソナデザイン
https://ja.wikipedia.org/wiki/%E3%83%9A%E3%83%AB%E3%82%BD%E3%83%8A%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3


元々は心理学の用語であの有名なユングが使っていたんですね。
マーケティングなどでは『最も重要で象徴的なユーザーモデル』とのことです。

作るメリットは・・・

「ペルソナ」導入により得られる4つのメリット

  1. 一人の顧客像に対するデータを徹底的に分析することで、ユーザの実態に対する理解が深められる
  2. 「思い込み」や「関係者間の意識のズレ」を防ぎ、精度の高いユーザ視点を持つことができる
  3. 担当分野の異なる関係者間でも、同じ顧客像を常に意識することが容易となるため、議論の質が高められる
  4. 価値観の多様化とニーズの細分化が進む中、ユーザの本音を理解し、コミュニケーションを深めていくために効果的である

参考) https://smmlab.jp/?p=20107


自分もテスト設計コンテストのときに作りましたが、どこまで作ればいいのかというのがモヤモヤしていました。

さてそれでは実際によくありがちなペルソナを作ってみましょう。

電気ポッドを使うペルソナ その①

尾湯 沸(おゆ わかす)
北海道大学の学生。
出身は音威子府で現在は札幌の麻生で一人暮らし。年上の彼女を絶賛募集中。
バイトはファミレスで深夜勤務を週4で頑張っている。
カップラーメンが好きで1日少なくとも1食はカップラーメンを食べる。毎月実家から30個のカップラーメンを送ってもらっている。
趣味は貧乏旅行で、一年に一回はバックパックでアジア諸国を回る。


それではこのペルソナの問題点を挙げてみましょう。

  • 作るときにユーザーの声や統計情報などを参考にせず、自分の経験や思い込みで作っている。
  • ペルソナに書かれている情報のほとんどが製品に不要な情報である。
  • 特化しすぎていてカップラーメン専用ポッドのようなペルソナになっている。
  • そもそもこのような行動をする人が極少数である。

どうしても作っていると詳細設定をするのが楽しくなってしまうんですよね。。。
JaSST北海道で楽天の川口さんに会ったときに、どこまで作ればいいのかという疑問をぶつけてみたのですが、『ペルソナは検証可能じゃなければならない』という回答をもらいました。
ペルソナはあくまで仮説ですので、川口さんの言葉は当たり前なのかもしれません。ただ自分はこの回答でかなりスッキリしました。上記のペルソナも行動様式が似ている人を集めるのは不可能に近いと思います。

まずは不要な情報を削除して、シンプルにしてみましょう。

電気ポッドを使うペルソナ その②

尾湯 沸(おゆ わかす)
大学生で現在は一人暮らし。
毎朝コーヒーを飲む。週に少なくとも3食はカップラーメンを食べる。
使い終わった電気ポッドのお湯を捨て忘れることがよくある。

 

ポッドに関わる情報はありますが無味無臭すぎますし、あるシチュエーションでどういう判断や行動をするかは分からないですよね。もう少し性格やこころの奥に持っている欲求を付加していきましょう。

電気ポッドを使うペルソナ その③

尾湯 沸(おゆ わかす)
大学生3年生で現在は一人暮らし。彼女はいない。
朝、頭をスッキリとさせるために毎朝コーヒーを飲む。
好きな食べものはラーメン。外食もするが、少なくとも週に3食はカップメンを食べる。
面倒くさがりで、残ったお湯がそのままになってしまうこともよくある。

 

どうでしょうか?製品をどう使うかに加えて、行動を決定する一要因である『面倒くさがり』という性格を表すワードを入れています。性格や欲求を入れ込むことで、細かいところまで規定する必要がなくなります。この人だったらこの状況ではこういう行動するだろうな、という共通認識を持つことができます。


最後にもう一つアンチパターンを紹介します。製品には関係ない欲求の付加情報をつけると、その情報に引っ張られてしまい本質を見失うことがあります。


電気ポッドを使うペルソナ その④ アンチパターン【関係ないけど気になっちゃう設定】

尾湯 沸(おゆ わかす)
大学生3年生。現在は同じ大学の1コ下の可愛い系の彼女と付き合っている。
しかしバイト先の先輩女性のことが好きになってしまい彼女と別れるべきか悩み中。先輩とは1日1回以上LINEでやり取りしているので、先輩もまんざらではないようである。
朝が苦手なので目覚めに毎朝コーヒーを飲む。
好きな食べものはラーメン。外食もするが、週に少なくとも3食はカップラーメンを食べる。
片付けが苦手で、部屋のキッチンは洗い物が溜まっていることが多い。残ったお湯がそのままになってしまうこともよくある。付き合っている後輩は家に遊びに来るたびにしっかり片付けをしてくれる。

 

どうでしょうか?優柔不断という性格を伝えたいのかもしれませんが、もはやポッドをどう使うかより、彼女と先輩女性の恋愛模様に目が行ってしまいますね。ということでこれも個人的にNGかなと思ってます。もちろんペルソナをイキイキさせるためには多少の付加情報は必要ですが、バランスが重要ですよね。

自分なりのペルソナ作成のコツを簡単にまとめると、
・検証可能であるかを意識する
・性格や欲求を付け加える
・気になっちゃう不要な設定は付け加えない

ペルソナに付加情報を加えて具体的にすることも重要ですが、さらにその奥底にあるユーザーの性格や欲求にアプローチするのがより重要だと思います。

ということで有意義なペルソナライフを!!

WACATE2017 冬に参加してきました!

こんにちは。JaSST東北実行委員の@ToshiManaPlus1です。
2017年も終わりに近づいており、忘年会シーズンになってきました。
今年を振り返りつつ、来年への勢いを付けたいと思い、
若手を中心としたソフトウェアテスト技術者が集まる勉強会「WACATE2017 冬 ~すべてがTになる~」に参加してきました。

WACATE2017 冬 ~すべてがTになる~ 開催概要 - WACATE (ソフトウェアテストワークショップ)

 

WACATEとは


「WACATE」とは神奈川県のホテルを借りて、一泊二日の合宿形式でひたすらソフトウェアテストについて学ぶことができる勉強会です。名前の通り若手エンジニアをメインターゲットとしており、座学だけでなく、濃厚なワークを体験できることが特徴として挙げられます。「WACATE」とは「Workshop for Accelerating CApable Testing Engineers」の略称であり、「加速」をキーワードとして参加者が成長できる場づくりが行われています。年2回開催されており、「1つのテーマを深く」の夏開催と「多くのテーマに触れる」冬開催でそれぞれ特色があります。冬開催の今回は多種多様なワークショップで構成されており、多くの知見を得ることができました。

JaSST東北では毎年ワークショップを実施しているため、特にワーク部分に着目して参加した感想を書いていきたいと思います。(数が多いため、1つあたりの感想は少な目です…)


BPPセッション

「WACATE」では、参加申し込みをする際にポジショニングペーパー(PP)という「参加の意気込み」などをまとめた書類を提出する必要があります。前回の「WACATE2017 夏」で最も優れたPPを書いた人によるセッションがBPP(ベストポジショニングペーパー)セッションになります。
今回は@koooooooooookiさんによる自己理解に関する発表でした。自分のマインドとの向き合い方に関するヒントを示す、あまり見ないタイプの発表で、興味深く聞くことができました。

www.slideshare.net


ISONO:Reboot ?なんで、私がベストスピーカー賞に??

技術論文の書き方を学ぶセッションでした。研究職でない方が中々論文を書くことはないかと思いますが、論文にすることで自分がやっていることを体系立てて整理・評価できることがメリットとして挙げられます。また、自分がやっている取り組みを査読という形で第三者から客観的に評価してもらえる、ということもすごく力になるとのことでした。論文を書きましょう!

www.slideshare.net


違いを捉えよう~場の力を引き出すカギを手に

ファシリテーションが得意な講師からは、「違い」に着目するワークが行われました。同じチームで些細なことからすれ違いが発生して上手くいかないときでも、共通点や違いを理解することで上手く活かす道が見つかるよ(意訳)という内容でした。一枚の画像から受けた印象を各自で出し合ったのですが、同じインプットをしているはずなのに、着目点の違いや表現の違いなどでもアウトプットが大きく変わる、ということを学べたワークでした。


ソースコードを読んでみよう

ソースコードをレビューして不具合を見つけてみよう、というワークでした。
ソフトウェアのシステムテストは内部構造に着目しないブラックボックステストが多いですが、ソフトウェアの内部を見ることでシステム特有の不備を見つけよう、という内容になります。
私は開発者なので、ソースコードレビューは比較的得意な部類でした。しかし、単純な不具合でも上手く意識できないと検出できない場合があり、得意だからこそ不具合を出さないように慎重に見ていく必要があると感じました。

www.slideshare.net


ユーザビリティテストをやってみよう!

アプリケーションの使用感について評価を行うユーザビリティテストのワークでした。二人ペアになって、テスト設計からユーザビリティテストの一連の流れを実際にやってみることができる、とても貴重なワークでした。ユーザビリティテストに必要な技法はインタビューのような対話に関する技術が多く、一般的なテスト技法とは違っていて新鮮味がありました。一時間ではもったいない、もっと時間をとった構成で受けたいと思うワークでした。

www.slideshare.net


コミュニケーションで大切なことは「伝わったこと」

コミュニケーションの難しさをお絵かきで体験するワークでした。一方が絵を口頭で伝えて、もう一方がそれを紙に書く、というのを行ったのですが、自分のイメージが上手く表現できない/伝わらないことを知ることができました。先に全体観を共有したり、既知の尺度(長さをcmでなど)表現するといったアイディアもたくさん出てきており、楽しみながら学ぶことができました。


みんなのメトリクス

業務であれば様々なデータを取っているかと思います。ここではデータ計測の意義について考えるワークを行いました。計測できるデータは何でも計測したくなりがちですが、計測するにもコストがかかります。「なんの為に測定するのか」をチーム内で議論して、測定したデータがどのように業務の助けになるのかを整理しました。データがどのように使われるかを知ることによって、ポジティブな感情で測定作業を行えるようになります。

www.slideshare.net


直交表に触れてみよう

膨大なテストケース数になりやすい「組み合わせテスト」に対して、効率的にテストケース数を削減できる「直交表」のワークでした。「直交表」は「実験計画法」に基づいて効果的なテストができる組み合わせを抽出する手法です。しかし、なぜテストケースを大幅に減らせて、できる限り高い効率の良い(バグを検出しやすい)テストケースを抽出できるのかが直観的に理解しにくいところがあります。本ワークでは直交表によって抜き出されたテストケースがどのようなものかを段階的に追っていくことで、初心者にも理解しやすい内容となっています。その気配りにワークを作る側として学ぶことが多かったです。

www.slideshare.net


インシデントレポート:Reboot

いわゆる「バグ票」とも呼ばれる、不具合結果の記録票の書き方についてのワークです。私は業務でインシデントレポートを書くことがほとんどないのですが、ワークのチーム内のテストエンジニアの方からは「タイトルで内容が分かるように記載する」「(効率のため)開発者とのやりとりが少なくなるように再現条件なども明確に書く」など、実体験に基づく話をたくさん聞けて、学びの多かったワークでした。

www.slideshare.net


設計品質とアーキテクチャ

最後は小井土さんによる、開発者目線からみた品質の話でした。特にシステムアーキテクチャについて語られていました。システムアーキテクチャとは、システムの品質特性を強制する目的で導入するシステム構造による仕組みを指してます。講演内では「レシピ(具体的な手順)」ではなく「ガイド(適度に抽象化された指針)」、という言葉が挙げられておりとても印象に残っています。ワークでは目的を達成するための「ガイド」の設計を体験することができました。

www.slideshare.net

www.slideshare.net


クロージング

クロージングセッションでは、参加者が最も加速感のあるポジショニングペーパーに対して投票を行い、ベストポジショニングペーパーが決まりました。今回は福岡からきて、全国JaSST行脚*1を行っている @yoshitake_1201さんが受賞しました。おめでとうございます!


おわりに

多種多様なワークショップがあり、内容だけでなく運営方法についても勉強になりました。良いところはJaSST東北にも反映できるように色々試してみたいと思います。
意欲にあふれた参加者や運営の皆様と触れ合うことで、こちらもやる気も頂きました。2018/5/25(金)のJaSST東北でも参加者に満足していただけるようなHAYST法のワークショップの準備を進めています。JaSST東北に参加していただく方々が加速する助けになれるように、精一杯頑張っていきたいと思います。

*1:JaSST'17 Tohokuにも来てくれました。感謝!

勉強会「バグ票の書き方・改善はじめの一歩」に参加しました!

こんにちは、実行委員のちまゆこと千葉まゆみです!
今回は勉強会の参加レポートをお送りしたいと思います。

 

参加させていただいたのはコチラ↓

connpass.com

 

バグ票ワーストプラクティス検討プロジェクトさん主催の、『バグ票の書き方・改善はじめの一歩』です。
参加者に求められるレベルがふと気になって、事前に主催メンバーのワニさんこと岡内さんに聞いてみたところ・・・「突き詰めると良い報告書の書き方だから、(初心者でも)いけるんじゃないかな」との回答。
「バグ票の書き方=良い報告書の書き方」という捉え方がとても良いなと思って、知人に宣伝しつつ自分も参加することにしました。


セッション1:ワークショップ『バグ票書き方・改善のはじめの1歩』

ずばり、良いバグ票ってなんでしょう?それに対する、悪いバグ票とは??

ワークショップではゲームやアプリのテストを想定し、実際にみんなでバグ票を書いたり、そのバグ票について考えたりするところから始まりました。

サンプルとして様々な「悪いバグ票」のサンプルを読み、どこが悪いか、何故悪いのかを岡内さんが解説。バグの書き方にも指針となる考え方、フレームワークがあるそうです。その具体的な内容をひとつ抜粋すると、バグ票が報告ではなく感情的な個人攻撃になっていないか、といったチェック項目は「Neutral(中立性)」という言葉で表されます。

一通りの解説が終わった後に、もう一度みんなでバグ票記載。解説にあったような様々なチェック項目を視点として持つことで、1回目のバグ票と2回目のバグ票を見比べると少しレベルアップできたような気がしました。 

 

f:id:jasst_tohoku:20171207025132j:plain

(写真:ワーク中のポストイット。中立性以外にも、色々な項目が。)

 

セッション2:事例発表『SQiPシンポジウムSIGワークショップの内容を自組織内でやってみた』

2017年9月に開催された、SQiPシンポジウム2017 SIG11で行なったワークを自組織で実施した際の事例発表とのこと。

スピーカーの城本さんは新横浜のベンチャー企業でQAエンジニアをされているそうですが、ベンチャー企業という社風のせいもあるのか、社員のみなさんのモチベーションが高く風通しも良い印象。テストの話だけでなくその環境が素敵だなと思いました。

自組織での開催はベテランや新人など異なるフェーズにいる方々が集まってのワークとなり、気持ちの良くないバグ票をサンプルとして集めたり、バグ票のフォーマットを考えたり、フォーマットが何故あるのかを話し合ったりしたそうです。

困ったバグ票を実際に読みながら、どうすれば改善できるのか、どういうフォーマットがあればよいかなど複数人で話し合うことで、お互いに様々な視点を発見できたということでした。

最後に城本さんが勤めている会社の「風通しの良さ」の秘密が書かれた書籍の告知がありましたが、組織のあり方に興味のある自分は、テストだけでなく全社的な業務改善の参考として読んでみたいなと思いました。

中でも城本さんオススメの業務ハック(?)は「花一輪(社員の誕生日に、他の全社員から1本ずつ花を集めて、花束を贈ること)」だそうです。笑

 

f:id:jasst_tohoku:20171207025532j:plain

(写真:アクロクエストテクノロジー株式会社 副社長 新免玲子さん著書)


最後に

いかがでしたでしょうか?レポートは訳あって簡潔にまとめましたが・・・その訳とは、こちらの勉強会の中でも特にワークショップの部分が、JaSST東海 S5-3 "バグ票カウンセリング" のプレイベントとなるためです!

全部書いたらネタばらしになってしまいますからね。。。今年のJaSST東海は、明日12/8(金)の開催なので、参加者のみなさまからのより詳細なレポートを楽しみにしています。


(千葉)

JaSST’18 Tohoku 準備始めました

JaSST'18 Tohokuの準備を着々と進めております。

 

今回は、アンケートでも皆さんが大好きなワーク中心で行きますよ!

実行委員で、どのようなワークが楽しんでもらえるか、試行錯誤中です。

 

ではでは、いったい何のワークをやるか気になっている方もいるかと思います。

来年の題材は・・・

 

HAYST法

 

です。

 

実際に秋山さんに来仙いただいて、勉強会を開催したりもしております。

(これについては、たぶん他の方がブログに書いてくれると思います。)

 

そんな感じで、皆さんにワークをとおしてHAYST法を学んでいただける

楽しいJaSST'18 Tohokuを準備中です。

 (ハードル上げてる気がするけど、気にしない)

 

私は、実行委員の中でもテスターではなく、

アプリ屋というか開発者の立場の人間ですので、

面白い感覚でHAYST法を学んでいます。

 

オブジェクト指向を学習した人は、オブ脳に目覚めるなんて言葉を耳にし、

その感覚を味わった方もいるかと思います。

それに似た感じで、テスト脳に目覚めそうな感覚を味わっております。

 

そんな感じで、JaSST'18 Tohokuで皆さんのテスト脳を加速させたいと思います!

(またもやハードル上げてるような気がするけど、気にしない)

 

来年のJaSST'18 Tohokuが楽しみという方は、

 

 2018年5月25日(金)

 

の予定を空けておいてくださいね!

 

そして、書籍を読んでおくと、より楽しめると思います。

 

こちらの白本を読んでいただければと思います。

 

より、興味がわいて直行表が気になる方は、さらにこちらの書籍がございます。

 

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

 

 

では、来年の5月をお楽しみに!

(竹内)

 

 

JaSST'17 Tohoku レポート

こんにちは。はじめまして。
JaSST'17 Tohoku実行委員のささきです。
大分間が空いてしまいましたが、2017年5月26日、JaSST'17 Tohoku 無事開催することができました。
地元からも遠方からも多くの方にご来場いただき誠にありがとうございました。
そして、基調講演と事例発表をしていただいたみなさま。
貴重なお話しありがとうございました。
私自身も勉強になるお話が沢山ありました。

今回のblogでは、そんなJaSST'17 Tohokuのレポートをお送りしようと思います。
なお、当日のスライドは下記に上がっておりますので、
今回参加できなかった方、気になるセッションがありましたら是非スライドをご覧になってください。

http://jasst.jp/symposium/jasst17tohoku/report.html#openning_s

今回のJaSST'17 Tohokuのテーマ :
「テスト分野における人財育成 ~テスト技術者は砕けない~」と
いうことで、育成についての基調講演、事例発表、ワーク等を通じて、
育成についての悩みを共有し、解決のきっかけを見つけて持ち帰って貰いたいということで、このテーマを選定いたしました。

■基調講演
「テストの極みを目指して
 ~さあ、理想に近づくための一歩を踏みだそう!~」
山崎 崇さま(ベリサーブ)


テストオペレーターからテストのプロフェッショナルへの最初の一歩を踏み出すためのお話をしていただきました。

(印象に残ったワード)

  • テストの価値は情報提供
  • 早い、安い、旨い
  • テストをこなすことにそんなに意味はない。適切な情報を適切なタイミングで提供することに意味がある。
  • ほかのエンジニアと違ってテスター≠テストの専門家ではない。テスターはテストの専門家であってほしい
  • Professional Tester's Skill-Space (TESTSKILL/ITSKILL/SOFTSKILL/DOMAINSKILL)
  • テスターは開発を加速させるための協力者というマインド
  • 最初の一歩を踏み出すために重要な3つのこと

  ①テストの全体感を持つ
  ②ロールモデルを見出す
  ③成長へのモチベーションを持ち続ける

 ①テストの全体感を持つについて

  • テストの全体感を持つための3つの軸(テストレベル/テストプロセス/テストタイプ)
  • 特に重要なのがテストケースを作るまでのイメージを持てること
  • (よくあるパターン)テスト設計技法を勉強したので、実務に適用しようとしてうまくいかない。テストベースに対していきなりテスト設計技法を使うのは失敗フラグ、テスト設計技法を使うためにはいろいろな前準備がある。いきなり使うことはできない。

 ②ロールモデルを見出すについて

  • 大まかな方向性を意識する(技術トラック/マネジメントトラック)
  • テストの専門性には様々な方向性がある。具体的にイメージできる憧れの人を持とう。
  • セルフデベロッププランを作ろう

 ③成長へのモチベーションを持ち続けるについて

  • 成長は目に見える形で測れて実感できることが大事。
  • 社外に飛び出す

(感想)

沢山時間をかけ推敲してくださったスライドは圧巻の一言。

テスターは開発を加速させるための協力者というマインド というところにすごく納得しました。私も目指しているテスターの姿です。対立ではなく、互いに協力できる関係でありたいです。

成長へのモチベーションを持ち続けるために社外に飛び出す についても共感しました。広い世界に飛び出していろいろな人と出会うことはとても刺激になりますよね。

事例発表1
「インキュベート修了者からの変化
~テストエンジニアへ進化するための成長プロセス~」
土岐 しのぶさま (ウェブレッジ)

ウェブレッジさんで実施している、社内教育制度「WRキャリアフレームワーク」と、成長プロセスについてお話しいただきました。

(印象に残ったワード)

  • テスト設計研修は「教わる」のではなく「考える」研修
  • 基礎編と応用編があり、

  基礎編 : 仕様書に書かれていることを整理する
  応用編 : テスト観点を洗い出し、構造化する(ワークを実施する)

 

(感想)

テストを極めるための多彩なキャリアパスがあることがとてもうらやましい。私はテストの研修というのを受けたことがほぼないため、こんな研修をうけられるウェブレッジの社員の方は幸せだなぁ。。。と、終始考えながらお話を聴いていました。

事例発表2
「テストエンジニア版RPG風スキルマップ」
根本 紀之さん (JaSST東北実行委員)

面倒なスキルマップを楽しくつけられるRPG風スキルマップの発表です。

(印象に残ったワード)

  • 「学習」を手助けするのが「育成」
  • テストエンジニア版RPGスキルマップ
  • ロールは 戦士、魔法使い、商人、僧侶、道具使い、盗賊
  • スキルマップは自分たちで再構築してみるとよい
  • 成長を実感させる方法の一つに褒めることがあるが、タイプによってほめ方を変えるとよい
  • タイプは4種類(達成者/探検家/社交家/殺人者)
  • 達成者 : 何かを達成することに喜びを見出すタイプ
  • 探検家 : 新しいことに挑戦したいタイプ
  • 社交家 : 人とのコミュニケーションに重きをおくタイプ
  • 殺人者 : 勝ち負けなど競争に重きをおくタイプ

(感想)
スキルマップは実施するのに時間がかかったり、つけることが難しかったりと、必要なことはわかるけどちょっと面倒なイメージを持っていましたが、RPG風のスキルマップを見て「こういう方法もアリなんだ!」と目から鱗でした。

簡単につけられてしかも楽しいところがとても気に入ってます。

事例発表3
「WACATEにおけるワークショップ開発の流れ」
朱峰 錦司さま (NTTデータ

スライドタイトルは「社内および社外活動におけるテスト研修開発・運営事例」ということで、WACATEのお話と、朱峰さんが業務で携わっている研修開発・運営のお話をしていただきました。

(印象に残ったワード)

  • 研修の役割とは学んだことを現場に生かすために間を埋めるもの
  • (事例1) 自社グループ向けに実践的なテスト設計研修を開発
  • 研修の対象者はテスト専任の方はまれで、基本的には要求定義~実装に関わっている方。
  • 2日間で完結するオールインワン。基礎編と応用編。
  • 応用編では詳細な仕様書を用意して実施している。
  • (事例2) 「WACATE」の運営
  • テスト設計に加え、素振り・実践がしにくいテスト分析をグループで演習できる場を提供
  • テンプレートを用いたセッション企画
  • 開催回ごとにホットな時事トピックを扱う
  • NextStepは中級者・上級者向けの施策
  • チームでの振り返り、プロジェクトをまたいだノウハウの共有・事例共有
  • シンポジウムやカンファレンスでの情報共有・事例発表
  • 自身・自社が扱うドメインになるべく近い題材にもとづいた実践的な研修が必要。
  • 座学だけでなく、実際に受講者がその場で手を動かしてテスト設計をする演習を盛り込むことがポイント。

(感想)

テスト設計の勉強をしてもそれを業務に生かせない、という悩みは実際によく聞くので、学んだことをどう使うかを知れる研修というのは、素晴らしいと感じました。
私自身はテストのことをよく分からないままテスト業務に放り込まれて、なんでこんなことやっているんだろう?と思っていたことを、テストのことを勉強するうちに「あ、だからこんなことやってるんだ!」と理解してきたのでとても時間がかかってしまったのですが、知識を得て、それを業務に近い形で体験して、実際に業務に入れるというのは
自分がやってきたことをとても短い時間で理解できるのだろうなと思い、素直ににうらやましいと思いました。
その分研修を実施するまでの準備は苦労は多かったと思います。


事例発表4
「テストエンジニアとしてキャリアを積み重ねて見えてきたこと
~ なにを大切にし、なにを変え、なにを変えなかったか ~」
山本 久仁朗さま (アカツキ

多くの企業を渡り歩いてきた山本さま自身が感じた、評価されるスキル、ポイントと
普遍的なスキルについてお話し頂きました。

(印象に残ったワード)

  • 現場の悩みで「テストのキャリアがない」、「テストが評価されない」、「キャリアアップの実感がない」
  • 組織ごとの評価ポイントには加点式/原点式と安定/変化がある。
  • クラシックなテスト技法は新しい会社では、意外とちゃんとやってない。
  • テスター・テストエンジニアの評価が効果的に行われていないのはなぜか
  • 評価するには可視化&合意が必要。つまり「説明責任」
  • 良い技術・手法が広まらないと業界損失
  • 評価される立場の人は組織カルチャーを認識し、スキルアップし、可視化・合意する
  • 評価する立場の人は必要スキルを再確認、組織特性を踏まえた評価方法を検討。
  • 評価の先には日本のソフトウェア産業の未来がある

(感想)
山本さんのお話を聞いていると、あ、テストってこんなにすごいものなんだ!そんなすごいことを自分たちはやっているんだと思えるので、すごく前向きになって、最後には「あー、明日からもテスト頑張らなきゃな」という気持ちになります。

テスター・テストエンジニアの評価がきちんと行われるための説明責任と評価方法の検討を今後自分も頑張っていかないといけないな。と思いました

 

ワークショップ
「状態遷移図(表)を作成してみよう」

状態遷移図の作成のワークを参加者全員で行いました。
作成したものは近くの席の人と互いに見せ合って確認しあいましたが、ほかの方の状態遷移図を見ると自分の考え方との違いが発見できて勉強になりました。

お題が皆さんが想像しやすい内容だったらか、ワイワイと盛り上がりながらワークに取り組んでいただけていたように思います。

 

お悩み相談会

今回の基調講演と事例の発表者の方々を参加者で囲みながら、参加者の日頃の疑問に答えたり、質問をしたりする時間を設けました。
どこの集まりも盛況で、発表者と参加者はもちろんですが、参加者同士で交流している姿も見られとてもよかったと思います。

 

■全体を通じての感想

アンケートの結果から参加者の方の満足頂けたのかな、ということが感じられたのがとても嬉しかったです。

テスターのキャリアについてどの現場でも結構悩んでいて、でもそのことについて話を聴ける場というのは少ないと思うので、参加者の皆様の今後のテスト活動において参考になる内容を提供できたならうれしいです。

 


今回参加された方は、是非次回もご参加いただけると嬉しいですし、参加していただけるイベントとなるよう実行委員一同頑張ってまいります。

今回は参加できなかった、という方も、次回は是非参加していただけると、とてもうれしいです。

それでは、みなさまありがとうございました。

JaSST’17関西 参加レポート

2017年6月23日に兵庫県いたみホールで開催されたJaSST’17関西に参加できたので,レポートします。

公式URL:JaSSTソフトウェアテストシンポジウム-JaSST'17 Kansai

今回のテーマは「アイ,テスト」で,AIをテーマとして開催されました。

募集人数の100人は満員になり,スポンサー参加を含めると110人と,東北の2倍の規模でした。テスト業界におけるAIへの関心の高さがわかりますね。

これだけ大規模なので,関西の実行委員の皆さんの準備は大変だったんだと思います。お疲れ様でした。

(注)最新技術がテーマなためか,予稿集が無くプレゼン資料の一部が公開されていません(3A問題発見セッション,私が参加しなかった3B-1,3B-2と招待講演のみ公開されてます)。

 自分の取ったメモと記憶を基にしたレポートのため,誤り等があれば訂正いたします。修正コメント等をいただければ幸いです

1.基調講演1「人工知能開発の問題点と品質保証について」細川宣啓さん(日本IBM

印象に残った点

 細川さんは最初に,AIによるプレゼン資料の自動編集機能をデモしてくれました。と言うのは嘘で,「AI」と聞くと無条件に受け入れてしまう我々への警告から基調講演はスタートしました。

・テストとAIの話題は,主に以下の二つに分かれます。これは基調講演2の増田さんも共通の意見でした。

   ・AIそのものをどうテストするか。

   ・AIによってテストがどう変わるか。

 

・AIに関する世界の動向について

細川さんの講演ではAIに関する世界の動向の説明があり,アメリカ議会においてスーパーAIは人類の脅威になるか,真剣に議論している事などを紹介してくれました。(その他にもAIに関する様々な話題がありましたがメモしきれませんでした)

 

・AIが人間に追いつくことができるか

今の時点では,AIが人間の脳と同等を処理を行うには,東京ドーム1.8個分のCPUコアと原発2基分の電力が必要であり,当分,人間に追いつくことは難しいのではないかとのことでした。

 

・AIそのものをどうテストするかについて

 AIの場合,期待値が予測できないため,テストが難しい。思考ロジックが学習により成長するので,答えが一定ではなく,テストが難しいとのことでした。

 

・アメリカで発生した自動車事故(失敗事例)について

 アメリカの事例で,画像認識による自動車の自動運転において,並行するトレーラーの色が背景の空の色と近く誤認識を行い,事故を起こしたケースが紹介されました。画像認識による自動運転では,前の画像と後の画像の差異を見て,背景なのか他の車なのか判断しているため,ほぼ同じ速度で走る背景と同じ色のトレーラーを誤認識してしまったそうです。現時点では画像認識だけの自動運転は難しく,赤外線センサー等を併用する必要があるとのことでした。

 

・AIの軍事転用と学習データの流出防止について

 AIを使ったドローン兵器の話もあり,AIドローンによる攻撃(自爆)後に,ドローンAIの学習データを盗まれない様にする研究も行われてるとのことでした。

 

・AIシステムの課題として,以下の点を上げていました。(資料上4点あったのですが,1点はメモしきれませんでした)

 ①学習データのデータポイズニングをどう防ぐか?(不正なデータで学習結果が使えなくなる。例:会話AIに対して差別的発言を繰返し,AIが差別的な発言をするようになる等)

 ②学習アルゴリズムに関して,入力データの偏りをどう防ぐか?そもそも偏らないデータを作れるのか?

 ③機械ベースの意思決定に関して,認識や分類の誤りをどう防ぐか?

 

・細川さんの現在の取り組みについて

細川さんが今,取り組んでいるAI技術として,昔の特撮アンドロイドヒーロー(ギター弾くやつ)の様に,普通の学習結果を出力する『良心回路』と,今までのNG情報から「AIの理解は失敗していないか?不快な結果ではないか?」等のチェックを行う『悪魔回路』の出力をあわせて判定する仕組み作りに取り組んでいるそうです。『悪魔回路』の処理は『良心回路』に比べて20倍程度の処理時間がかかるそうで,(良心回路の出力を悪魔回路が否定することで)答えが出ない可能性もあるそうです。現在のAIの課題を解決する提案として,とても面白い考え方だと思いました。

 

・最後に,細川さんが述べていたのが,AIは手段であり「結局,何がしたいのか?」によってAIが適しているのか,他の技術が適しているかである。「AIを使う」のが目的ではないので,「何をしたのか」をよく考えて欲しいとのことでした。私も手段と目的が逆転しない様にしたいと改めて思いました。

受講しての感想

・基調講演にふさわしく,AI技術以外にもAIに関する世界の動向など,幅広い話題にあふれた楽しい講演でした。懇親会で細川さんご本人に確認したところ,後日一部を除いて講演資料が公開されるそうです。公開されたら,色々調べてみたいと思いました。

(余談ですが,懇親会で細川さんと にしさんの掛け合いを見ることができたのですが,とても面白くて時間を忘れてしまいました。細川さんと にしさんが同じ懇親会に居る時は,お二人の近くに座ることを強くお勧めしますw)

2.基調講演2「人工知能技術を利用したアプリケーションの開発とテストについて」増田聡さん(日本IBM

印象に残った点

・増田さんの基調講演も以下の2点を中心に話されていました。

  • AIそのものをどうテストするか。
  • AIによってテストがどう変わるか。

・AIの処理構造について

遊園地にある音声認識アプリを例に,AIによる日本語認識と回答選択方法を丁寧に説明してくれました。AIの知識が無い私でも,とても分かりやすいものでした。

 

・今回の例(遊園地の音声認識アプリ)について

遊園地の音声認識アプリは,来場者が出す質問「ゴーカートはどこにありますか?」を認識し,来場者へ「○○にあります」と回答を行うアプリです。

 

・言葉の類似度の判断方法について

「ゴーカートはどこにありますか?」と「ゴーカートはどこですか?」は似た言葉であり,文章の類似度を測るのにコサイン類似度を使用します。

(https://ja.wikipedia.org/wiki/%E3%83%99%E3%82%AF%E3%83%88%E3%83%AB%E3%81%AE%E3%81%AA%E3%81%99%E8%A7%92 )

 

・判断処理例について

文章を形態素解析し単語に分解して,類似度を判断します。例えば,以下の3つの文書を分解すると

(a)ゴーカート / は / どこ / に / あり / ます / か?

(b)ゴーカート / は /どこ / です / か?

(c)入場料 / は / いくら / です / か?

<それぞれの文章と出現する単語表>

 

ゴーカート

どこ

あり

ます

です

入場料

いくら

(a)

     

(b)

     

 

 

(c)

 

         

 

(a)と(b)のコサイン類似度は 0.676

(b)と(c)のコサイン類似度は 0.3

になるそうです。この場合(a)と(b)が同じ意味と判断して回答します。

また,「ゴーカート」や「入場料」などの特徴的な言葉を「特徴ベクトル」として重み付けをするそうです。

 

・判断までの処理内容と,目標成功率の実現方法について

来場者の発言は,以下の処理を行い,AIが回答を行います。

  ①周辺環境(マイク等)→ ②(音声の)テキスト変換 → ③テキスト分類 → ④テキスト音声変換

 

  最終的な成功率を80%とすると,①~④の各工程の成功率は95%が必要となります。

  それを少しでも上げるため,②,④で特定キーワードをまとめることで,成功率を上げています。

 

 NG例として

  • 「ゴーカートはどこにありますか?」を「豪華はどこにありますか?」に②テキスト変換(誤変換)すると,回答が「イベンドは7月からです」になります。
  • 「ゴーカートはどこにありますか?」を「ゴーカードはどれにありますか?」に②テキスト変換(誤変換)すると,回答が「ゴーカートの持ち時間は15分です」になります。

 

・AIに対するテスト方法について

AIに対するテストは交差検証法を使うそうです。具体的には,学習予定のデータの一部を残しておき,テストデータとして使用し,期待する回答が返るか検証するそうです。

テストデータを学習させると100%期待回答を返してしまうため,学習しないデータをテストに使うそうです。

 

・AIの場合のV字モデルについて

AIの場合は,V字モデルの右側は,V字と言うより繰り返しになるそうです。

 

IBM Jeopardy challengeについて

IBMのAIがアメリカのクイズ番組に挑戦した「 IBM Jeopardy challenge 」の成果について,IBMは2012年に17の論文を公開しているそうです。なかでも興味深かったのが,クイズ番組は対人戦なので,AIが戦略を考え,終盤になってくると正解率が低くても,回答率を上げて得点を稼ぎに行くといった工夫を図っていたそうです。

https://www.ibm.com/watson/jp-ja/quiz/index.html

 

・AIを使ったバグ発生予測について

AIを使ったバグ予測も検討されているそうで,開発プロジェクトにおける各種メトリスクを,AIが学習できるようにデータラベルを付けて加工し学習させることで,その成果物におけるバグの発生量を予測する取り組みも行っているそうです。

 

・AIによるテスト設計の自動化について

仕様書からテストケースの自動作成について,人間が仕様書の記載内容を確認し,仕様書のなかでテストケースに出来そうな文章を分析して,類似度の高いものはテストケースを自動で作ることができるのではないか,ということでした。

受講しての感想

増田さんの講演は,AIの知識が少ない私にも,AIの内部処理構造等が理解でき,とても分かりやすい講演だったと思います。AIによるテスト設計の自動化についても,自動作成に向いた部分をあらかじめ人間が仕訳することで,ある程度自動設計ができるとの意見で,将来に期待が持てる気がしました。

 

3A.問題発見セッション「納得できるテストをつくるアプローチ(ワーク込み)~妥当な判断をするための問題発見方法と思考フレームワーク紹介~」水野昇幸さん(JaSST Hokkaido 実行委員会)

このセッションは講演資料が公開されてます。とても分かりやすい資料なので,是非ご覧いただければと思います。

https://www.slideshare.net/NoriyukiMizuno?utm_campaign=profiletracking&utm_medium=sssite&utm_source=ssslideview

印象に残った点

・納得できるテストの必要性について

我々はテスト設計結果について,顧客(お客さん)に納得してもらう必要があるとのことです。(当然ですが)

登場人物として,顧客,マネージャ,テスト設計者があるが,マネージャはテスト設計結果を説明できる必要があり,テスト設計者はテスト設計結果に自信が持てる必要があるそうです。

  

・納得できる証明とは

納得できる証明とは「主張が明確で,筋道がわかること」とのことです。(P.14)

「反論の余地が無く,裏付けが整理されており,知りたい事がダイレクトに答えて明快」なものだそうです。

個人的にはなかなか難しいと思いましたが,実現する方法を説明してくれました。

 

・納得を実現する方法

具体的には,主張-論拠のツリー構造を使うそうです。(P.15)

ツリー構造で考えることで,繋がりや論拠が明確になります。

また,ツリー構造により,全体的に考えて抜けがなく見えるそうです。

 

・重要なポイント

構造を考える上で重要な点として「テストケースは何らかの目的を持つ」ことです。(P.18)

そのため,テストケースを,目的-手段のツリー構造で整理することができるそうです。(P.21)

ツリー構造での整理(3段階で整理する)

  • ①目的 - ②手段/目的(①を実現する手段であり詳細目的)- ③手段(②の手段を実現する手段)

表現を変えると,

  • ①上位目的  - ②戦略目的 - ③手段

テスト用に表現を変えると,

  • ①テスト対象機能 - ②テストケース目的 ― ③テスト手段(テストケース)

になるそうです。

 

・テストケースの整理が難しい理由

以下の場合,整理が難しくなるそうです。(P.42)

  •  作業そのものになれていない。
  •  テストケース目的に対する知識不足(ドメイン知識やVSTeP観点出し)。
  •  テスト知識(テスト設計技法)不足。
  •  「目的と手段の思考方法」で考えることが少ない。

 

・目的と手段の思考方法について

目的と手段の思考方法の基本構造は,

   目的 ― 手段(+理由)

です。必要に応じて理由を記載してなぜこの手段を採用したか分かるようにするそうです。(P.47)

 

・目的と手段の思考方法における注意点について

目的-手段に関して,以下の様な失敗に注意が必要とのことでした。(P.52)

  • 循環論理:(例)知識をつけるために勉強する。
  • 手段の逆転:(例)TOEICで高得点をとるために英語を頑張る。
  • 手段の目的化:(例)チェックリスト項目を完璧にクリアする

 

・テストケースを整理するメリットについて

目的の無いテストケースはないため,この整理方法を利用すると重複が分かり,不要なテストケースを把握することができるそうです。(P.66)

個人的な意見ですがツリー状で整理することにより,テスト目的の漏れも気付く可能性も多いにあると思います。

 

・テストケース整理時の注意点について

注意点として「納得できるテスト」は「完璧なテスト」ではなく,作業者の実力通りになるそうです。完璧ではないが,その時点のベストを作ることはできるそうです。(P.71)

個人的には,その時点のベストができれば,十分じゃないかと思いました。

また,今回の構造的な「論理」を作っても,相手から信頼されていない場合は,納得を得られないことがあるそうです。(P.72)

 

・補足情報について

納得できるテストについては以上ですが,補足として,水野さんが興味深い事を教えてくれました。

(a)ツリー上に整理することによって,「分からないこと」が分かるのが重要とのことです。(P.112) 特に,自分が分かっていないことを理解していことを「愚者の楽園」と表現しており,とても面白く感じました。

(b)SFAA(全てのアメリカ人のための科学)に纏められた「科学的アプローチ」では,分からない事は,論理構造を明確にしながら一つずつ根拠を明確にしながら,仮設検証を繰り返して,明らかにしていくそうです。(P.113)

受講しての感想

ツリー構造を使って納得できるテストを作る手法は,興味深いものでした。

所々,VSTePの紹介も交えながら,水野さんの軽快なトークに引き込まれて,あっという間に時間が過ぎました。水野さんは本日の講演以外に問題解決手法等の講演もされており,他の講演も聞きたいと思いました。

3B.テクノロジーセッション

テクノロジーセッションは私は参加できなかったので,講演資料のリンクのみ記載します。

 

・3B-1「サービスデザインの時代~顧客価値をビジネスに~」

長谷川 敦士さん(コンセント)

講演資料

https://www.slideshare.net/atsushi/ss-77256833

 

・3B-2「AIとテストパターン~AIを適用した製品・サービスに対してテストをどのように組み立てていくか~」徳 隆宏さん(オムロン

講演資料

https://www.slideshare.net/tokutaka/jasst-kansai-2017-ai-ai-and-testing-pattern

 

4.招待講演「UI自動テストツールとAI」~AIを使った自動テストの「今」と「未来」~ 伊藤望さん(TRIDENT)

伊藤さんの講演資料も公開されてます。

https://www.slideshare.net/NozomiIto/uiaiai

印象に残った点

・伊藤さんは,スマホ等のUI自動テストツールを開発しているそうです。現在β版で提供されているそうです。

http://blog.trident-qa.com/2016/10/introduce_magic_pot/

 

・今後のAIの利用シーンについて

今後,定型的な作業はAIが実施するように変わっていくのではないかと話してくれました。

 

・AIが実施するテスト領域について

  • テスト設計は,非定型なため AI化は難しいそうです。
  • テスト実行は,定型なため AIツール(Magic pod等)を利用できるそうです。

 

・アプリの自動テスト(Magic pod)について

 画面を入れると画面部品をサジェストしてくれる。

 画面部品に対して「クリック」や「キー入力」を指定してテストケースを作成していくそうです。

  

・Magic podの画像解析について

画像解析AIは人間の思考ベースで考えたそうです。画像要素をどう探すかというと,ボタン等は見た目で探しており,入力領域はUI要素のラベルから特定しているそうです。

アイコンやボタンを見た目から特定するのにディープラーニングで,2000枚~3000枚の画像を学習させるそうです。画像の種類を人間が指定して学習させるそうです。学習ロジックの中にランダムな処理(確率的勾配降下法)があり,AIがどう学習したかはブラックボックスになるそうです。

 

・画像解析AIのテストについて

解析エンジンのテストは交差検証を使って,学習データの1部をテストデータとして使い,正解率で解析エンジンの性能を測るそうです。

 

・AIの判断間違えについて

Deep Learningは人間と同じ間違えをするそうです。MagicPodのテストでは,正解率の確認と基本ケースのテストは全部行い,間違った判断をしないか確認するそうです。

 失敗した時の対策としては,以下の様なものがあるそうです。

(a)間違えたデータを学習データに加える。

(b)とりあえず再学習させてみる。

(c)諦める。(そのままにする)

(d)機械学習ロジック自体の見直し。

 

・AIの使い所について

AIの使い所としては,以下の様になるのではないかとのことでした。

(a)不安定さを許容できる処理。

(b)人間よりAIの方が精度が良くなる処理。

 

・Magic podの最終目標について

最終的に人間の書いたテスト設計結果を,AIが理解してテストスクリプトへ落として自動実行にしたいそうです。

 

・AIによるテスト自動化の範囲について

AIによるテストの効率化は色々可能だが,完全自動化は当面無理とのことでした。テストの完全自動化が実現した時には,システム開発の仕事は全て自動されているだろうとおっしゃってました。テスト設計の自動化は,AIが常識を読み取る必要があるそうです。

 

・AIによるQAの変化について

AIによりテスト実行などの定型作業は今後減るのではないか。その分,QAはテスト設計などの創造性の高い仕事ができるとのことでした。

テストにおける単純作業がQAの地位を下げている面があり,AIにより単純作業が無くなり,スキル勝負の世界になればQAの地位が上がるのではないかとのことでした。QAの未来は明るいとおっしゃってました。

受講しての感想

AIを活用したツールを制作している伊藤さんのお話しは,AIをとても身近に感じられました。また,AIによってQAの地位が上がるとの,非常に心強いお話しが聞けて,JaSST関西のまとめとしても良かったと思いました。

 

5.運営について

JaSST関西の運営で、良いと思った点です。他にも色々あると思いますが、気付いたのはこの位でした。次回の東北の運営でも参考にさせて貰う予定です。

 

・前日の会場作り:

 100人規模だから必須なのでしょうが,前日の夜に会場をセッティングしていました。これなら当日の朝にバタバタしないで済むと思いました。残念なのが,前日の夜に勉強会等を企画できない事ですね。どっちを優先するか悩み所です。

 

・名簿順の受付と申し込み順の受付:

 JaSST関西の受付のお手伝いをした時に,申込み順の名簿の他に,あいうえお順の名簿があり,申込み番号が分からない参加者が来た時に,素早く見つけることが出来る様になってました。東北でも次回から準備したいと思います。

 

・プリンタ持ち込み:

 会場にプリンタを持ち込んで,必要な印刷物をその場で作成してました。もちろん,印刷物は事前に準備した方がいいのですが,当日追加で欲しくなる場合もあるので,会場へのプリンタ持ち込みは便利だと思いました。

 

・情報交換会の全員参加:

 東北では情報交換会は事前申し込み制ですが,関西は全員参加を前提にしており,お茶等を全員分準備してありました。また,全員参加が前提なので,情報交換会の後に招待講演がある構成でした。ワークショップによる時間延長等を考慮した構成だったと思うのですが,最初から全員参加という割り切りも良いと思いました。(東北では当日になって参加を希望する方が毎年いるので)

 

以上。JaSST関西実行委員の皆さん,講演者の皆さん,楽しい一日をありがとうございました。

 

(記)高橋