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

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

メモ取りながら読み始めたので、メモを随時UPしていこうかと。書き出して分かったのは「テスト」なのにあたしの興味はやっぱり「人間系」なんだな。ってこと。テストチームはプロジェクトを巧く成功に導くために、どういうスタンスで、人とどうやって接しなきゃいけないか。ばかりが気になるらしい。

• • • • • • • • • -

筆者たちは「ベストプラクティス」というものを信頼しない。最適な手法は状況に応じて異なると信じているからだ。

■■第1章 テストという仕事
テストの役割とは一体なにか？

■001：プロジェクトの行方を照らせ
具体的な役割はPJによって異なるが、基本的には「情報を見つけ出すこと」

■002：常に目的を意識せよ
PJによって異なる自分の職務を常に考えること

• 顧客の立場で製品評価/バグを見つける/顧客のためにありとあらゆることをするetc

■003：テストは幅広い顧客へのサービス業だと心得よ
テストとは「サービス」をすること。テストの成果は、どれだけ顧客の要求や利益に貢献できたかで決まる

• 対PM ⇒ 情報を提供することでボトルネックにならない
• 対PG ⇒ 即修正できるよう、的確な障害レポートを出す

■005：重大なバグを素早くみつけよう

• 修正した箇所をまずテストすること
• 周辺機能より先に、基本機能（売り）をテストすること
• 複雑なテスト（信頼性の評価）より、「機能がきちんと動くかどうか」をテストすること
• 特殊な条件を与える前に、普通の条件でテストすること
• 特殊なエラーより先に、一般的な障害やエラーでテストすること
• 影響の大きいバグを狙ってテストすること
• テストして欲しいと開発側が望んでいる部分をテストすること

■006：プログラマとは二人三脚で進め
素早いフィードバックで、修正テストのサイクルを、小さく素早く回す。テスト担当者ではなく、PGがボトルネックになるくらいが理想

■007：口には出さなくてもいろいろ疑問を持とう
ただし、いきなり核心をつく質問はPGを保守的にさせてしまう。効き目の強い薬（＝質問）は 少しずつ飲む。食事と一緒に摂取することが肝心

■008：プログラムの失敗を成功の母とせよ

• ×「プログラムが正しく動作することを検証する作業」　⇒ほぼ不可能
• ○「プログラムが動かないことを証明する作業」⇒1件のテスト項目で可能

■009：バグを全部見つけるのは無理だと心得よ
全てテストすることは不可能であることを理解し、限られた時間をどう使うか考える

■010：テスト「完了」と聞いたら注意すべし
「完了」ということばの定義は難しいため、常に定義の意味を確認しあうこと

• バグを全部見つけた/全部チェックした/現時点で最も有効で効率の良いテストを実施した
• 定義した目的を達成できるよう全力を尽くした/事前に決めたテストを全て終えた
• 浅いが全ての範囲をテストした/自分の担当箇所は終えたetc

■011：テストで品質が保障できるなどど思うな
品質保証は全ての部門の協力で行えるもの。自分だけが頑張ってるオーラは出さないこと

■013：「私の仕事じゃありません」 と言ってはならない
テスト担当者たるもの、広い視野を持つべき。様々な状況に順応し、臨機応変に対応することが「私の仕事」と考えて動く

■014：プロセス改善グループには気軽に変身するな
バグの数を減らすために、プロセス改善に手をつけるのはいいが、プロセス改善は、本当に大変。気をつけて。

■015：みんながテストを知っているわけじゃない
テストについて分かってもらう、要望を出すのはテストチームの責務。特にPGへの説明は、効果があり痛くもないが、繰り返しが必要なインフルエンザの予防接種と同じ

■■第2章　実践的テスト担当者の思考法
テストとは、整然と認識論を駆使することであり、愚痴主義ではない

■016：認識論を駆使すること
認識論は、いかにして問題を扱うかという問題を扱う学問

• ソフトウェアが十分に良いと、どうやって知るのか？
• 十分に良くないとしたら、どうやって知るのか？
• 十分テストしたと、どうやって知るのか？

■019：テストは思考の産物だ
テスト担当者の能力の差は、テスト設計の選び方、観察したものの解釈と報告力である。良いテスト担当者を見つけたら、考え方を学ぶこと

■024：テストは質問の答えを探す作業である
テストとは、製品のあるべき姿と現状の差異を確かめる作業。

■025：モデリングはテストの決め手だ
テストを設計する時、元になるのは製品のモデルであって、製品自体ではない。ということは、モデルがテストのよしあしの全てを決めてしまう。

■026：直感は糸口として有用だが,判断の根拠に使ってはならない
直感は先入観にとらわれがちなので、きっかけ程度にとどめておくべきだ。

■030：推論と半鐘の方法論で製品を評価せよ

• 製品が正しく動くことより、製品に「障害がある」ことを見つける方が効果的
• 「こんな風に動くはず＝定評」は必ず反証できる。定評は信仰にすぎない

■032：要求仕様書をあてにするな
文書としての要求仕様が要求の全てではなく、打ち合わせ/推論/参考文献 の全てが要求である。

■034：「動いた」本当の意味を確認せよ
「動く」＝「ある要求を、ある程度満たしている」に言い換えてみる。定義は人によって曖昧だし、言葉を補わなければ疑問が残る

■042：混乱をテストに生かすべし
混乱は、なにか重要なことを示唆しているかもしれない。問題点や質問としてあげることが重要。製品の製造について関わっていないテストチームだからこその特権

• 仕様が混乱の元
• 製品が混乱の元
• ユーザードキュメント
• そもそも分かりづらい

■043：慣れは見落としの素,新鮮な眼をいつも絶やさずに

• チームに新しく参入した人とは、一緒にテストをして観察する
• テストが型にはまると、バグが発見しづらくなる。時々担当を変えよう

■044：手順に従うのではなく,手順を従わせる
そもそも、テスト手順に全ての事柄を記載するのは不可能。もし手順に完全に従うなら、自分で設計したものか、完全理解したものに限る。そうでなければ、テスト手順をテストチームに従わせる。

■045：「1287文字入力せよ」などと書いてはいけない
具体性は行き過ぎると役に立たない。手順書には、コンセプトと直接関係のない特定の値を書くべきではない。必要な情報や具体的事項は書いておくべきだが、基本的には次回の担当者が創造性や判断力を発揮できる余地を残すことは必要

■046：テスト技術者の成長もテストの成果の一つである
テストプロセスを評価する際には、テスト担当者の質を見てから行うこと。テストの価値は、ドキュメント量ではなく、テスト担当者の質だ。