yoshitake_1201’s diary

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

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

JaSST'19 Tokyo F3「赤い会社のテストエンジニアたちが語りつくす～テスト現場で起こるリアル課題と対処策～」の参加ブログ #JaSST19Tokyo #JaSST

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

講演内容

タイトル：「赤い会社のテストエンジニアたちが語りつくす～テスト現場で起こるリアル課題と対処策～」
URL：http://jasst.jp/symposium/jasst19tokyo/details.html#F3

講演資料

パネルだったので資料はありませんでした。

講演中のツイートまとめ

togetter.com

JaSST'19 Tokyo、F3「赤い会社のテストエンジニアたちが語りつくす～テスト現場で起こるリアル課題と対処策～」の参加ブログです。
講演中に私がおぉ！と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。

以下、まとめです。

SHIFTさんのCM！

vimeo.com

www.shiftinc.jp

あったんですね。
福岡では流れてないのか（流れてるけど自分がテレビを見ていないからなのか…）私は初見でした。
かっこいいCMでしたね。
テスト業界の会社がテレビCMを流すっていうのはなかなか斬新な取組みだなぁと思いました。

本当に1,500万円もらったいる人がいるんですか？

パネラーの方々のコメントはノーコメントでしたけど（笑）
「知りたかったら入社して〜」っという返しはうまいなぁと思いました。

「〇〇であること」は「〇〇ではないこと」が抜けていることが多い

なのでフローチャートなど使って教えたりしている。と。
このあたりチームメンバーとの関係性次第な気もするので、テストケースのレベルが難しいよなぁと思いました。

アジャイルな現場の場合「会議にとりあえず来てね」をなくす

これは個人的には意外でした。
（ここで佐藤さんが使われた「アジャイル」の定義にもよるんですが）。
「開発 → テスト → リリース」のサイクルが早い現場と想定したのですが、伝達コスト的なところもあるだろうから、会議は全員参加 → 短く終わらせる、というようなイメージを持っていたんですよね。
ただこういった話は状況や目的によって全然違うので、細かい背景も聞いてみたかったです。

「これまで経験した一番の無茶振りは？」という質問に対して

「プロジェクトが燃えてる」って聞いたから現場に行ってみたら「やることがなかった」という話は印象的でした。
確かに燃えてるんだろうけど、どうしようもないですよね。
その後どういう対応したのかまで聞きたかった。

感想

パネラーの4人の方々はロールや経験年数が違ったこともあり幅広い意見が聞けたのでよかったですね。
欲を言えば、新人教育についての具体的な話や、テスト設計の具体的なアプローチなど聞いてみたいなぁと思いました。
個人的には鈴木さんが現場レベルの話を忌憚ない感じの話をしていたのが良いなぁと思いました。
だめなことはだめ、できないことはできない…など。

来年もパネルセッションしてほしいですね。
パネラーの方々、ファシリテーターの方々、ありがとうございました！

JaSST'19 Tokyo D2「あなたに捧げる～TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善【導入時：改善計画立案編】リターンズ」の参加ブログ #JaSST19Tokyo #JaSST #jasstd2

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

講演内容

タイトル：「あなたに捧げる～TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善【導入時：改善計画立案編】リターンズ」
jasst.jp

講演資料

こちらからダウンロードできます。
www.software-quasol.com

講演中のツイートまとめ

togetter.com

JaSST'19 Tokyo、D2「あなたに捧げる～TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善【導入時：改善計画立案編】リターンズ」の参加ブログです。
講演中に私がおぉ！と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。
※ 特にTPI Nextと至るところに書かれていますが、このブログではTPI Nextにはほぼほぼ触れていません。

以下、まとめです。

「疑ってかかって！」

スクリーンショット - a0620582af19cdb49b0b5f058b2f3c75 - Gyazo

講演資料P4より

講演中、様々な場面で度々この言葉を安達さんが言われていました。
そもそも、TPI Next公式トレーニングを受けてないから…と資料にはありますが、その他にも似たような文脈で以下の言葉を使われていました。

  • 「"モデル"は体系的なものだから一般化されている」
    • 端折っていることに注意
  • 「書いてあることだけを信じないでください」
  • 「(モデルが)合わないと思ったら捨てていいんです」

発表されている内容や紹介されているモデルは全部が全部正しい（= 自分たちの組織に合う）かはわからないので、「とりあえず信じること」はやめようね、気をつけようね という意味で使われているんだろうと私は感じました。

プロセス改善の位置づけ（分類）

スクリーンショット - ce65347f1f63b0eef74295767cfdd002 - Gyazo

講演資料P9より

自分の周りでは、「改善」といえば「製品品質改善」をイメージする方が多いかと思っています。
が、プロセス改善というのもありますよね。
（どちらも大事なんですが、個人的にはプロセス改善の方を重要視しています）

こういった分類については、以下のセッションでも似たような話が出てきました。

プロセス改善モデルの改善が失敗しやすい原因

プロセス改善モデルは失敗しやすい、という話がありました。
その原因は 「プロセス改善モデルスコープを勘違いしているから」
というのが1番の原因かなと私は認識しました。
（現に私も失敗したことがある勢の1人です）

以下は「問題・課題ベースの改善」と「プロセス改善モデルベース改善」の特徴の違いをまとめられた表と、P17、P83、P86を参考に私が作った図です。

スクリーンショット - 132c18d5a0e700dc5b66c4b292a5651a - Gyazo

講演資料P10より

スクリーンショット - ecbae2bd47e5b9d90ad87daee3ca9a4b - Gyazo

講演資料P17、P83、P86を参考に作った図

注意したいポイントは以下です。

  • 「人の感情部分」は「プロセス改善モデル」のスコープ外
  • モデルなので一般化されている
    • 大事なこと以外は端折ってる
    • 自分たちの背景・実情と異なることが多分にある

これらのことを認識しない状態で「モデル = 銀の弾丸」と思って使うのでだいたい失敗してしまうとなるのかなぁと。

またモデルを読んだ人が「こんなん使えないよ」と言うのを私はたまに聞くのですが、その多くは「モデルに具体的なことが書かれていないから」という意見が多かったです。 ただ、そもそも「モデル = 体系的」なものなので、その意見はその通りですよね。 「現場を良くしたいけどゴールも見えずどうしたらいいかわからない」というときに「モデル」を使うと良いなぁと思いました。

「問題・課題ベースの改善」と「プロセス改善モデルベースの改善」のハイブリットなアプローチ

これが今回の事例だそうです。
どちらか片方ではなく、両方使うということでした。

「感情は論理に勝る」

講演資料P83より

講演終了間際、↑のページで安達さんが強く言われていたのがこの言葉です。
講演資料や↑の図にある通り、「（現場の）人の感情」はプロセス改善モデルのスコープ外です。
だから どれだけ論理的にモデルを説明しあるべき姿を説いても、最後の最後に「嫌なものは嫌」と言われたらそこで終わるんです、と。

このことから改善の始めの一歩を踏み出すときに失敗する多くの原因は↑なのかなぁと思いました。
（自分が失敗した原因もこれにあたるかなぁと）

※補足
今回発表された事例は「改善意識がある方が1人、その周りはそこまでの意識はない」という現場の事例でした。
だからこのことが強く書かれていると思いました。
また改善の大きな悩みの1つに「メンバーや自分の感情（モチベーション）の維持」があるとも思いました。

事例の中でTPI Nextを活用したのは3ヶ所

講演資料P80より

今回の事例（アプローチ）のSTEP全体像が↑です。
その中でTPI Nextのエッセンスを使ったのは3ヶ所だけでした。
TPI Nextを活用したのも、事例当事者である中山さんがたまたまTPI Nextを使っていたから活用してみた、という感じだそうです。

なので、TPI Nextを使わないほうがいいなら（使わなくてもいいなら）無理に使う必要はない。と言われていました。
最初に言われていた、「合わないなら捨てていい」ということを強調されている感じですね。
感情に重きをおいて、プロセス改善モデルで手段を探す、素敵なアプローチだと思いました。

TPI Nextについて

TPI Nextを読みやすくする背景

スクリーンショット - f4d71d4106947693f37b211f6d7cab5f - Gyazo

講演資料P29より

この図のような組織のテストチームに所属していると思ってTPI Nextを読むとわかりやすいよ。と言われていました。
確かに、TPI Nextは組織全体像やステークホルダとの関係を意識しないと読みときづらいなぁと思っていました。
ありがたい背景です。

TPI Nextの注意点 = たくさんの場所に散ってる

スクリーンショット - d6ab9d2ac6c261b4bddab2196aee0d28 - Gyazo

講演資料P45より

キーエリア名と内容が一致していない場合があるとのことでした。
講演中は時間の都合で↑の一番左のものだけ質問となりました。
会場では、「手法の実践」「テストケース設計」の順で手が多く上がったと記憶していますが、正解は「テスト担当者のプロ意識」に存在するでした。

なぜこの分布になっているのかを考える

スクリーンショット - ad2bde977a0965d03341a2313dd34895 - Gyazo

講演資料P31に赤枠と赤字を足したもの

↑の資料は、講演資料P31に私が赤枠と赤字をつけたものです。
なぜ「テスト業務の専門性」のAやB（初期レベル）が少ないかな？
そう思って見てみると、初期レベルでは「テスト業務の専門性」よりも「利害関係者の関係」や「テスト管理」を重要視しているからと読めるよね。
という安達さんの見解でした。

私はこういう風に意識して読んだことがなかったので、かなり腑に落ちました。
その視点で見ていくと、「利害関係者との関係」はどのレベルでも基本的に満遍なくプラクティが分布されているので、定常的に重要（なによりも大事）と読めるかなぁと思いました。

TPI NexTは人に着目している部分が多い

スクリーンショット - d90aa61609036e36a19b2aaae5158454 - Gyazo

講演資料P43より

体系的なモデルなのに技術だけでなく人に着目していてバランスがいい、という話でした。
話は変わりますが、JSTQBシラバスの中でも人に着目する要素がかなり出てきますよね。
最初受験したとき(2年前ぐらい？)は「資格試験なのになんで人間関係？」と思ったんですが、今となってはその理由もこれと同じかなと思います。
テスト業界全体として、人間関係（ステークホルダー、テスト実行者、テストリーダー、テスト管理者など）に重きをおいているんだなぁと感じました。

感想

「改善活動」について詳しくまとめられた発表で、とても勉強になりました！
個人的なことですが、最近「改善」という言葉があまり好きではなかったんです。
ただ講演を聞く → 知人に講演内容の説明をしたおかげで、改善活動にも種類があるなぁと気づくことができ「改善」という言葉が少し好きになりました。
（改善は、お悩み解決と研鑽に分けられる、と今の自分は考えています）

「モデルが作られた背景を考える」「なんでこの分布になっているか考える」といった視点を持っていなかったので、その視点を知れたのがよかったです。
モデルなどの文章を読むと、難しい言葉で短く書かれているので「それが正しいか？」などの思考が止まっていたなぁと。
なので、今後は疑いながら噛み砕きながらかかろうと思いました。

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

参考

※ TPI Nextの監査ツール日本語版が公開されています。
以下のサイトからダウロードできます。
www.tmap.net

※ JaSST'17 Hokkaido 中山さんの事例
jasst.jp

「あのチーム」のフレーズを教えてくれるボットを入れてみた話

こんにちは。
福岡でテストをしているyoshitakeです。
前任のテスト担当者と入れ替わる形で昨年5月に今の会社に入社。
その後11月に @sae というテスト仲間が1人増え、現在結成4ヶ月、メンバー2人のテストチームで日々業務に臨んでいます。

今回の内容は、最近チームのSlack Channelに取り入れた「あのチーム」のフレーズボットについての紹介になります。

「あのチーム」ボットとは？

speakerdeck.com

speakerdeck.com

上記の資料で紹介されている「あのチーム」が日頃よく使うフレーズを定期的に教えてくれるボットです。
教えてくれるフレーズは以下の16個からランダムに1つです。

  • うまくいったらどうなるの?
  • なにしてるの？
  • えー
  • できそう？
  • なんでやるんだっけ？
  • 早く見つかってよかったねー
  • 再現させたらわかるの？
  • なんでできると思うの？
  • 自分で触ってみた？
  • なにが大事じゃないの？
  • 多数決で決める？
  • やりたくないの？
  • どこが自信あるの？
  • がんばらないで！
  • みせて
  • わかんない

※ そもそも「あのチーム」とは？ については上記のスライドを参考ください。

入れようと思ったきっかけ

ある日のMTG中、僕が@saeに「あのチーム」のフレーズを使ったことがきっかけでした。
（その時使ったのは「うまくいったらどうなるの？」だったと思います）
@saeが「なんでそういう言葉知ってるの？」と聞いてくれたので、上記の資料の紹介と説明をしました。 すると「こういうフレーズ言えるようになりたいよねぇ」と言ってくれたので、どうやったら身につけられるかを考えた結果、今回のボット導入しようか、となりました。

しかしボットは形骸化しがち…

定期的に同じ内容のフレーズを通知するだけのボットが形骸化しがちというのはあるあるかと思います。
今回のボットはそうなって欲しくないので、形骸化しないために +αで別の要素を追加することを考えました。

どんな要素がいいかなぁ…と悩んでいたところ、「あのチーム」のテスター miwa(@miwa719)さんといえば…

そうだ、スタンドだ！と思いつき、メッセージが通知されると立ち上がるという要素を盛り込みました。
（工数入力を促すメッセージもついでにお知らせしてもらうことにしました）

通知は11:00、15:00、17:00の1日3回としました。

実際のチャット内容

こちらです。

f:id:yoshitake_1201:20190224130006p:plain

スタンド！の流れから、アイコンとお名前はmiwaさんご本人のtwitter iconとIDをお借りしました。
（ちなみにUninoteというのは弊社で使っている社内製の工数入力システムです）

入れてみた結果

よかったこと

  • 立ち上がることで意識を切り替えることができる
  • 立ち上がってからメッセージ内のフレーズについて少し意見を交わせる
  • 通知回数と時間がちょうどいい

+αでスタンドを入れたのが良かったなぁと思ってます。
そもそもスタンドすることがいいですね！
立ち上がるとPCから目を離せるのでいい意識の切り替えになりますし。
また、席が隣なので立ち上がることで話す時間も取れることができるというのもいい感じです。
軽く話し終わったら工数をつけてそのまま仕事に戻っています。

そして、通知時間もいい感じでした。
集中しすぎようとしている、または気が抜けそうになっている時間に通知されるので、いい息抜き & 気持ちを入れ替えるのに役立っています。

アイコンと名前をmiwaさんにしたことのいい効果

最初は流れでmiwaさんにさせてもらったのですが、実は想定外のいい効果が生まれました。

  • スタンドを必ずやる（miwaさんに言ってもらっている気になるので断れない）
  • 自分のチームにmiwaさんがいると感じる → なんとなく安心感が生まれる
  • 自分のチームにmiwaさんがいると感じる → もっとテストしよう！と身が引き締まる

ただのてきとうな画像や「あのチームボット」などという簡素な名前だったら、たまにサボっていただろうなぁと思います。
しかしSlackの表示的には「miwaさんがスタンドを促してくれている！」となるので、サボろうという感情はなくなりました（これまで2人とも1回もサボってません）。
どんなことをしていようと2人がいきなりおもむろに立ち上がるので、周りの人からは変な妙な目で見られているかもしれませんが…（笑）

加えて、チームのチャットルームにmiwaさんが登場する（ことになる）ので、どこか安心感と一緒に身が引き締まる感じを得ることができました。
「あのチーム」を少し体験している気になっているのかもしれません（笑）

おわりに

今回この内容をブログに書いて公開してもいいですか？とmiwaさんご本人に相談した所、快く承諾してくださいました。
miwaさん、本当にありがとうございます！

それぞれのフレーズがどういう意味合いで使われているのかは、上記の2つのスライドと「エラスティックリーダーシップ ―自己組織化チームの育て方」という書籍内で、「あのチーム」のメンバーであるseki(@m_seki)さんが一部紹介されています。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

詳しく紹介されているフレーズはこちらです。

  • うまくいったどうなるの？
  • 早く見つかってよかったねー
  • 再現させたらわかるの？
  • わかんない
  • やりたくないの？

ちなみに私達は、資料で詳しく紹介されてないフレーズが通知されたときは「こういう風に使ってるんじゃないかな？」と想像しながら意見交換しています。
（なお、我々の中では「多数決で決める？」というフレーズは、「このままだと多数決になっちゃうよ、それでもいいの？」という感じで使っているんだろうという結論になりました。今度ご本人たちにお会いしたときにどういう感じで使っているのか聞いてみようと思っています）
このフレーズを自然に使えるようになったり、自分たちで新しくフレーズを生み出せたりして、よいチームになったらいいなぁと思ってます。

それでは、ここまで読んでいただきありがとうございました。