Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a QA improvement
Semelhante a QA improvement (20)
Mais de Sadaaki Emura
Mais de Sadaaki Emura (14)
QA improvement
- 3. Self introduction 3 2000年 松下通信 デバイスドライバ ソフトウェアエンジニア 2002年 Yahoo! Japan ヤフオクBtoC エンジニア、チームリーダー 2007年 楽天 楽オク 運用リーダー 楽天競馬 エンジニアリーダー 楽天学割・プレミアム プロデューサー OSPDグループ QAリーダー Hobby Career ジョギング、登山、PS4
- 7. Ice break 7 Q. テスト実行において最も評価すべきポイントは？ 1. 見つけたバグの総数 2. 誰も思いつかないバグの数（レアバグ） 3. 開発に修正させたバグの数
- 9. Ice break 9 Q. テスト実行において最も評価すべきポイントは？ 1. 見つけたバグの総数 2. 誰も思いつかないバグの数（レアバグ） 3. 開発に修正させたバグの数
- 14. What’s testing 14 ■1. 欠陥を摘出する ■2. ソフトウェアの品質レベルが十分であることを確認する ■3. 意思決定のための情報を示す ■4. 欠陥の作りこみを防ぐ ISTQB Foundation Level Syllabus
- 15. Find defect 15 ■1. 欠陥を摘出する https://www.pakutaso.com/20161149306phpcompanyo.html • 修正に値しないバグはない • 重要なバグをすばやく見つける • 開発に適切な情報を伝える :
- 16. Find defect 16 https://www.pakutaso.com/20161149306phpcompanyo.html Small defect has big impact こんなサイト信頼できますか？
- 17. Find defect 17 https://www.pakutaso.com/20161149306phpcompanyo.html Small defect has big impact こんなサイト信頼できますか？ • サイトの信頼性低下 • ユーザー混乱 • バグの馴れ合いの体制
- 18. • 修正に値しないバグはない • 重要なバグをすばやく見つける • 開発に適切な情報を伝える Find defect 18 ■1. 欠陥を摘出する https://www.pakutaso.com/20161149306phpcompanyo.html http://jp.freeimages.com/photo/sniper-1438100 ✓ 修正した箇所をテスト ✓ 特殊処理より基本機能をテスト ✓ リスク（影響）の大きい機能をテスト ✓ 開発がテストしてほしい部分をテスト Ex. Find important defect quickly
- 19. Find defect 19 こんなことありませんか？ これでテストケース足りるの？ では追加します。工数は増えます まじ？ リリース日は死守でね どこまでテストするんだ？ 開発 開発 QA QA Find important defect quickly https://www.photo-ac.com/main/detail/136433
- 20. Find defect 20 Find important defect quickly 何故起きるか？ • 開発がテストの網羅性で不安 • QAは自分のテストケースに自信を持てない • テストケースをとりあえず増やせば、安心は増えそう（みんな） テストに納得ができていない
- 21. Find defect 21 Find important defect quickly みんなが納得できるテスト設計（ダメなケース） https://www.ac-illust.com/main/detail.php?id=652958 • 設計書のコピペ • 設計書からいきなりケースに落とす https://www.ac-illust.com/main/detail.php?id=454029 • テストの目的が不明確 • 網羅性ばかりに目がいく • やらなくてよいケースまでテストしてしまう
- 22. Find defect 22 Find important defect quickly みんなが納得できるテスト設計（良いケース） • テストの目的（テスト観点）を明確にする • リスク等からの優先度付けをする • 何故テストするかを理解できる • 網羅性の担保が安心できる • やらなくて良いテストが理解できる 目的 目的 テストケース テストケース テストケース テストケース テストケース • 絞って重要なところからテストできる
- 23. • 修正に値しないバグはない • 重要なバグをすばやく見つける • 開発に適切な情報を伝える Find defect 23 ■1. 欠陥を摘出する https://www.pakutaso.com/20161149306phpcompanyo.html ✓ 中立な立場 ✓ バグレポートの価値を高める ✓ 誰が見ても理解できる ✓ トレース、分析できるようにする Ex. https://www.photo-ac.com/main/detail/149715 Give appropriate information
- 24. Find defect 24 Give appropriate information こんなことありませんか？ [JIRA-XXXX] XXXX 障害 ○○がよくうまく動かない
- 25. Find defect 25 Give appropriate information こんなことありませんか？ 開発からして • 具体的にどう動かないのだ？ • どうやったらそうなるんだ？ • バグの内容、それによるリスク • 明確な再現手順で開発の手間削減 • 補助情報で原因調査削減 https://www.pakutaso.com/20140408101ol-6.html
- 26. Find defect 26 Give appropriate information こんなことありませんか？ [JIRA-XXXX] XXXX 障害 何回もバグがRE-OPENしています。 ○○さんは単体テストやってるんです か？
- 27. Find defect 27 Give appropriate information こんなことありませんか？ 開発からして • 一緒に仕事したくなくなる • 開発のプライドが傷つけられる • バグを憎んで人を憎まず • バグの情報提供に徹する https://www.pakutaso.com/20140604162post-4223.html
- 28. Find defect 28 Give appropriate information こんなことありませんか？ [JIRA-XXXX] A 障害 Aのバグが解決したことを確認できまし た。ありがとうございます。 ただ、その影響でしょうか、Bの機能が 動かなくなりました。確認してもらえま すか？
- 29. Find defect 29 Give appropriate information こんなことありませんか？ みんなからして • なんのチケットだっけ？ • 全ての課題は解決してる？ • バグの集計面倒だ • 1バグ１チケット • 脱線しない https://www.photo-ac.com/main/detail/140949
- 30. Find defect 30 Give appropriate information 模範レポートの要素例 再現 バグの発生頻度。稀に発生するものか等？ 分離 テスト環境の変更でバグの状況が変わるなど可変要素を一つずつ変更しながらバグ の挙動を観察することで、深い障害レポートを作成できる（原因の特定化） 比較 アプリバージョンの変更（新旧）などで挙動の違いを調べる（デグレかどうか） 要約 ステークホルダーが認知しやすいレポートにまとめる 凝縮 不要な情報を削る あいまいさの排除 混乱、誤解を排除する 中立化 プログラマの非難などしない テストは情報サービス産業である バグレポートの価値を高めよう
- 31. Check quality level 31 ■2. ソフトウェアの品質レベルが十分であることを確認する https://www.photo-ac.com/main/detail/331209 • 仕様書に対する合致性の確認 • 品質を保証するためのエビデンス :
- 32. Give information for decision 32 ■ 3. 意思決定のための情報を示す http://jp.freeimages.com/photo/gavel-2-1236453 • リリースしてもよいのか？ :
- 33. Give information for decision 33 リリース時の判断に使われます テスト完了レポート リリース OK 残バグ Critical 0件、Major 1件、Minor 5件 リスク • ○○機能は本番でのみ検証可能とのことで、テスト未実施 • ○○機能は不具合件数が多く、全て改修済みだが要注意 • リリース時の品質レベルを伝える • バグはゼロに出来ないことがある • リリースリスクがどこにあるのか
- 34. Prevent defect 34 ■ 4. 欠陥の作りこみを防ぐ • 仕様書のバグを見つける • バグを産みそうな所を指摘 • バグ分析とフィードバック : http://jp.freeimages.com/photo/knight-0-1-1565479
- 35. • 仕様書のバグを見つける • バグを産みそうな所を指摘 • バグ分析とフィードバック Prevent defect 35 ■ 4. 欠陥の作りこみを防ぐ ✓ あいまいな表現 ✓ 暗黙の仕様 ✓ 論理矛盾、漏れ等 Ex. ※開発も含めて不明確な実装がなくなる https://www.photo-ac.com/main/detail/993991 Find specification bug
- 36. 36 こんなことありませんか？ Prevent defect Find specification bug • 検索結果の表示が速くなる • 4歳以上18歳未満ではXXX、１８歳以上24歳以下では○○○ • 団体になると２０％引き • ボタンをクリックすると○○機能が正常終了すること • AかつBまたはCのとき、○○機能が稼動する
- 37. 37 こんなことありませんか？ Prevent defect Find specification bug • 検索結果の表示が速くなる • 4歳以上18歳未満ではXXX、１８歳以上24歳以下では○○○ • 団体になると２０％引き • ボタンをクリックすると○○機能が正常終了すること • AかつBまたはCのとき、○○機能が稼動する 速い定義は？ 具体的な処理は？ 記述のゆれ 団体の定義は？ 条件が複雑 事前につぶすことで、開発・テスト工程に不具合の種をブロックする
- 38. 38 Prevent defect Find specification bug カテゴリ 概要 詳細 追跡可能性 要件・仕様に対して機能が 追跡できるか？ 要件が正しく分解され、後工程の成果物に漏れなく、一意に紐 づく 理解容易性 記述・定義が一意な表現に なっているか？ 分岐条件や結果が一意に判別できる 統一性 記述のゆれ・バラつきがな いか？ 用語のゆれ、仕様定義や参照定義のバラつきがないこと 保守性 ドキュメント体系、管理IDが 明確になっているか？ 成果物関連図が定まっており、トレーサビリティの取れる管理 体系 国際性 日本語特有のあいまい表現 がないか？ 「未満、以下、あれ、これ、たいてい」などのあいまいな表現 試験性 仕様の漏れ、論理矛盾がな いか？ 観点、因子、水準の洗い出しができること。組み合わせた場合 の期待値が明確に洗い出せること
- 39. Prevent defect 39 ■ 4. 欠陥の作りこみを防ぐ https://www.pakutaso.com/20140154007post-3674.html • 仕様書のバグを見つける • バグを産みそうな所を指摘 • バグ分析とフィードバック Analyze bug and give feedback ✓ 次回のテストでバグの出そうなところ ✓ 次回の開発の改善 Ex.
- 40. Prevent defect 40 Analyze bug and give feedback 次の開発～テストのプロセス改善として… • 仕様書の課題（含めてほしい情報等） • テスト環境の課題 • 欠陥を産みやすいところ（バグが顕著な機能等） • QA内で改善しないといけないところ
- 42. Ice break 42 Q. テスト実行において最も評価すべきポイントは？ 1. 見つけたバグの総数 2. 誰も思いつかないバグの数（レアバグ） 3. 開発に修正させたバグの数 再掲
- 43. Ice break 43 Q. テスト実行において最も評価すべきポイントは？ 開発に修正させたバグの数 ■1. 欠陥を摘出する ■2. ソフトウェアの品質レベルが十分であることを確認する ■3. 意思決定のための情報を示す ■4. 欠陥の作りこみを防ぐ バグを見つけ、適切なバグレポートを伝える ユーザーが満足する品質かをチェックする ユーザーが満足する品質としてリリースであることを示す 開発と共存してバグを減らす