More Related Content
Similar to QA improvement (20)
More from Sadaaki Emura (14)
QA improvement
- 18. • 修正に値しないバグはない
• 重要なバグをすばやく見つける
• 開発に適切な情報を伝える
Find defect
18
■1. 欠陥を摘出する
https://www.pakutaso.com/20161149306phpcompanyo.html
http://jp.freeimages.com/photo/sniper-1438100
✓ 修正した箇所をテスト
✓ 特殊処理より基本機能をテスト
✓ リスク(影響)の大きい機能をテスト
✓ 開発がテストしてほしい部分をテスト
Ex.
Find important defect quickly
- 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
- 25. Find defect
25
Give appropriate information
こんなことありませんか?
開発からして
• 具体的にどう動かないのだ?
• どうやったらそうなるんだ?
• バグの内容、それによるリスク
• 明確な再現手順で開発の手間削減
• 補助情報で原因調査削減
https://www.pakutaso.com/20140408101ol-6.html
- 27. Find defect
27
Give appropriate information
こんなことありませんか?
開発からして
• 一緒に仕事したくなくなる
• 開発のプライドが傷つけられる
• バグを憎んで人を憎まず
• バグの情報提供に徹する
https://www.pakutaso.com/20140604162post-4223.html
- 29. Find defect
29
Give appropriate information
こんなことありませんか?
みんなからして
• なんのチケットだっけ?
• 全ての課題は解決してる?
• バグの集計面倒だ
• 1バグ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
- 37. 37
こんなことありませんか?
Prevent defect Find specification bug
• 検索結果の表示が速くなる
• 4歳以上18歳未満ではXXX、18歳以上24歳以下では○○○
• 団体になると20%引き
• ボタンをクリックすると○○機能が正常終了すること
• 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内で改善しないといけないところ