“Issueの書き方と伝え方”勉強会参加レポート

4/21(土)に、九州からいらしたリナさんを囲み、“Issueの書き方と伝え方”勉強会がありました。感想まじえてざっくりレポートしてみます。

イベント情報はこちら
https://connpass.com/event/83134/

『293の法則 第4章』(秋山さん)

概要

まずは用語の整理から
・エラー

  • ヒューマンエラー:思考の誤り
  • 失敗:失敗を導く要因

・欠陥

  • ディフェクト(defect):購入時に存在
  • フォールト(fault):経年劣化などで増えるもの

・インシデント

  • 故障(failure):期待と違う(異常な)結果
  • 不具合/バグ:表出した現象(問題)

・障害レポート

  • Issue:話題/論点
  • バグ票:バグを一件一葉にまとめたもの

・293の法則第4章のサマリ

  • 詳細は293の法則の第4章を参照

・優先度と重要度の補足

  • 緊急度、影響度、重要度を5段階で評価し各合計が優先度となる
  • 優先度単独で点を自分でつけない方が良い(優先度は結果として決まる)。同店の時は緊急度(リスクが見えている)>影響度(客観的)>重要度(主観的)
  • どの項目を誰がつけるのかは現場によって違う模様
  • 例えば緊急度は起票者、影響度、重要度はPLなど。チームの熟練度やどこまでをチームメンバに委譲したいか、で決まってくると思われる(会場でも、参加者の現場の場合を話して議論が盛り上がったポイント)
感想

用語の説明のところがすごく丁寧で助かりました。たまに自分でもdefectとかfailureとかどう違うのか忘れて、JSTQBの用語定義引っ張りだしたりするので。『293の鉄則』第4章もみんなで読んでみて、各現場の話が聞けて面白かったです。

『こんな○○は嫌だ(仮)』(シブヤさん)

資料は公開されてないので、差しさわりのない範囲でサマリします

概要

・バグ票はコミュニケーションツール
・こんなバグ票は嫌だ

  • 文章が長い
    • 一文が長大。「、」がいくつあるのかってレベル
  • タイトルが分かりにくい
    • 「xxがおかしい」「xxが仕様通りでない」など
  • 再現できない
    • 手順がないとか、「特定のタイミングで発生する」とあるが、タイミングについて言及がないとか。
  • 偉そう
    • 思いこみで書いてるとか、文句が入っているとか

・それでもみんな、何かをよくするためのシステムを作ってて、テスターは何かをよくするためのシステムが気持ちよく使えるかをテストしてる

  • シブヤさんがテストするのは世界平和のため
感想

シブヤさんが、テスターあるあるな、嫌なバグ票を恨み節的な感じではなく、笑いに昇華して発表されてるのが、聞きやすくて面白かったです。「タイトルが分かりにくい」は、バグ票書き始めのころに自分もよくやってしまいました。今は具体的に書こうとしてタイトルが長くなりすぎる傾向にあるんですが、みなさんどうされてるんでしょうね。
平和のためにテストしているシブヤさんが素敵でした!

『年間2000件以上Issueを書く私が思う、しあわせになるIssue』(リナさん)

概要

・リナさんの組織と背景の紹介

  • テスター(メイン1名とヘルプ数名)、担当のエンジニアの顔が見える組織
  • 探索的テスター
  • 環境はGitHubを使用、GitHubのIssue機能を使ってバグを報告している
  • Issueで起票するが、以下のようなパターンを使用(起票したものがバグとは限らない)
  • バグ票ワーストプラクティス検討プロジェクト(「ダメなものを避ける」ことで良いものを作る方がやりやすいのではないか)

・Issueってなぁに?

  • エンジニアとテスターとシステムをつなぐお手紙みたいなもの
  • コミュニケーションツール

・しあわせになれるIssueってなぁに?

  • エンジニアには「修正しやすい」、テスターには「修正確認しやすい」。つまり「Issueがあれば、思い出せる」もの

・テンプレート(補足:リナさんのテスト対象はWeb系が多い)

  • タイトル
  • 本文
  • ラベル ★ここがリナさんの工夫の箇所

・ラベルで工夫

  • ある程度ラベルに裁量が与えられてるそうなので、「Bug」「Request」「Question」「UI」などで工夫
  • (探索的テストメインで進めており、現象について)事前合意がないので、バグかどうか判断できない

・こんなときどうする?

  • 一覧画面にて絞込→編集画面に遷移→一覧に戻ると絞込が解除されている

・リナさんならどう書くか

  • Requestとして起票する:「xx編集画面」更新後も条件を保持してほしい

・Issueを書くときに考えていること

  • できるだけ検索条件は保持されてほしい。
    • 登録後の一覧に戻るときだけでいい
    • セッション保持とともに持つのは要件として重すぎる
    • 技術的に最短距離でできるところに落としてほしい
  • エンジニアがしていたであろう操作を考慮したい
    • それ確認してたのに(Chromeでは)
    • それ前に確認してたのに(デグレ)

・IssueをCloseするとき

  • 「ありがとうございました」と書く

・エンジニアからもらってうれしかったIssue

  • タイトルに【おねだり】と書いたら即対応してくれた
  • http://underscore42rina.hatenablog.com/entry/2013/09/07/104513
  • ていねいな説明
    • 結論(対応あり・なし)
    • バグの発生パターン(調査結果)
    • パターンに対する対応と懸念点
    • 対応なしの場合の理由
  • 弱音
    • バグって言われるとつらい→いい感じにラベルの名前を変える
    • 「モンスター」とか「セフィロス」とか
感想

リナさんと、リナさんの周りの人たちが作ってるやさしい世界が素敵だなーと思いました!真似させてもらいます。私も開発者から「バグ」って言われるとつらいので「改善要望」にしてほしいとか、リクエストをもらうことがあるので、裁量もらってる範囲で、チームや人の状況みつつ言葉を選んでみようと思います。
IssueをCloseするときの「ありがとうございました」はさっそく真似させてもらってます。考えてみれば、「確認しました。OKです!」は言ってたけれど、「ありがとう」は言ってなかったように思います。自分が見つけて報告したものについて、開発者が対応してくれたんだから、確かに「ありがとうございます」ですよね。欠かさず言えるようにしようと思いました。感謝大事!
あと、私の所属コミュニティにも言及してくださってありがとうございます!バグ票ワーストプラクティス検討プロジェクトのサイトもよかったら見てみてください(宣伝)
https://sites.google.com/site/swworstpracticesite/

『不具合票あれこれ ー不具合票をテーマにしたブログ記事を調査しました』(鈴木三紀夫さん)

大変面白いので、リンク先の資料をみることを強くお勧めします!特に論点が面白いです。
https://docs.google.com/document/d/1_t43JDi6moOPx-TJHns2Yjr0qQAwvZWP32drjulkLhk/edit#

概要

・不具合票
・不具合報告

・論点

  • 不具合票のタイトルは要約を記載すべきか、内容が把握できるレベルまで記載すべきか
  • 不具合票のタイトルに隅付括弧を入れるか、入れないか
  • 不具合票に書くのは、欠陥・バグかインシデントか
  • 不具合票に要望を書くか、書かないか
  • 不具合票のテンプレートは必要か、不要か
  • 不具合票は必ず書くか、開発者に説明できれば書かないか
  • 不具合票に考察を書くか、書かないか
  • 不具合票にはたくさんの情報を記述すべきか、簡潔にすべきか
  • 不具合票の現象に「どうならなかったか」を書くか、書かないか
  • 重箱の隅をつつくような不具合を起票してもよいのか、そのような細かい不具合はまとめて起票するほうがよいのか
  • 不具合票に「本来は〜であるべき」を書くか、書かないか
感想

全体的に調査の網羅率がすごいです!論点のところが議論が盛り上がってよかったです。自分のプロジェクトや自分はどうしているだろう、と考えながら読むと、特に面白いと思います。
個人的には隅付括弧を入れる派なんですが、全体的にはどうなんでしょうね。機能名でフィルタすればわかるのはその通りなんですが、タイトルでぱっと見分かりやすくなるので、機能名とか画面名をつい隅付括弧で入れてしまいます。情報量は、チームの熟練度とか開発者との関係性によって変えてますね。

全体の感想

Issueにテーマを絞る勉強会ってなかなかないので、濃い話がたくさん聞けて楽しかったです。各社、各現場でどうされてるのかな、と疑問に思ってたところで色々「うちではこうやってるよー」というのが聞けました。
その後のテスト酒場もとても楽しかったです。バスケ、野球の話からバグ票の話、ゆるファシワークショップのその後の話まで、たくさん話しました。テストってちょっとニッチなところがあるので、同業者で集まる場っていいですね。
講演してくださった皆さま、企画してくださった皆さま、ありがとうございました!