yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

「ゆるっとIT vol.10 ソフトウェアテストの話を聞こう」で発表させてもらった #yurutto_it

イベント参加レポート

f:id:yoshitake_1201:20190405194005p:plain

f:id:yoshitake_1201:20190405194027p:plain

イベント概要

ゆるっとIT vol.10 ソフトウェアテストの話を聞こう
yurutto-it.connpass.com

※ 会場提供してくださったさくらインターネットさんがビールなど提供してくださいました。
ありがとうございました！
ビール美味しかったです。

発表資料

speakerdeck.com

発表のきっかけ

ゆるっとIT主催の井関さんから「ソフトウェアテストの話聞きたい！」と声をかけていただきました。
なんの話する〜？と相談して、井関さんにはテストの話をいっぱいしました（笑）
あの時の話…相当散らかってましたね。
井関さんは聞き上手だと思います。
そこからいくつかtopicを頂き、今回の発表内容となりました。
（頂いた全部発表しきれなくて申し訳ない…）

もうちょっと紹介したかった内容

まだまだいっぱいあるんですけどね…。
その中から少しだけ、↓に記事や資料を載っけときます。

testingとcheckingの違い

www.infoq.com dev.classmethod.jp

コードの臭い・不吉な臭い

ja.wikipedia.org

objectclub.jp

テストって実行だけじゃない

f:id:yoshitake_1201:20190405192825p:plain
テスト設計チュートリアル U-30クラス向け 2019年度版 P65より

※ 資料
aster.or.jp

JaSST'19 Tokyoのブログ

以下に私が書いたブログのまとめリンクがあるのでぜひ（笑）

yoshitake-1201.hatenablog.com

個人的な反省点

発表時間をオーバー。。。
まるっとtopic 1つ分足りませんでした。
今後気をつけますm( )m

参加者の方のスコープをある程度絞っていたつもりだったんですが甘かったですね。
rinaさんが良い質問をしてくださいました。 ありがとうございます！
「前提知識」をどう定めるかが難しいです。

また、一般参加してくれてた@saeからは「早口だった」というのをもらったので気をつけます。
たしかに早かった。

あと、質疑応答！
ブレブレになってしまったので、いい回答できるようになりたいです。
JaSSTで登壇されていた方々…やはりすごいです。

感想

今回参加してくださった方々の多くが「開発者」で、メイン業務が「テスト」って方は5人ぐらいだったんですよね。
もともと参加者の想定が「開発者 ≒ プログラム書く方」と聞いていたので、ユニットテストに焦点を当ててみました。
ユニットテストを書くときによく聞く悩みを整理、また悩みに対する考え方などを整理できて個人的には良かったです。

こういった勉強会がきっかけになって開発とテストでもっと交流していけたら良いですね。
勉強会に参加してくださった方がテスト酒場やテスト系の勉強会にも来ていただけたら嬉しいなぁと思いました。
（次の開催日未定なんですけど…（笑）)

では最後になりますが、勉強会来ていただいた方々ありがとうございました！
井関さん、呼んでいただきありがとうございました！

Mac上でIE8、IE9、IE10、IE11、Edgeを使う方法

テスト小ネタ テストに役立つツール

IEとEdgeを使える仮想マシンが公開されている

forest.watch.impress.co.jp developer.microsoft.com

Microsoftが無料でIE8 ~ IE11、Edgeの仮想マシンを公開しています。
利用可能なブラウザ&OSは以下。

方法

  1. 好きなプラットフォームをインストールする
  2. 以下から仮想マシンをダウンロードする(Step.1のプラットフォームを選択する)
  3. Step.1の仮想環境でStep.2のイメージを起動する

※ 90日の有効期限がついているので、起動後（日本語化の設定後）にスナップショットを作成しておいたら便利です。
※ 公式ページにそう書いてくれています（優しいMicrosoft）

These virtual machines expire after 90 days. We recommend setting a snapshot when you first install the virtual machine which you can roll back to later.

以下設定に際して便利な記事です

qiita.com
replication.hatenablog.com
eng-notebook.com
pc-karuma.net
answers.microsoft.com
qiita.com

感想

社内の方に教えてもらいました(^^)
便利ですね。
IEしか再現しないバグのときに実機のWindows PCと一緒に動作させて比較してみたんですが、どちらもちゃんと再現してくれました（当たり前ですね）。
個人的なデメリットは「起動に時間がかかる」「画面が専有される」「メモリ喰う」でしょうか。
なので日常的にはEdgeやIEは実機PCでテストしてます。
手元にWindows10実機がないけど急ぎで確認しないといけないとき…など突発なときは仮想マシン起動してます。

まぁ状況次第で使い分けたらいいかなぁって思いました。

おまけ(IEやEdgeまわりに関係する記事)

japanese.engadget.com japanese.engadget.com

JaSST'19 Tokyo 参加ブログ(個人的全体まとめ)

JaSST JaSST19Tokyo イベント参加レポート

セッションごとに個別にまとめたブログ一覧

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

JaSST'19 Tokyo 2日間の参加ブログ（個人的全体まとめ）です。
ただのポエムです。
以下、参加してよかったこと（順不同）です。

Testing ManiaXを手に入れられた！

WACATEのブースでTesting ManiaXを販売していたんですよ。
自分がテスト業界に入る前に発行されていた同人誌なので、もう手に入らないだろうなぁと思ってたんですが、まさか手に入れることができるとは！
vol.1 ~ vol.9の取扱いがあったので全巻即買いしました。
wacateの方々（特に並木さんかな？）ありがとうございました！

※ Software Testing ManiaXとは？
サークルWACATEが2009年 ~ 2015年の間に刊行していたソフトウェアテストに関する同人誌です。
テストに関わる様々な方が寄稿されていました。
全10巻です。

※ WACATEとは？
テストエンジニアを加速させるためのワークショップです。
次回は6/15(土) ~ 6/17(日)開催とのことです。
wacate.jp

自分の頭の中の整理ができた

自分なりに考えながら日々テストに取り組んでるんですが自信が持てないこともあったんです。
「こうした方が良いんじゃないかな〜」と考えてやってるんですが、「これ大丈夫かな？」と不安になってくるというか（笑）。
だけど「テストプロセス改善」、「QA入門」、「テストマネジメントの鉄則」などのセッションに参加したおかげで、ある程度頭の中を整理できたなぁと思いました。 また自分がやってることに対して「」自信を持つことができました。

「テストマネジメントの鉄則」セッションでの湯本さん、町田さんの発言は特に刺さりました。
「自分のことを言っているのではないか？」と思うほどに…。
そんなわけないんですけど、けっこう業界として「あるある」なことで自分は悩んでいたんだなとわかりました。
共感しすぎてセッションの後半ずっとヘドバンしていたレベルで頭振ってました（笑）。

たくさんの方と交流できた

お世話になってる方々とお話できるのがやはりいいですね。
SNSでよく交流させてもらってますが、リアルだからこそ…っていうのはあります。
セッションの内容についても議論・意見交換することができますし。
また、ありがたいことに今回、情報交換会でたくさんの方に話しかけに来てもらったんですよね。
本当ただただありがとうございますでした。

また今回は同じテストチームの@sae(@sito_110)が一緒に参加してたので、相互に@saeを紹介できたのはかなり嬉しかったです。

チームメンバーと一緒にJaSSTに参加できた！

私はこれまで基本1人でJaSSTに参加してたんで、同じチームのメンバーと一緒にJaSSTに参加するっていうのは初めてだったんですよね。
（実はJaSST'17 KyushuやJaSST'18 Kyushuで経験あるんですが、実行委員だったりなんだりがあるので個人的にそれはノーカウント）
あと、実は今回開発チームのメンバーも1人参加してくれていたので弊社からは3名が参加していました。

1人で参加するのも勉強になるので良かったんですが、チームメンバーが一緒に参加してくれるというのは更に良いですね。
お互いが別々のセッションに参加したときはそのセッションの話を聞ける、同じセッションに参加したときは深く議論できる、という。

JaSSTが終わってから空港へ行く途中や会社に戻ってからのふりかえりなどなどで話が尽きませんでした（一緒に行動していた@saeがそれで喜んでいるかは話が別です。 たぶんうざがられてもいると思います）。

2人以上で参加されていた方々はこれまで、こんないい経験してたんですね。
羨ましくなりました。

感想

参加できてよかった。というのがただただ感想ですね。
語彙力が残念です。

東京は昨年から続いて2回目の参加だったんですがやはり規模がすごいですね。
また、今年はパネルトークが多かった印象で、現場や業界最前線で取り組まれている方のお話を聞くことができたので知見を広く得ることができたと思いました。

基調講演に海外の方を呼んでくださるので世界の話が聴けるというのもかなりいいですね。
昨年に続いて自分の現状との差が大きくて、頑張っていきたいなぁと思いました。

講演者の方々、実行委員の方々、お話してくださった方々、ありがとうございました〜。

JaSST'19 Tokyo C6「FLシラバス2018のポイント解説！！」の参加ブログ #JaSST19Tokyo #JaSST #jasstc6

JaSST JaSST19Tokyo イベント参加レポート

講演内容

タイトル：「FLシラバス2018のポイント解説！！」
jasst.jp

講演資料

www.slideshare.net

講演中のツイートまとめ

togetter.com

JaSST'19 Tokyo、C6「FLシラバス2018のポイント解説！！」の参加ブログです。
講演中に私がおぉ！と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。
※ 念のため。
このブログはASTERやJSTQB公式のものではありません。
yoshitakeの個人のブログなので、もしあれ？と思った場合は公式シラバスやスライドを参考ください。
（というか思わなくても公式シラバスをみんなで読みましょう（笑））

では、以下まとめです。

シラバスの適応タイミングと資格取り直しについて

資格の取り直しは不要

とりあえずよかったです。
ただ、シラバスをちらっと読んだ感じ用語の変更、というのがかなり大きい変更だなぁと思いました（説明資料にもありますけど）。
なので、再度勉強します。

次回2019年8月に行われるJSTQB FL試験では旧シラバスに準拠

f:id:yoshitake_1201:20190404123712p:plain
講演資料P12より

シラバス切り替え時期は重要ですよね。
すでに勉強している方は8月に滑り込んだほうが…とも思うし、どうせなら新シラバスで…とも思うし。
難しいところですね。

主な変更点は5つ

f:id:yoshitake_1201:20190404123649j:plain
講演資料P6より

  1. 本質的なことは変わってない
  2. レビューについて多く取り扱うようになった
  3. ブラックボックステスト技法が詳しくなった
  4. ホワイトボックステスト技法の多くが対象外になった
  5. 用語の変更

変更点とありながら 「本質的には変わってない」 というのが良いですね。

レビュー技法が追加された

f:id:yoshitake_1201:20190404123653p:plain
講演資料P8より

  • アドホックレビュー
  • チェックリストベースドレビュー
  • シナリオベースドレビュー
  • ロールベースドレビュー
  • バースペクティブベースドリーディング

5つの技法が追加されたそうです。
旧シラバスではプロセスに重きをおいていたけど、今回からはレビューの仕方も重視するようになったとのこと。
個人的には「アドホックレビュー」と明記されたのが良いなぁと思いました。
人と話すとき便利になりますね。

レビューといえばJaSST Reviewもありますし、直近ではJaSST'19 Hokurikuで安達さんのセッションもありましたね。

jasst.jp

jasst.jp

ブラックボックステスト技法についてガイドはもういらない!?

f:id:yoshitake_1201:20190404123659p:plain
講演資料P9より

技法の説明が旧シラバスよりも充実したので不要（かも）とのことでした（笑）
この部分、新シラバスと旧シラバスを比較してみたんですが、文章が全然違いました。
月並みな感想ですが新シラバスのほうがよりわかりやすくなっていると思います。
特にデシジョンテーブルテストについては、書き方（条件やアクション）まで記載されているのですごく丁寧だなぁと思いました。

ホワイトボックステスト技法がFL対象外に

上記内容がK4からK2レベルに引き上げられたそうです。
この部分も新シラバスと旧シラバスを比較してみたんですがかなり変わってましたね。

個人的には、旧シラバスでは「ホワイトボックステスト技法」は「コードやプログラムを書く」という部分にけっこう踏み込んでいて、FLの他の項目と経路が違うなぁと思っていたので、今回対象外となったことに納得感がありました。

用語変更がある

f:id:yoshitake_1201:20190404123705p:plain
講演資料P11より

国際規格だからなんでしょうが、ISTQBとしての変更とJSTQBとしての変更と2つの軸があるんですね。
2つの視点が大変だよなぁと思いました。

用語変更について身近なところでは「同値パーティション」という言葉が目立つなぁと思いました。
昨日実際に使ってみたんですが少し違和感がありました。
慣れるまで時間がかかりますね（笑）
この「同値分割」については湯本さんのブログを参考に！とのことでした。

note.mu

感想

湯本さんが「世界と戦っているんだ」と言われたのががかっこよかったです。
シラバス変更の大変さや変更にかける思いの片鱗を見させてもらったなぁと感じました。

新シラバスですが、JaSST'19 Tokyo終了後に公開されたので、1度読んで見てこのブログを書きました。
講演で説明もありましたが「本質的には変わってない」と思いました。
しかし文章は多くの部分で変わっていました。
（変わっていたのですが、私個人としては読みやすく & わかりやすくなった印象を持ちました）
また 探索的テストなども節をとって説明されるようになったりしていたので、かなり今風になったと感じました。

個人的なことなんですが、「新しいシラバスが公開される」ということを知ってですね、公開後ワクワクしながらシラバスを読んだんですよ。
ただ、まさか自分がJSTQBシラバスをこんな気持で読む日が来るとは… という感じでした。
JSTQBを初めて勉強したときには考えられなかったです（当時：2年半ぐらい前なんですけどね…）。
（当時、シラバスはただただ難しいとしか思ってなかったので…（笑））

ただ、今は新シラバスのABD(Active Book Dialogue)とかやってみたいと思うぐらいには、シラバス理解したい欲が強くなりました。
みんなで読み合わせしてみたいですね。

湯本さん、講演ありがとうございました！

参考

JSTQBシラバス jstqb.jp

JaSST'19 Tokyo D4「QA入門セッション」の参加ブログ #JaSST19Tokyo #JaSST #jasstd4

JaSST19Tokyo JaSST イベント参加レポート

講演内容

タイトル：「QA入門セッション」

jasst.jp

講演資料

JaSST'19 Tokyoイベントレポートで公開されると思います。

講演中のツイートまとめ

togetter.com

JaSST'19 Tokyo、D4「QA入門セッション」の参加ブログです。
講演中に私がおぉ！と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。

以下、まとめです。

トラディショナルなQA（秋山さんパート）

そもそも品質とは？

以下2つの定義をしている方がいる。

※ SQiPやASTER標準テキストにも書かれている。 www.juse-sqip.jp

aster.or.jp

要求仕様書の項目に全て○がつけばいい品質？

そうではない。
受け取り手のことを考えましょうというのが品質。

※ この議論は以下のイベントを参考にするといいかと。
nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

品質保証できているとは？（〇〇の△△は、××）

簡単な演習がありました。

問：〇〇の△△は、××という文で、それぞれ以下を参考に埋めてください。

〇〇: 自社の名前
△△: 商品名やサービス名
××: 提供している価値（広く信じられていること)

このとき 「××に書いたモノ、あるいはコト」が「〇〇の△△に対して品質保証できている」となる。
ここで、××が書けなかった人 → 1年後にかけるようになりましょう。
××が書けた人 → もっと良いものにしましょう: これを「品質改善活動」と呼ぶそうです。
とのことでした。

「1年後」というのが気になったのですが、この後 品質保証は継続的な取組み という説明をしていただいたので、価値と呼べるようになる・品質が保証されているというのには1年ぐらいはかかるのかなぁと思いました。

品質保証とはお客様へ提供する価値の約束

f:id:yoshitake_1201:20190404123149p:plain
講演資料P10より

「品質保証とはお客様へ提供する価値の約束」
これが秋山さんの品質保証ということの理解だそうです。
私の中で特に印象的だったのは、「品質保証は一つの製品ではなしえない」「品質保証は誰かの頑張りではない」でした。
継続しなければ品質保証とは言えない・品質保証は品質保証部だけが頑張ることではない。
ただ聞くと当たり前だよなぁと感じたんですが、とても深い言葉だなと思いました。

品質保証活動は組織的活動

f:id:yoshitake_1201:20190404123154p:plain
講演資料P12より

この図にもある通り、品質には以下の3つに分類されるそうです。

  • 商品品質
  • 業務品質
  • 企業品質

それぞれの品質では、良い/悪いの指標や見える(関わる)人が異なるが、それぞれの当事者意識がないと品質は上がらない（保証できない）ということかと思います。

余談になりますが…@saeも自分と一緒にこのセッションを聴講していたんですよ。
そこで理解を深めようと、JaSST終了後に社内でこのセッションについてふりかえりをしたんですが、この図を見ていたときに自分たちが理解できていない…ということに改めて気づきました。
パッと見簡単に理解できそうな気がする（また、講演中は理解した気になってた）んですが、なかなか難しい部分でした。
奥が深いです。

品質保証部は偉いのか？

f:id:yoshitake_1201:20190404123203p:plain
講演資料P13より

品質保証部の位置づけとして↑のように社長の直下に位置づけられることがあるそうです。
ただこれは品質保証部が偉いからというわけではなく以下の2つの理由からこの位置づけになっているそうです。

  • 全社的な活動を行うため
  • 組織全体のレベルを引き上げるため

品質の話はお金にしないと経営者は理解してくれない（ことが多い）

f:id:yoshitake_1201:20190404123207p:plain
講演資料P15より

品質向上を行う場合、どこから取り組むべきか？どこに注力するべきか？
という点について、コストを分類 & 現状を把握すべき、ということでした。

コストの種類は資料にもある通り4つです。

  1. 外部失敗コスト
  2. 内部失敗コスト
  3. 評価コスト
  4. 予防コスト

まずはこの4つのコストについて、現状分析を行いどのコストが一番大きいかを知ることが大事。
そうして今の会社（またはチーム）の成熟度を確認し、↑の順に改善に取り組んでいくと良いとのことでした。
コストの分類、対応の優先度について知れたことが個人的にとても良かったですね。

※ 参考
http://www.f.waseda.jp/yito/quality%20cost1.html

先進的なQA（中野さんパート）

講演のトピックは4つ

  • 新しいテクノロジーへの対応
  • 価値基準の変化
  • DevOpsのその先
  • モチベーションを阻害しない組織へ

新しいテクノロジーへの対応

テクノロジーの進化により製品やサービスは、さらに複雑度を増すことになる。
テクノロジーの性質により課題は異なるが、個々の組織だけでなく品質保証やソフトウェアテストの業界内で研究や議論を進めていく必要がある。

新しいテクノロジーの例として、Gartnerから5つほど品質保証に関係しそうなものを抜粋 → 説明してくださいました。
↓は、中野さんがGartner: Top 10 Strategic Tecnology Trends for 2019 より抜粋された項目

  • AI -Driven Development（AI主導開発）
  • Autonomous Things（自律的なモノ）
    • ロボット、ドローン、自動運転などの「自律的なモノ」+「AI」の融合
  • Empowered Edge（エンパワードエッジ）
    • エッジ: 人々が使用するエンドポイントデバイス
  • Immersive Experience（没入型エクスペリエンス）
    • 仮想現実（VR）・拡張現実（AR）・複合現実（MRS）
  • Blockchain（ブロックチェーン）
    • 分散台帳管理

このブログでは↑の5つから2つほど抜粋します。
Empowered Edgeについて。
一般のユーザからすると便利だがその実はデータ構造が複雑になる → テストが困難・複雑になる、といった指摘をされていました。
ブロックチェーンについて。 ミッションクリティカルな領域になり、その領域にテスト（QA）が介入していくことになる。
こういった「ミッションクリティカル」なものが増えてきている現状で、テストを行っていかないといけない。

なので、新しいテクノロジーに対する研究・議論が必要とのことでした。

※ 参考
www.gartner.com

www.atmarkit.co.jp

価値基準の変化

製品品質だけでなく、利用時品質にも責任を持つために必要な仕組みを考え、評価軸を定義し、組織全体で改善できるように取り組むことが重要だと思われる

製品品質から利用時品質へ

f:id:yoshitake_1201:20190404123213p:plain
講演中の資料より（※ Priority #3 → #1 という優先度になっています）

使用性のテストが疎かになっている（評価されにくい）現状がありますよね。
もっとそこを追求し、顧客満足度のつながりを考えましょう！とのことでした。

ちなみに、中野さんが社内の専門家に「なんで使用性って評価されにくいのか？」と聞いたところ「人間の特性に関する勉強（情報）が圧倒的に不足しているから」という回答をもらったとのことでした。
デザイン = センス といったような認識の方が多いけど、実際はそうではなくて様々な理論に基づいていることなので、勉強していったほうが良い、とのことでした。

DevOpsのその先

品質保証組織がDevOpsの文化の中でリリースの高速化やテストの最適化など貢献できる可能性がある。
さらにその先には構築した仕組みなどが技術的負債になる可能性も考えられる。
その上でそれらを踏まえた中長期的戦略を企てる必要がある。
（DevOpsに取り組む組織、チームが多い中「QAがDevOpsに入っている（含まれている）」という事例が少ないと感じている現状に対して）

なぜQAがDevOpsに入らない（入りにくい）のか？

以下2つが考えられるとのこと。

  • 当事者意識の不足
  • 技術不足

たとえばデプロイメントパイプラインについて。
開発側がこういうのをやろう！としたときに「テストには関係ないと思って」QAはあまり関わろうとしていない。
しかし、デプロイメントパイプライン = リリースに直結している。
また、CI/CDを使い開発者がテストの管理を行いだすことにもなってくる。
そういうときにQA側の知識はすごく役に立つはず。
なのでそこに加わり提案していくことは重要、ということでした。

しかし、加わったとした（加わろうとした）とき、QAでありながらデプロイメントパイプラインを構築できる人はとても少ない。
なのでそうした技術の不足を補っていく必要がある、とのことでした。

※ 参考
bliki-ja.github.io

codezine.jp

cloudbees.techmatrix.jp

モチベーションを阻害しない組織へ

QCDや生産性を高めていくために品質保証組織が開発組織との関係性のあり方を考える。
相互に尊重しあえる関係性を築くために議論していく必要がある。

「モチベーションを維持するために品質保証組織は開発組織とどう関わるべきか？」
という問いを提示され、この問に対して中野さんは以下の2つの案を提案されました。

  • マイクロマネジメント型QA
    • 問題の発生を防ぐために業務プロセスを細かく手順化し管理する
  • サーバントマネジメント型QA
    • 自分たちのことは自分たちで考えて実施させ、不足や要求に対して必要なサポートをする

※ マイクロマネジメント型QA、サーバントマネジメント型QAというワードは中野さんがこの発表で定義した言葉です。

どっちが良いか？と参加者に挙手を求められたのですが、「サーバントマネジメント型QAがいい」という方が多かったですね。
私もこっちに手を上げました。

ただ、同じ現場（メンバー）だとしてもチームの成熟度や状況に応じて変わるので模索・議論していかないといけないなぁ…と思いました。

感想

品質とは、品質保証とはなにか？を知る & 整理できてよかった！と思いました。
秋山さんのパートでは、JIS、SQuBOK、PMBOK、TQM、ISOなどなど、品質・品質保証・品質管理について様々なもので定義されているんだなぁ…と驚きました。
まだまだ勉強しないとですね。
ただ、自分がこれまでもやもやとしていたところに「こういう定義があるんだよ」と教えていただけたことがとてもありがたかったです。
（個人的には、品質の分類を知れたことがとてもありがたかったです）

中野さんのパートでは、新しいものや日々変わっていく現状に対してどう向きあうのか？という中野さんの考えの一端を知ることができてよかったです。
技術のことだけでなく、プロセスのこと、人間関係のことなど本当に様々なことを考えられていて、ただただすごいと思いました。
私も自分の現場でもっと考えていこうと思います。

秋山さん、中野さん、ありがとうございました！

JaSST'19 Tokyo 基調講演「AI-Driven Testing: A New Era of Test Automation」の参加ブログ #JaSST19Tokyo #JaSST

JaSST JaSST19Tokyo イベント参加レポート

講演内容

タイトル：「AI-Driven Testing: A New Era of Test Automation」
jasst.jp

講演資料

JaSSTイベントレポートで公開されると思います。

講演中のツイートまとめ

こちらでまとめられてました。

togetter.com

JaSST'19 Tokyo、基調講演「AI-Driven Testing: A New Era of Test Automation」の参加ブログです。
講演中に私がおぉ！と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。
※ また英語での講演だったこともあり間違ったことが載っている可能性が、他のブログよりも多分にあります。
ご注意ください。
あくまで自分用にまとめたものです。

以下、まとめです。

テスト自動化とは言っても結局マニュアルテスト

現在の「Automation」は自動化とは言ってもどこかに「マニュアル = 手動」が入っている。
テストを考える部分、コードを書く部分、テスト結果を確認する部分などなど。
なので完全自動化は実現できていない。

AI Testというのは3つの段階（種類）がある

  • AI-Driven Testing (AI駆動テスト)
  • Testing AI Systems (AIシステムのテスト)
  • Self-Testing Sysytems (自己テストシステム)

今回は 「AI-Driven Testing」についての発表でした。

カバレッジギャップを埋める

現状は、ソフトウェアの複雑さ（Software Complexity）とテストカバレッジ(Conventional Test Coverage)に開きがある。
AI-Driven Testingでは、このカバレッジのギャップを埋めることを目的としている。
ここで重要なのはAI-Driven Testingでは100%のカバレッジを求めていないことだそうです。
精度を高めることを今は求めているとのこと。

講演資料を参考に作ったグラフが↓です。
f:id:yoshitake_1201:20190404122706p:plain

UlitmateSoftwareはOSSで公開中

github.com

現在開発中のAPi-Driven Testing のOSSだそうです。
ぜひ使ってみてほしいとのことでした。

※ 他のAI-Driven Testingサービスはこのブログの後半にリンクを載せました。

AI Driven Testの生成は、AIが小説を学習してAIが執筆するのと似ている？

アリス・イン・ワンダーランドの出てくる単語などを学習し、自動で小説を書くというAIがある。
AI-Driven Testのテストケース生成はこれとよく似ている。とのこと。

例えば、あるページに「first name」と出てきたとき、空白を入力して「submit」をクリックするとエラーが出る。
こういったことを学習していけば、AI-Driven Testのカバレッジをあげていくことができる。

感想

背景やスコープなど非常に丁寧な説明でわかりやすかったというのが講演中 & 講演直後の感想です。
ただやはり時間が経つと翻訳だったこともあっていろいろ忘れてしまっていて…（笑）
来年以降、生の英語 & 講演姿を見れるようになりたいと思いました。

ただ、AI-Driven Testについて。
考え方は非常にわかりやすかったかなぁと。
カバレッジが100%じゃないから納得いかないでしょうが、現在あなた達が行っているテストもカバレッジ100%じゃないでしょ？
という説明には「そうだよなぁ」と納得しました（笑）

また、AI-Driven Testが発達していくと、全数テストは可能や殺虫剤のパラドックスがなくなるということになったりするんじゃないかなぁとも思いました。
AI使ったテスト、やっていきたいですね。

AI-Driven Testingのツール（サービス）

www.mabl.com

test.ai

applitools.com

sofy.ai

www.diffblue.com

eggplant.io

apptest.ai

www.functionize.com

testrigor.com

www.testim.io

www.ultimatesoftware.com

講演中のメモ

後半はTLと講演を聞くことに集中したのでメモがあまり取れてなかった。。。

JaSST Tokyo


基調講演

Automation
→ 人間が最終的にやっていること
→ 独立して何かをやっているということ

P19

Automation vs Manual
Automationと言いながらも結局テストケースをManualで作っている。
Manual TestをAutomationしているだけ。

結局最終的にはコードを手で書かないといけない。
それがすごく微妙だよね。という話。
まぁそれが良いとしても、結果が出てきても、それを人が確認しないといけない。

つまり自動化の中身はマニュアルばっかりだよ。


AI- Driven Testing 
Testing AI System
Self Testing System

↑のような流れでAIのテストは発展していかないといけない。

今回は、AI Driven Testing の話だけする。
P22

機械学習について。
種類
教師あり学習
教師なし学習
強化型学習

P27
ソフトウェアテストに対する機械学習の適用

テストついては、無限にドメインがある。
ただドメインが無限ではいけない。
なぜならソフトウェアテストは無限にできないから。

P27からは簡単化して考えた

AI Driven Testは完璧なテストと現実のテストの差分を埋めるためにつかう。

P32
ロボットが学習していく図。
Explore→探索ができる、としよう。
そうしたときに画像を使って学習させることが来でる。
Modelを使えるとしよう
そうするとModelを使って模倣する
いろんなかs夏ができるときに部分できなアプリケーションの観測しかできないときに、前に見たことがあるときにこれがこのモデルだ！と推定することができる。

要チェック
aiipum + test.ai

JaSST'19 Tokyo A5「テストマネジメントの鉄則」の参加ブログ #JaSST19Tokyo #JaSST #jassta5

JaSST JaSST19Tokyo イベント参加レポート

講演内容

タイトル：「テストマネジメントの鉄則」
jasst.jp

講演資料

www.slideshare.net

講演中のツイートまとめ

togetter.com

JaSST'19 Tokyo、A5「テストマネジメントの鉄則」の参加ブログです。
講演中に私がおぉ！と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。

以下、まとめです。

テーマ：「欠陥管理」

欠陥管理がうまくいかないのはExcelのせいではない

「ツールがあれば…」と言っている人を見かけるけど、ツール入れたらスグ解決するわけではないですよ。ということでした。
ごもっともですよね。
何かを解決したい、良くしたい、など目的があって、その手段としてツールを入れるべきなので。
個人的には直近「JIRAほしいなぁ」ってよく言ってたんですが、別にJIRAじゃなくてもできることあったんですよね。
（現在自分がやりたいことはGoogle Spread Sheetでチャレンジ中）
「ツール = 銀の弾丸」ではないですもんね。

転がし続けろ！

「情報を滞留したままにしておくのは良くない」 という意味合いでした。
テーマ的にはこの場合「情報 = 欠陥 」ですが、他にもタスク、障害などなど様々なことに関わる。とおっしゃられてました。
放置されたバグ、決まらない仕様などなど。
全体が見えているのはテストマネージャだし、「テストを目指した期間内に終わらせる使命がある」 → 「それを阻害するような要素は解決していこう」という意味合いなのかなぁと思いました。

「組織ごと移動させると上司だけ移動して部下がついてこないバグ」

「声に出して読みたいバグ票コンテスト」を開催しているそうです。
インパクトのあるタイトルをバグ票につけよう、といった意味合いのご意見でした（笑）。
長谷川さんの例題なんですが、とてもおもしろかったですね。

個人的には、特徴的なバグ票はレポート番号を覚えてるんですよね。
忘れられないバグたちです。
タイトルにユーモアあるのをつけれる環境づくりも大事なんだろうなぁと思いました。

テーマ：「テスト計画」

念入り、肝いりなものはNG

テスト計画は作成したらその通りに実施できるわけではなく、状況に応じて変わるもの。
なので熟考 & 時間をかけて作成するよりも、一度作ってしまう → 状況に応じて都度変更/修正するほうがいい。とのことでした。

JSTQB ALテストマネージャのシラバスにもテスト計画は開始から終了まで継続的に行う、といった旨が書かれていると調べてきてくださいました。
該当の部分は以下かと思います（FLシラバスにも似たような文脈の記載がありました）。

■ AL テストマネージャシラバス

1.2.1 テスト計画作業
各テストレベルにおいて、テスト計画作業はそのレベルのテストプロセスの開始時に始まり、そのレベルの終了作業が完了するまで、プロジェクト全体を通じて継続する。

■ FL旧シラバス

5.2.1 テスト計画作業
テスト計画作業は、連続的な活動であり、全てのライフサイクルプロセスや活動で実施する。

■ FL新シラバス

5.2.1 テスト計画書の目的と内容
テスト計画は継続する活動であり、プロダクトのライフサイクル全体を通して行う（プロダクトのライフサイクルはプロジェクトの範囲を超えて、メンテナンスフェーズまで延長されることに注意する）。

前回は15分かかったけど、今回は8分でできるかも…

そんなことは思わないようにしましょう。という話でした。
テスト実行って、短縮されることってまずないですよね。と。
これは自分もやっている部分があるので気をつけようと思います。

全ての情報を全てのステークホルダが知らなくても良い

町田さんが「テスト計画はみんなのために」の中で言われた言葉です。
多重下請けの構造になったとき、プライムから末端まで計画が伝わらなければならないが、伝言ゲームなので伝わりにくい。
なので必要な人に必要な情報を共有しよう、という話でした。

個人的には「必要な人に必要なことを伝える」というバランスが難しいよなぁと思いました。
計画の粒度や抽出など考えないといけない…テストマネージャはやはり大変ですね。

テーマ：「進捗管理」

「パトロールしていて『このおっさんいっつもフラフラしてんな』って思われないですかね？」

「ツールとパトロール」でリナさんが長谷川さんにツッコミを入れた言葉です（笑）
困っていることを尋ねたり、同じバグ票起票してないかな？というのを確認するための鉄則で「ツールとパトロール」というのを長谷川さんが紹介されていました。

パトロールは先のことを拾うための活動、ルールは現時点のことを拾うための活動、とわかりやすかったです。

親身になるな！

テスト終了間際になると「あのテストやったかな？」と不安になって声をかけたくなる。
しかし、それを今やっているテストに差し込むと大変なことになる。
なので、そういったことに親身になってはいけない。
必要なら、別途追加テストのフェーズを取るべき。
という意味合いでした。

本筋と少しずれるのですが、この説明のときに湯本さんが「暇そうな開発者連れてきて探索的テストしてもらったらいい」ということを言われたんですが、その説明が良いなぁと思いました。

以下湯本さんの発言（走り書きのメモ）

「暇そうな開発者連れてきて探索的テストしてもらったらいい」 「ただ、彼らには探索的テストって言ってもわらからないから、まず考えたことを書き出してもらう。そして書き出したことについて1時間ぐらいテストしてもらう」

「とりあえず触ってもらう」ではなく「まず考えて書き出してもらう」と促すのがすごいなぁと思いました。
自分も真似しようと思います。

テスト消化数って聞いて何を思いますか？

実施したテストの数 or 合格したテストの数 どちらでしょう？
会場で挙手を求められたんですが、割とバラけていた印象でした（前の方にいたのであまり後ろが見れなかったですが…）。
ちなみに本来の意味は「実施した数」です（合ってますよね？（笑））。

ただ、その言葉の意味を全員が正しく認識しているか？
認識していない状態で数字だけで判断しないほうがいい、という話でした。
（カバレッジとかまさにそうですよね。

この話と少しそれますが、自分も言葉の認識の違いは最近よく遭遇しているなぁと思っています。
品質、テスト、ドキュメント、改善、などなど。
もう少し踏み込んで認識合わせしていこうと思っています。

質問：リスクの考え方

プロダクトリスクとプロジェクトリスクがあるよね。と。
（D2「あなたに捧げる～TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善【導入時：改善計画立案編】リターンズ」でも、改善には「製品品質改善」と「プロセス改善」があるよね、と似たような話もありました）

その中の説明で、プロジェクトリスクについて「メンバーがインフルエンザになるリスク」という説明がありました。
個人的にはすごく納得していた（なんなら考えていた）んですが、想定したことがない、という意見もけっこうあってちょっとびっくりしました。

リスク管理の話にシフトしたなぁと思いながら聞いてたんですが、プロジェクトリスク、プロダクトリスクどちらもQA活動になる、と言ってもらえたのは個人的には良かったかなと思いました。

個人的に刺さった名言集

ただただ自分が刺さった名言集です。

  • ツールはメンバーみたいなもの
  • テストマネージャはテストを目指した期間内に終わらせる使命がある
  • リテストはテストケースが増えているようなもの
  • テストチームはどこまで開発に踏み込むべきか？
  • バグには個性がある
  • アジャイルだからとか関係ない
  • 間違ったアジャイル
  • テスト計画は変わる
  • テストで奇跡は起こらない
  • 見えている数字に騙されるな
  • 進捗って9割終わったぐらいが5割ぐらい
  • バグ1件出ると30分はかかる
  • ここは対象外って言われてもそんなことないんだよね

感想

聞けてよかった！とただただ思いました。
ちょうど自分が抱えている今の悩みをパネリストの方々がバシバシ言ってくださる形になってました。
そしてその悩みに対するパネリストの方の回答も、自分が「こうしたほうがいいんじゃないかな？」と思っていたものと同じベクトルだったので、いろいろと整理でき、自信を持てました。

モデレータのリナさんのツッコミも良かったですね。
私の中でのリナさんのベストシーンは「あれ、さっき嘘つくなって言いませんでしたっけ？」と湯本さんにツッコミをいれたシーンですね。
最高でした。
togetter確認したら、「嘘つくな」の30分後に嘘ついてたんですね（笑）

昨年のJaSST'18 Tokyoでも「テストマネージャの決断」セッションを聞いて、かなりタメになったのですが、今年も最高でした。
来年も同じようなセッションがあると良いなぁと思いました。

リナさん、長谷川さん、湯本さん、町田さん、ありがとうございました！

参考

昨年のセッション
jasst.jp

togetter.com