yoshitake_1201’s diary

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

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

講演内容

タイトル:「テストマネジメントの鉄則」
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