Recommended
More Related Content
What's hot
What's hot (19)
Similar to レビューのコツ
Similar to レビューのコツ (20)
Recently uploaded
Recently uploaded (7)
レビューのコツ
- 1. グルメなテスト テスト設計 - レビュースペシャル - QA Engineer 米山 允章 (Yoneyama Yoshiaki) 株式会社メルカリ / Mercari, Inc. https://www.mercari.com/jp/ 「レビューのコツ & レビューのお悩み一問一答」
- 2. 自己紹介 ● 米山 允章 ● なぜここに立っているか ● 社外活動 Web QA Meeting JaSST Tokyo 2
- 3. アジェンダ 3 1. 私が経験したレビューの事例 (6分) 事例1 金融系システム 事例2 ソーシャルゲーム 事例3 モバイルアプリ 2. 皆さんの20のお悩みに個人的な意見で答えてみる (18分) 3. レビューの基本 (3分) 4. まとめ (1分)
- 7. レビューフェーズ 7 ① 要件レビュー（対面） ② 設計書レビュー（対面） ③ テストケースレビュー（対面） ④ テスト結果レビュー（机上）
- 8. ツール 8 Excel
- 12. 事例2 ソーシャルゲーム 12
- 13. ① 要件レビュー（机上） ② 設計書レビュー ③ テストケースレビュー（対面） ④ テスト結果レビュー ⑤ 障害振り返りレビュー（対面） 13 レビューフェーズ
- 14. ツール 14 スプレッドシート
- 17. 事例3 モバイルアプリ 17
- 18. (① 要件レビュー) ② 設計書レビュー ③ テストケースレビュー ④ テスト結果レビュー ⑤ 障害振り返りレビュー 18 入社当初（4年前）
- 19. ① 要件レビュー（大きな案件のみ） ② 設計書レビュー ③ テストケースレビュー（大きな案件のみ） ④ テスト結果レビュー（机上） ⑤ 障害振り返りレビュー （Slack） 現在 19
- 20. ① 要件レビュー ② 設計書レビュー ③ テスト観点レビュー ④ テスト結果レビュー ⑤ 障害振り返りレビュー (私の)理想 20
- 23. レビューのお悩み (1/20) 参加者により、いちいち些細なことをつつき進められない。 [私の回答] ● 分かる ● レビュアー変えましょう ● 些細なことにはさっと返して次に進めましょう ● ファシリテートするのも大事な仕事 23
- 26. レビューのお悩み レビュー対象について、レビューイより仕様を把握していないながら もレビューしなければならない場合に、どのようにレビューを進める と効率が良いのかを聞きたいです。 （レビュー対象が多い時ほど起こりがちな悩みです） [私の回答] ● 分かる ● まずは自身で今回の変更箇所の把握を本気でする ● その上でケースを確認して疑問に思った所は遠慮せずに 質問する ● レビューの依頼を受けたのだから自信持って 26 レビューのお悩み (4/20)
- 27. レビューのお悩み 短期間で効率よくレビューをするための準備が難しい 27 [私の回答] ● 最も優れた（レビューして欲しい）レビュアーの ペースに合わせて進める レビューのお悩み (5/20)
- 29. レビューのお悩み 量が多過ぎて 全てを見ることができない 29 [私の回答] ● 今回の仕様変更箇所が多すぎるなら、レビューを分ける ● 変更箇所より、リグレッションや毎回行っているケースが 多いのであれば、そこはレビュー対象から外す レビューのお悩み (6/20)
- 30. レビューのお悩み 会社で初めてのQAで、先輩にレビューをしてもらった経験が ないので、レビューの仕方があっているのか間違っているの かがわからない 30 [私の回答] ● 多分正解は無い（プロジェクトによってベストが異なる）の で、試行錯誤してみる ● 他社や他チームの人と話してみる ● 改善案が思いついたらメンバと話し合い、試してみる レビューのお悩み (7/20)
- 31. レビューのお悩み レビューしても抜け漏れがありそう 31 [私の回答] ● 実際に抜け漏れた観点から学びを得る ● 範囲を広げて優れたレビュアーを探す ● 開発者やPにレビューしてもらう レビューのお悩み (8/20)
- 32. レビューのお悩み 仕様把握仕切れない 32 [私の回答] ● 要件レビューを行う ● 変更箇所を把握する（PRを見る/開発者に聞く） ● 日頃からプロダクトを触る / 担当箇所以外にも興味を持 つ レビューのお悩み (9/20)
- 33. レビューのお悩み レビュアによりレビュー結果にバラつきがある 33 [私の回答] ● しょうがない ● まずは自分も優れたレビュアになる ● レビューでの有益な指摘を他のレビュアーも学ぶ ● レビューへの準備/臨み方で改善できる可能性はある （優秀なレビュアーの日頃の行いや準備は何か違うはず） レビューのお悩み (10/20)
- 34. レビューのお悩み テストケースが充足しているかの判断がむずかしい。 （テスト設計のお悩みは非機能要件が弱い） 34 [私の回答] ● それが簡単だったらテストケース作成も自動化できちゃう ● 非機能要件も広いけど、本番環境でしか確認できない部分（パ フォーマンス）等はプロの方に任せるのも手 ● 通常のテスト観点であれば、やりながら学んでいくことが大事。 過去の障害を参考にしたり、障害振り返りをちゃんとやりながら 改善していく レビューのお悩み (11/20)
- 35. レビューのお悩み レビューに時間がかかってしまう。 35 [私の回答] ● 見直した方が良いこと ○ そのレビュー中に議論すべきではない話で時間を費やして いないか ○ レビュー前にセルフレビューしているか ○ 他のメンバのレビューでも同じか ○ 指摘の粒度は細かすぎないか （指摘事項の横展開はレビューイに任せるとか） ○ そのフェーズで話すべきことか ○ レビューというタスクの優先度 レビューのお悩み (12/20)
- 36. レビューのお悩み テスト設計者の考慮漏れに気づけているかという不安が あります 36 [私の回答] ● 少なくとも自分が設計した場合に作るであろうケースがカバー できているか ● どこまで頑張るかは不具合が発生した際のリスクにも応じる ● テスト設計に不安が残るようであれば、探索的テストを厚めに するとか レビューのお悩み (13/20)
- 37. レビューのお悩み レビュー観点？というものはどのように形式知化、展開していくべ きか。 37 [私の回答] ● 観点や仕様はWikiに纏める ● レビュー内容を他のメンバも見れる場所に置く レビューのお悩み (14/20)
- 38. レビューのお悩み 勤務先の企業にレビュワーを育てる文化がなく、レビュワーを育て ることが困難である 38 [回答] ● レビュアーを育てる文化なんてそうそうない ● 多分その案件で実現したいこと（ビジネス面含む）の本質と、漏 れがちな影響範囲の二面がレビューの肝 ● 前者に対してはPとのコミュニケーション、サービスの現状把握 ● 後者に対しては観点をwikiに残す、バグから学ぶ、日頃から有 益なレビューを体験してもらう、プログラムの動き方は最低限学 んでもらう レビューのお悩み (15/20)
- 39. レビューのお悩み 有識者の参画割合がメトリクスとなっているが、そもそも有識者と いう定義があいまい [私の回答] ● たしかに ● ”プロジェクトにアサインされてる期間？" 定義について納得す るまで議論すべし ● “最低１人有識者を含めること” みたいな話であれば納得感はも てる 39 レビューのお悩み (16/20)
- 41. レビューのお悩み 「レビュー」という単語に対しての解釈がバラバラ 41 [私の回答] ● バラバラなことでどんな弊害が出てるのでしょうか？ ● 社内勉強会で啓蒙活動するのは有効 レビューのお悩み (18/20)
- 42. レビューのお悩み レビューのボリュームが多く、時間的に全部は見切れない 42 [私の回答] ● 全て今回の新規実装部分に対するケースなのでしょうか？ ● そうであれば見るべき ● 終わらない分は机上で見るとか ● 気になる所だけ観点を大枠で確認するだけで、大体満たせる ことも結構ある レビューのお悩み (19/20)
- 43. レビューのお悩み どのようなレビューが所謂"いいレビュー"なのかがイマイチ分から ない。 43 [私の回答] ● レビューのフェーズで要件漏れや開発時の考慮漏れを発見し て、QA前に不具合を収束させる ● そのレビューで議論するべきことだけが議論されている ● レビュー時間が速い ● 考慮漏れを指摘してもらえる レビューのお悩み (20/20)
- 44. 最悪なレビューとは 1. レビュアーがやる気ない 2. レビューの場で話すべきではない議論で多くの時間が費 やされる 3. 予定通りレビューを行うこと有りきで、成果物が出来てな い 4. 観点が漏れてても指摘はでない 5. レビューを設定するのも大変 (≒優先度が低い） 44 最高のレビューはこの逆 最悪なレビューとは
- 45. レビューの基本のき 45
- 58. まとめ 58