http://jasst.jp/symposium/jasst18hokkaido/timetable.html JaSST'18 HokkaidoのLT資料です。 プロジェクトを横断して、不具合を共有している話を紹介しました。

1. 1No Input Signal

2. プロジェクトを横断して
不具合レポートを書いている
Fusic
吉武 伸泰
2
2018/11/30
JaSST’18 Hokkaido LT
(アフターツアーでのレビュー対応版)

3. 自己紹介
•吉武伸泰 (よしたけ のぶひろ)
－@yoshitake_1201
•Fusic のテストエンジニア
•テスト酒場 in 福岡幹事
•JaSST九州 実行委員
•九州ソフトウェアテスト勉強会
ツッコミ役です
3

4. 私の仕事＝Web系のテスト
• 私は基本プログラム書かない
• 受け入れテスト（ or システムテスト）
－Vモデルでいうところのあの辺↗を担当している
• 1ヶ月に複数の案件をテストする（平均5件ぐらい)
4
案件数は、月の忙しさや
テスト期間によって異なります

5. 本日の悩み！
5

6. 同じ不具合を
報告する
6

7. 同じ不具合報告→どういうこと？
• 同じ時期に複数の案件のテストがある
↓
• たまたま似たような案件が重なる
↓
• 同じような不具合を見つける
7
1人の人が同じ不具合を何回も出してる
わけじゃないよ！

8. そこで
8

9. 不具合を事前に
共有しよう！
9
と思った！

10. 不具合を共有
• 複数の案件を横断的に関わっている
－僕が不具合を共有したら効率的！
• 不具合発見→修正する作業はもったいない
－ 1回作ったものを直すのは大変
－ 手戻りはコストが多い
• 発見→チケット→対応→確認する（影響度も気にする）
10
どういうテストするよ！って事前に知ってたら
それを想定して開発したらいいから作り直し少なそう

11. アプローチ
月に1回
レポートを書く！
11

12. 月に1回のレポート
• 社内Wiki（tamel）というのがある
－何かあったらtamelを書く文化がある
－ものすごく自由度が高い
• 本当に何でも書いていい。
（ルービックキューブの解き方や、個人のメモなどもある）
12
何かを書く→共有するというアプローチがライト！
→「レポートを書く」という点で乗り越えるハード
ルがない

13. レポートの内容
• 今月よく報告した不具合
－そもそもはこれをなくして品質向上したい
• 驚いた不具合
－僕も驚いた ＆ 開発者も驚いた意外なもの
• コラム
－好きなことを淡々と
• (OKボタンとキャンセルボタンどっちに置く？など）
13
• レポートに載せる件数は最大でも4件ぐらい
－読みたい人だけ読んで！というスタンス
－情報が多いと読まれにくそう（読まれる努力は大事）

14. 結果
14

15. なんかいい感じ！
15

16. レポートの感想
• 非常に良記事！（F越さん）
• ホントに良記事。（Y田さん）
16
関わった案件で「よかったUI」なども教えてほしい！
というコメントも（ちなみに2回目からシリーズ化）
← slackで「ナイスtamel」emojiももらった！

17. レポートの副産物
• 会社全体の悩みがわかった
－新人のスキルとか…
－新技術の注意点とか…
• レポートと銘打ってシリーズ化したことで
新人も探す＆読みやすい（気がする）
17
まだ3回しかやってないので
今後続けるとまだまだ出てきそう！

18. 今後やりたいこと
• このレポートの効果測定をしたい
－このレポートを通じて不具合が減ったのか？
• 不具合そのものを分析した結果を載せていきたい
－どの段階で発生した不具合なのかや、その対策なども
－せっかくなら貯めたチケットを有効活用したい
18
レポートの読者も増やしていきたい！