ソフトウェアテスト293の原則(第3章/第4章)

ソフトウェアテスト293の鉄則

■■第3章 テストの技法

■048：テストの五大要素をいつも念頭に置け

1. テスト実施者
2. 網羅性
3. 発見したい問題
4. 作業内容
5. 結果の判定方法

■050：網羅性に着目したテストは,どこまでテストするかがポイント

• 関数テスト⇒UTテストコードで網羅可能（と思う）
• 機能や関数の組み合わせテスト⇒これもUTテストコードで網羅可能とみた
• メニューツアー：GUIを備える製品で全てのMenuを動かす
• ドメインテスト：変数に着目したテスト
• 境界値テスト
• 最適な代表値によるテスト
• 変数テスト⇒P60参照
• 入力フィールド用のテストマトリクス⇒P52参照
• フィールドの変更の仕方を明確にしたテスト
• 論理テスト
• パステスト
• 状態遷移テスト
• カバレッジテスト
• 繰り返し発生する問題用テスト⇒P55参照
• 仕様書/要求に基づくテスト
• 組み合わせテスト

■051：問題に焦点をあてたテストは,どんなリスクがあるかがポイント
下記、よくバグであがるもの

• 演算処理上の制約
• メモリに関する制約

■052：作業に焦点をあてたテストは,どうテストするかがポイント
下記、あまりやったことないもの

• ゲリラテスト：経験値が高いテスタに一定期間内で攻撃的なテストを一気に行う
• インストールテスト

■■第4章 バグの報告

■057：障害レポートを商売道具として活かせ

• バグを修正することで得られるものを明確にする
• 反論を予期して対応しておく

■061：他人の障害レポートの書き換えは安易にやるな
追記情報として上書きはしない。また日付と名前が確実に追記情報に入るようにする

■065：障害管理システムをプログラマの評価に使うな
あくまで技術的目的で使用すること。士気を下げてはいけない

■066：障害管理システムをテスト実施者の評価に使うな
報告バグ数とバグの中身は全然別の話

■072：修正に値しないバグはない

• 修正が4時間以内で済み、かつ同じ苦情が繰り返しそうな「安価な修正」に対応していると、サポートコストは半分に軽減というレポート
• 軽微な欠陥は信頼を下げる

■073：優先度と重要度を区別せよ

• 優先度：会社としていつまでか
• 重要度が高くても（X年X月以前のデータは壊れる）優先度は低いかもしれない（X年X月のデータはもう入力不可）

■075：些細なコーディングエラーを見つけたならテストを追加せよ
様々に条件を変化させてテストをしてみる

• テストの行動様式を変える（実施内容を変えることで条件を変える）
• アプリの設定を変えてみる（テスト対象プログラムに変更を加え、条件を変化させる）
• 環境を変更してみる

■076：再現しないエラーも全て報告せよ。時限爆弾になる恐れがある
これは、やらないかもなー。統計では修正可能なのは、「再現しないバグ」の20%しかないと言われているらしいが、やっぱり報告

■077：再現できないバグはない
ホントはそんなものないんだよ。確かに！

■081：重複した障害レポートは問題解決促進剤になる

• 検索できるようにしてあること
• 相互に参照可能なこと
• 問題が解決するまでCloseさせないこと

■082：障害レポートは1件に1葉
よくやる人がいる。DB化できないし混乱するから複数キチンと記載する

■085：問題点をはっきり報告し、解決策は書かない
解決策には複数あるかも知れない。最適な1手を見逃させることになる

■090：障害レポートをクロスレビューせよ
これはやったことないかも。テスタのレベルがあがるし、PG側からの要望もあるだろしやった方がいいな。

■091：相手に直接会っておこう
報告書を読む人を知っておくと全然違う。これは大事だ。絶対。大きいPJであればあるほどそうだ。

■094：バグ確認は鮮度が命

• 修正者に対しての敬意。信頼関係でバグFIXが加速しやすい
• 報告が遅れるほど、修正者は忘れていく

■095：修正が失敗していたらプログラマと直接話し合おう
これも確かに。レポートも必要だけど直接は大事だ、絶対