More Related Content
Similar to SQiP2017_sig11_気持ちの良いバグ票コミュニケーションを一緒に考えましょう (20)
SQiP2017_sig11_気持ちの良いバグ票コミュニケーションを一緒に考えましょう
- 2. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 2
本SIGの進め方
所要時間:90分(16:55~18:25)
時間帯 所要時間 内容
16:55~17:00 5分 オープニングトーク
17:00~17:05 5分 ワーク①問題点の洗い出し:導入
17:05~17:25 20分 自己紹介+ワーク①問題点の洗い出し
17:25~17:35 10分 ワーク①問題点の洗い出し:ヒント紹介
17:35~17:40 5分 ワーク①問題点の洗い出し:洗い出し
17:40~17:55 15分 ワーク②改善策:ブレインストーミング
17:55~18:05 10分 ワーク②改善策:分類
18:05~18:15 10分 ワーク②改善策:フォーマット化
18:15~18:20 5分 発表
18:20~18:25 5分 クロージング
- 4. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 4
本SIGテーマについて
What:
気持ちの良いバグ票コミュニケーションを一緒に考えましょう!
Why:
バグ票は宝の山のはず、活用できてますか?という疑問がある
How:
バグ票にまつわるみなさんの苦い経験をもとに
みんなで語る! ⇒他者の経験に学ぶ
Who:
僕ら自身が、僕らのために
When/Where:
このSIGテーマ11にて
- 5. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 5
本SIGで行うこと、注意事項
行うこと:
バグ票の改善方法をミニワークでやっていきます
目的:
改善のやり方を学んで、現場を改善していくためのヒントを持ち
帰ってもらいたいと思います。
注意事項:
① 本SIGの情報は、成果物としてポスターボードに貼りだします。
この場限りの情報としたいものがあれば、一言お願いします。
② ワークの結果はコミュニティの参考として使わせていただきま
す。その際、個人情報を特定できるものは使用いたしません。
- 6. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 6
SIGのポイント
議論を行う上で、下記について注意してください。
オープンマインドで積極的に
守秘義務
この場で話した内容はむやみに公言しない
(その代わり、気にせずに話す)
オフレコあり
思いついたことは,整理しなくても良いから、まずは口にしてみよう
一人だけ長くしゃべらない
自分の経験を話す
相手の経験を否定しない、尊重する
別の意見があるのは大いに結構
その際には話を膨らますように発言しよう
性急な解決策を求めない
- 8. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 8
城本 由希 (しろもと ゆき)
社内での仕事:
所属:Acroquest Technology 株式会社
経験:品質保証
担当:テスト設計/実施、リリース管理
社外での活動:
ソフトウェアテスト系のイベントに出没。
昨年からコミュニティ活動も開始。
JaSST ,WACATE,etc,..,
自己紹介
- 9. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 9
コミュニティ紹介 ―活動をはじめたきっかけ
1. バグ票はソフトウェアの様々な関係者が最も多く関わる開発技
術文書であり、ほぼ全ての開発現場で存在する
バグ票
開発者、テスト実施者間のコミュニケーションツール
バグを直してもらうためにやりとりする
研究の動機ーバグ票の状況をもう少し考えてみると・・・
コミュニケーション
直接
直接話す
Skypeなど
チャットなど
間接
メール
バグ票
レビュー記録表など
開発者、テスト担当者間の
コミュニケーション
間接的なコミュニ
ケーションになるほ
ど、一定のルール
が必要では?
- 10. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 10
コミュニティ紹介 ―活動をはじめたきっかけ
2. バグ票の書き方を解説している書籍などは多いが、
悪いバグ票がどのようなものかは議論があまりない
3. 有効にバグ票が活用されていない現場がある
もしかしたらバグ票の質がソフトウェア品質にも寄与している
のではないか
4. なぜなら、活用できないために多くの弊害が発生している
コミュニケーションのために無駄な工数が発生している
プロセス改善が進まない etc.
目のつけどころとして悪くない!?
研究の動機ーバグ票の状況をもう少し考えてみると・・・
- 11. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 11
コミュニティ紹介 ―活動実績
活動の記録-というわけで色々やってみました。
- 12. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 12
• NaITE(長崎IT技術者会)
さまと共同で作成
• バグ票システム(BTS)をこ
れから導入する方へ向け
て執筆
「はじめてのバグ票システム~導入実践ガイ
ド」
http://naite.swquality.jp/?p=382
紹介資料(Slideshareへリンク)
- 13. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 13
コミュニティ紹介 ―現在の取り組み
最近では、以下の内容に取り組んでいます
1. 「BugAdvocacy」の要約作成
バグや品質についての考えを紹介した本。後述するRIMGENの観点が
紹介されている。日本語訳がないため、要約を作成して品質関連のシン
ポジウムなどで紹介している。
2. アンチパターン作成
バグ票の悪い例の収集や、そこからのアンチパターンの作成。
3. Redmineプラグイン作成
アンチパターンの防止や軽減に役立つプラグインの検討、作成。
- 14. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 14
例題ワークの進め方
例題ワークの進め方
1. ご自身が持ってきたバグの問題を付箋に書く(5分)
2. グループで自己紹介(5分)
3. サンプルの「気持ちの良くないバグ」紹介
~「気持ちの良くないバグ」問題点洗い出し(10分)
ここから先は、グループワークで進めていただきます。
- 17. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 17
気持ちの良くないバグ票サンプル
No.01
表題 連携システムXからの日時がずれていて不当な日時が過去日時として扱われ
る
報告者 A
機能 連携システムXからのリクエスト対応機能(画面ID 0X022)
症状 これまでのリリースで何度も報告しているが、連携システムXから送信される予
約用の日時のタイムゾーンが他と異なるため過去日付として扱われることがあ
る。本システムでの受付け日時の重要性から考えるとこの時期にこのバグは
危うい状況にあると考える。実装者はタイムゾーンを理解しているのだろう
か?他にも画面ID01004と画面ID01009は管理者向けの画面なので、装飾が
十分でないことは特に問題ないと思うが、JST,GMT,GMT0900のようなタイム
ゾーン表記がばらばらだったリ、表記がなかったりするのは、タイムゾーンンオ
重要性を理解できていないことの結果ではないだろうか。他にも警告メールを
送信するためのメールサーバの間で秒単位のずれがある。これらの時刻は統
一しておくのが基本ではないだろうか。時刻の認識を新たにしてほしい。他に
も祝日設定において春分の日と秋分の日が年にかかわらず同じ日に設定する
が、これらは毎年の官報での発表があった後に正式に決まる。Webを検索す
れば春分の日と秋分の日とを算出するソースコードサンプルを見つけることが
できるが、そのコピー&ペーストはあまりにも短絡的で日付や日時に対する意
識が低いといえる。
https://thinkit.co.jp/story/2012/07/18/3619
- 18. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 18
前提の確認
そもそもバグ票は…
バグを直してもらうためのも
の!!
ですよね?
- 20. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 20
記入例
No.01
表題 ユーザに不親切
報告者 B
機能 ユーザ登録機能(画面ID 01022)
症状 xxxページでユーザに住所の入力を求める部分で、番地等、半角英数文字を
入力すると「全角で入力し直してください」とエラーメッセージがでる、
あるべき姿 ユーザが入力した半角英数文字を全角に変換して登録する。ユーザへの再入
力は要求しない。なぜ半角とわかっているものをわざわざユーザに入力し直さ
せようとするのか一切理解できない。
表題から問題事象が具体的にわからない
テスト実施者の主観が入りすぎ
やり方
① 問題のありそうな箇所に線を引く
② 線を引いた理由を書く
https://thinkit.co.jp/story/2012/07/18/3619
- 22. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 22
書籍 Bug Advocacy紹介
Cem Kerner, Rebecca L. Fiedler らが
2015年7月下旬に出版した書籍。
著者らの講義の内容をまとめた内容。
下記のことが述べられている
• 「品質」や「バグ」の考え方
• バグ票の書き方
• 改善のヒント
• バグトラッキングシステム(BTS)の利用時の留
意点
• 再現不能なバグや却下されるようなバグ票に
ついての考え方や対応
• バグ票作成者への信頼や信用がバグ票の利
用や効果について大きく影響すること
https://www.amazon.co.jp/Bug-Advocacy-
Workbook-Rebecca-Fiedler/dp/098981193X
- 23. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 23
「RIMGENの観点」について
バグ票の記載内容を改善するための6つの要素をそれぞれ頭
文字をとって”RIMGEN” と呼び、紹介されているものがある。
頭文字と簡単な内容を以下に記す。
※RIMGENそれぞれの日本語訳は、検討中のものです。よりよい案がありましたら、教えていただけると助かります。
要素 意味 内容
R Replicate
(再現性)
・再現できるか
I Isolate
(独立性)
・単純な手順となっているか
・冗長な要素や手順などは分けられているか
・1件/レポート となっているか
M Maximize
(発端性)
・最悪なことが起きるバグの兆候をみつけているか
G Generalize
(普遍性)
・プロダクトに対するバグの影響範囲を識別できているか
・そのバグは他の環境や条件で発生することはあるか
E External
(第三者性)
・プロダクト利用時にバグの影響範囲を開発者やテスト担当者、
開発組織外の視点から識別できているか
N Neutral
(中立性)
・困惑させるような推測や思い込みなどがない
・個人に対する批判や侮辱、いらつかせたり困惑させるような内
容がないか
- 24. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 24
「RIMGENの観点」のバグ票問題 具体例
Replicate:
・再現できるか 問題①:
再現手順が示されていない。
起票者はお客様側のプロダクト
オーナー。
こちらで調べる必要がある。
問題②:
後で同類の事象が発生したときに
探せない。どんな修正、確認を
行ったかわからない。
(「確認しました」のみ)
- 25. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 25
「RIMGENの観点」のバグ票問題 具体例
Isolate:
・単純な手順となっているか
・冗長な要素や手順などは分けられているか
・1件/レポート となっているか
問題①:
複数の問題(と考えられる事
象)が1件として起票されている。
- 26. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 26
「RIMGENの観点」のバグ票問題 具体例
Maximize:
・最悪なことが起きるバグの兆候をみつけているか
問題①:
WEBシステムでプロキシサーバ
のキャッシュのことを考えずにソ
フトウェアを作ったところ、常に
最新情報を見せたい画面で古い
情報が表示されるというバグが
埋め込まれた。実はこのバグは、
古い情報を見せるという問題だ
けではなく、他の人用の情報を
見せてしまうというセキュリティ
上の問題でもあった。
- 27. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 27
「RIMGENの観点」のバグ票問題 具体例
Generalize:
・プロダクトに対するバグの影響範囲を識別できているか
・そのバグは他の環境や条件で発生することはあるか?
問題①:
報告した際にレアケースといわ
れ、却下されたが、のちの市場
クレーム報告で、顧客が同様の
手順を行い、データが壊れてし
まう現象が発生した。
- 28. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 28
「RIMGENの観点」のバグ票問題 具体例
External:
・プロダクト利用時にバグの影響範囲を開発者やテス
ト担当者、開発組織外の視点から識別できているか
問題①:
仕様には、明確に記載されてい
ないところだけれど、ユーザに
は、わかりそうなバグ。
- 29. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 29
「RIMGENの観点」のバグ票問題 具体例
Neutral:
・困惑させるような推測や思い込みなどがない
・個人に対する批判や侮辱、いらつかせたり困惑させ
るような内容がない
問題①:
バグ原因切り分けで「○○が
原因だと思われます」と自分で
推測して書いていました。一歩
間違えたら開発者をミスリード
していた。
- 30. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 30
RIMGENの観点に沿ってないときの問題点
RIMGENの観点に沿わないとどうなるか?
明確でないバグ票
バグが非現実的、
不合理として却下される
関係者間の信頼がなくなる
再現不能なバグとして
却下される
R
I
M G E
N
システムへの理解とその説明スキ
ルが必要ではないか?
高め 改善難易度 低め
客観的に書くべきではないか?
修正されるべきバグに
フォーカスが当たらない
バグの内容を理解する
のに時間がかかる
書き方で防げる問題ではないか?
- 32. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 32
記入例
No.01
表題 ユーザに不親切
報告者 B
機能 ユーザ登録機能(画面ID 01022)
症状 xxxページでユーザに住所の入力を求める部分で、番地等、半角英数文字を
入力すると「全角で入力し直してください」とエラーメッセージがでる、
あるべき姿 ユーザが入力した半角英数文字を全角に変換して登録する。ユーザへの再入
力は要求しない。なぜ半角とわかっているものをわざわざユーザに入力し直さ
せようとするのか一切理解できない。
やり方
今回のワークでは、改善に比較的取り組みやすい「R」「I」の観点で
見つかる問題に絞ります。
① 問題のありそうな箇所に線を引く
R:黄色 I:ピンク
② 線を引いた理由を書く
自己紹介で書いてもらったバグについても、RIMGENのどれに分類で
きるのか、合わせて考えてみてください
- 34. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 34
ブレインストーミングのお約束
ブレインストーミングの4原則
1. 判断・結論を出さない(結論厳禁)
2. 粗野な考えを歓迎する(自由奔放)
3. 量を重視する(質より量)
4. アイディアを結合し発展させる(結合改善)
- 36. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 36
フォーマットに着目する理由
バグ票
開発者、テスト実施者間のコミュニケーションツール
バグを直してもらうためにやりとりする
コミュニケーション
直接
直接話す
Skypeなど
チャットなど
間接
メール
バグ票
レビュー記録表など
開発者、テスト担当者間の
コミュニケーション
間接的なコミュニ
ケーションになるほ
ど、一定のルール
が必要では?
- 37. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 37
フォーマットに着目する理由
間接的なコミュニケーションになるほど、一定のルール
が必要では? ルールの一例がフォーマット。
→フォーマットがないと、以下のような問題が起き、バグの
本質的な問題にたどり着くまでに時間がかかる
事象が一文で書かれるのみで、手順がない
複数の重要度の異なる問題が書かれ、結局何が問題なのか
がわからない
…などなど
フォーマットがあれば、
バグ修正開発者⇔テスト実施者(バグ起票者)の
ヒアリング時間は減らせるのではないか?
その分、バグ解決に充てられる時間を増やせる!
色々ありますよね…。
- 39. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 39
フォーマット化してみよう 所要時間:10 分
・改善案の検討議論
・これまでの話し合いから見えてきたポイントを盛り
込んで、バグ票のフォーマットに入るべき、項目をあ
げてみましょう
バグ票
項目1:表題
項目2:xxx
以下の内容について検討してください
• フォーマットの項目
• 自由入力か選択式
- 41. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 41
まとめ
下記の内容についてグループで発表していただきます。
・サンプルのバグ票に欠けているポイント
・そこから導き出されたフォーマット
- 43. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 43
RIMGENの観点に沿ってないときの問題点
RIMGENの観点に沿わないとどうなるか?
明確でないバグ票
バグが非現実的、
不合理として却下される
関係者間の信頼がなくなる
再現不能なバグとして
却下される
R
I
M G E
N
書き方で防げる問題ではないか?
システムへの理解とその説明スキ
ルが必要ではないか?
高め 改善難易度 低め
客観的に書くべきではないか?
修正されるべきバグに
フォーカスが当たらない
バグの内容を理解する
のに時間がかかる
- 44. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 44
「RIMGENの観点」について
バグ票の記載内容を改善するための6つの要素をそれぞれ頭
文字をとって”RIMGEN” と呼び、紹介されているものがある。
頭文字と簡単な内容を以下に記す。
※RIMGENそれぞれの日本語訳は、検討中のものです。よりよい案がありましたら、教えていただけると助かります。
要素 意味 内容
R Replicate
(再現性)
・再現できるか
I Isolate
(独立性)
・単純な手順となっているか
・冗長な要素や手順などは分けられているか
・1件/レポート となっているか
M Maximize
(発端性)
・最悪なことが起きるバグの兆候をみつけているか
G Generalize
(普遍性)
・プロダクトに対するバグの影響範囲を識別できているか
・そのバグは他の環境や条件で発生することはあるか
E External
(第三者性)
・プロダクト利用時にバグの影響範囲を開発者やテスト担当者、
開発組織外の視点から識別できているか
N Neutral
(中立性)
・困惑させるような推測や思い込みなどがない
・個人に対する批判や侮辱、いらつかせたり困惑させるような内
容がないか
- 45. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 45
さいごに
今回はフォーマットに着目しましたが、改善の流れはほか
でも同じ
①問題点の洗い出し
②問題点の分類
③改善案出し
④改善案の分類
お手軽で効果の高そうなところからTRY
- 46. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 46
さいごに
そもそもバグ票は…
バグを直してもらうためのも
の!!
繰り返しに
なりますが
- 47. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 47
本日お伝えしたいこと・・・バグ票への関心
SQiPシンポジウム終了後、みなさんに現場で
「バグ票の問題や改善を意識した!」
「バグ票の改善を始めたい!」
と思って頂くことが
本SIGの目標
バグ票×コミュニケーション
- 48. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 48
ご参加ありがとうございました。m(__)m
バグ票へ、もっと愛を・・・
「まだ話し足りない方がいらっしゃいましたら、情報交換会にて!」
- 49. Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 49
~お誘い~
興味をもっていただけたら、サイトを見てみてください。
バグ票に関する「思い」を共有しましょう!
問い合わせ先:sw.WorstPractice@gmail.com