Document Actions
書籍「基本から学ぶソフトウェアテスト」を元にした講義資料
書籍「基本から学ぶソフトウェアテスト」を元にした講義資料です。
書籍「 基本から学ぶソフトウェアテスト 」を元にした講義資料
対象読者
- ソフトウェアテストを勉強したい人
- 本を読むのが面倒で、手っ取り早くポイントだけ知りたい人
- アリエル固有のことは書いていないので、テスト技術者の教育担当者は、講義資料として使ってください
注意
- 「基本から学ぶソフトウェアテスト」を(意図的に)深読みして書いている部分もあります
- このため、実際に書籍に書いていないことも資料に含んでいます
- 客観的な「要約」ではないことに注意してください
1. テストの進め方
- テストの前に対象ソフトウェアを理解すること
- バグ1件ごとにバグ報告を書くこと(複数のバグを同じレポート内に書かないこと)
- 正しく動かないはず、と思ってテストすること
- 境界条件を意識すること
- 最小限の再現条件を探す努力をすること
- 普通の使い方(正常系)でまともに動作しない場合、テストの中断も考慮すること(時間の無駄かもしれないので)
- wontfix(修正しない)の返答に対して、その判断を無批判に受け入れないこと(プログラマはwontfixの判断をよく間違えるので)
- リリース間際の場合、修正しない判断には高度に政治的な背景があるかもしれないので、こだわりすぎないこと
格言:優秀なテスト技術者は多くのバグを見つけた者ではなく、最も多くのバグを修正させた者である
2. テストの目的と限界
- 完全なテストはできないことを知る
- 20行のプログラムで、全パスのテストに10億年かかる例もある
- 完全ではなく、十分なテストをするしかないことを知る
- テストの目的は、ソフトウェアの正しさの証明ではない
- テストの目的は、ソフトウェアが誤っていることの証明(=バグの発見で証明)
- 誤報(正しい動作をバグと見誤ること)を過度に恐れる必要はない
- バグを見落とすことの方が大きな損失
- もちろん、常識的な範囲で。正常系でまともに動作しない時に異常系のバグ報告を沢山するのは非常識(ただし、この判断は簡単ではないのでプログラマに相談すること)
- 重複バグを過度に恐れる必要はない
- 同一バグ報告を探すのにかける時間は5分で十分(5分で見つからなければ新規にバグ報告する)
- 格言:バグを検出したテストが成功で、バグを見つけられないテストは時間の無駄だ
- => 微妙
3. テストの種類と位置付け
- バグは早く見つけるほど良い
- バグの修正ミスは驚くほど多い(些細な変更で修正ミス確率50%、大きな変更で修正ミス確率80%というデータすらある)
- 副作用バグも驚くほど多い(verify重要)
- 専門用語を知らないことはそんなに気にしなくていい(知りすぎると変な人になる)
4. ソフトウェアエラー
- テスト技術者の仕事はバグを見つけて報告すること。最終的な仕事の目的は製品の品質を向上させること
- 「品質」とはバグの多寡だけではない
- 「品質」とはソフトウェア製品の顧客満足度そのもの
- 「バグの多寡=信頼性」とするならば、「信頼性向上」は「品質向上」の1部
- バグ(=ソフトウェアエラー)の一般的な定義: プログラムと仕様の間の不整合 => 仕様が明確かつ正しい場合にはこの定義でもOK。しかし、現実の仕様は曖昧で、かつ正しいとも限らない
- バグの実際的な定義: 利用者が期待しているような動作をしないこと
5. 障害の報告と分析
良いバグ報告とは
- 再現手順が明確
- 再現手順が最小限
- バグ報告はすぐに書くこと
- バグ報告には事実を書くこと(意見がある場合、事実の記述と分けて書くこと)
- 感情的にならないこと
- プログラマを非難するような表現は謹むこと(慈愛の心)
- どうやっても再現できないバグは「再現できない」旨を明記してバグ報告すること
再現条件がいかにプログラマにとって大事か分かる話:
書籍「プログラマーのジレンマ」から抜粋
坂道を下る途中で車が故障した時の話。 ハードウェアエンジニア「分解してすぐに修理します」 ソフトウェアエンジニア「車を坂の上まで戻して、故障が再現するか確かめましょう」
- 再現可能なバグはたいてい修正できる。再現不可能なバグの修正は難しい
格言: バグ報告を書く目的は、バグを修正してもらうことである
6. 障害管理システム
- プログラマがバグを修正しない言い訳をしても感情的に反応しないこと
- 副作用バグは、現象が異なれば別のバグ報告にすること
- 再現しない、と冷たく突き返されても怒らないこと
- バグ報告に書いた再現手順を見直す、もしくは実際に再現してプログラマに見せること
プロジェクトマネージャの憂鬱 - こんな行動がプロジェクトマネージャを困らせる -
- バグ報告への質問に返答がない
- verifyがなかなか実施されない
- テスト技術者が意地になってバグ報告のreopenを繰り返す
- マカー(「このUIがMacっぽくありません」報告)
格言: 障害管理システムを部下の考課に使ってはいけない。特にバグの報告数でテスト技術者の能力をはかってはいけない。
7. テストケースの設計
- (組合せや状態遷移の)場合分けは、頭の中だけで考えず、書き出すこと
- 直感を信じること(勘の働くのがプロ)
- バグを見つけた手順はテストケースとして文書化すること
- テストケースが増えすぎたら減らすことも考えること(バグを見つけられないテストで疲弊するのは長期的にはマイナスなので)
- ずっとバグがでないテストケースは思い切って削除する
- 回帰テストを構造化すること(毎バージョン行うテスト、2、3バージョンごとに行うテスト、もっと間隔を空けて行うテストなど)
- リリース後に見つかったバグは、そのバグを再現できる手順をテストケースとして文書化すること
11. テストのツール
スキップ
13. 開発全体におけるテストの役割
- プログラマにしてみるとよい質問「もしあなたが考えてもみたくない最もおぞましい部分でバグを発見するとしたら、そこはどこですか?」 => 実はプログラマの無意識は、バグがどこにあるかを知っています。本人の力だけでは無意識を認識することはできないので対話で引き出してください
リリース前テストの指針
- 実践テスト: 普通の人が初めて使う気持ちで実施するテスト(素直な気持ちで)
- 修正済の致命的なバグの再テスト
- 再現性が低くて未修正のバグの分析
- 最後のverifyに手を抜かない(ただでさえ多い修正ミスがリリース直前には更に増えます)
RC(リリース候補)後のテストの指針
- 致命的なバグ(showstopper)を見つけることに集中すること
- (今さら変更しようのない)ユーザインターフェースの提案をRCに対してするのは非常識
- 古いバージョンでテストしないこと
- wontfixは普通だと思うこと
- 社内がピリピリした雰囲気でも引かないこと
無事リリースできたら
- みんなで拍手
15. テストチームの管理
作業見積りの指針
- テスト作業の見積り時間は多いのが普通。少ない場合は何かを見落としている
- 大幅オーバーの作業に優先度をつける。低優先度の作業を全部できないのが普通と思っておくこと
優秀なテスト技術者とは
- 誠実さ、品質に対する責任感
- 理論よりも経験をもとに根拠を見つける能力
- 優れたコミュニケーション能力や高い文章能力
- パズルが得意なこと
- 効率という概念を持っていること
- 同時に多くの仕事をこなせること
- 他の人の気持ちが分かること
格言: 虐待から部下を守ることは、テストチームのマネージャの重要な使命である