読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST'15関西(2)「なんじゃこりゃ!このバグ票なんか腹たつ ~バグ票の失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術~」

 6/26(金)に開催されたソフトウェアテストシンポジウム2015関西(JaSST'15 Kansai)に参加しました。 私が参加したセッションは下記です。

聴講したセッション

セッション 1-1

 「アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的マネジメント」 平鍋 健児 (チェンジビジョン)

セッション A3-1

 「なんじゃこりゃ!このバグ票なんか腹たつ ~バグ票の失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術~」 近美 克行(バグ票ワーストプラクティス検討プロジェクト)

セッション A3-2

  「テストエンジニアの人材育成と 自己開発の秘密のレシピ ~エンジニア能力開発のすすめ~」 佐々木 方規(ベリサーブ)

セッション A3-3

 「チームで成功させるシステムテスト自動化 by Friendly.」 石川 達也 (Codeer)

セッション 5-1

 「フィリピンでのテストチーム立上げと マネジメントの秘訣!!」 田中 学二 (Klab Cyscorpions Inc)  「Being as a test engineer in the past and in the future (邦訳) フィリピンのテストエンジニアの想い ~これまでとこれから!!」 GERANGCO Angeli Marie (Klab Cyscorpions Inc)

 今回は、セッション A3-1「なんじゃこりゃ!このバグ票なんか腹たつ ~バグ票の失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術~」で印象に残った事を紹介します。

セッション A3-1「なんじゃこりゃ!このバグ票なんか腹たつ ~バグ票の失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術~」近美 克行(バグ票ワーストプラクティス検討プロジェクト)

(1)「バグ票ワーストプラクティス検討プロジェクト」のサイト

https://sites.google.com/site/swworstpracticesite/

(2)なぜ、バグ票?

  • 全員がバグ票を見ているため、コミュニケーションの問題を取り上げるには最適である。
  • ベストプラクティスの環境を整えるのが大変。
(3)問題事例
「バグ票炎上」

 テストエンジニアや開発者がやりとり相手をバグ票をやり合う。

例えば...
「酷いデグレードです」
「御社の開発力では将来があやぶれています」
「これはデグレではありません。デグレの定義...」

バベルの塔

 用語やルールが混乱し、バグの問題解決管理に支障をきたす。
→人員追加されている状況であるが、バグ票の書き方を知っているとみなし、バグ票の教育を十分やっていないことが原因。

「バグピンポン」

 テストエンジニアと開発者の間で発見したバグに同意がとれず、メールやバグ票が行ったり来たりすること。
→詳細は、森崎修司さんのblogを参照。

「何かがおかしい」

(4)バグ票が上手く使われていない状況
  • 役割を果たさないバグ票
  • ライフサイクルを廻る
  • パターン
    • 「ピンポン」
    • 「ストップ」
    • 「アバウト」
  • メーカー系や受託開発で問題がある
(5)問題の解決に向けて(テーマ3)

 WACATEの夜の分科会やソフトウェア品質(SQiP)シンポジウムのSIGで問題事例共有ワークを実施。

(5-1)対策

 事前に目的を共有する

(5-2)傾向
(5-3)得られたこと
  • 様々なドメインの方のドメインからの知見
  • 「問題事例を共有して「困った!」というと誰かが助けてくれる」
  • 立ち上げ時の事例も役に立つ
(6)One more things
(6-1)名古屋大学 戸田山先生
  • バグ票は開発文章
  • 伝える文章のための工夫

 「文章には相手と目的がある(べき)」
 「目的を上手く果たせる文章が良い文章」
 「効果的な書き方...」

 2名が書いた絵を見比べて1名が書いた文章が伝わるか実験し、課題で考えざる得ないことは下記などが挙げられる。

  • 文章の目的は?
  • 相手は?
  • 相手はどういう人?
  • 何を知っている?
  • 何を知らないか?
  • 知識を与えれば、目的のことをやってくれるか?
(6-2)TIPS:日本語
  • 主語省略、指示代名詞、係り受けのあいまいさ
     例:阪神に絶対に買ってほしい
  • 当たり前すぎることは書かない。
  • 量の格率(Paul Griceの理論)  要求に見合うだけの情報を発信せよ
     求められている以上の情報を発信するな
(6-3)チームの一体感を醸成しよう
  • 電話しよう!
  • バグの再現デモをしよう
  • 相手を飯に行こう!
  • 「読み手が変われば、書き方が変わる」

所感

 バグ票は、多くのエンジニアが目に触れる媒体である。それ故、文体のとらえ方によっては「けんか腰」に感じることもあるので、相手に誤解されないための転ばぬ杖として、「バグ票ワーストプラクティス検討プロジェクト」から発信される知見から学び、実践しようと思う。