先週届いたJames Whittakerの本を読みつつtwitterにつぶやいているので、今まで書いた分のまとめを貼っ付けておく。
# Exploratory Software Testing 2章もうちょいで読み終わり。9:48 PM Sep 17th from web
# Manual TestingとScripted Manual Testingの違い。後者はテストケースの粒度は関係なくテスト手順が存在している。例えば、数字をテキストボックスに入力するとして、テスト手順は「数字を入力する」でも「10を入力する」のどちらでもよい。9:52 PM Sep 17th from web
# 2種類のExploratory Testingの考え方。 Exploratory Testing in the SmallとExploratory Testing in the Large。9:54 PM Sep 17th from web
# 2種類の違いは探索するスコープの大きさ。9:54 PM Sep 17th from web
# 本の例だと旅行を使ってて、「何処に行く」、「何をする」、「何時行く」、「何処に泊まる」といった大きなスコープで旅行を計画していくのがLargeのほう。9:56 PM Sep 17th from web
# XXXレストランで、ワインはfoo、メインディッシュはbarみたいに小さいスコープで考えて行くのがSmall。9:57 PM Sep 17th from web
# ソフトウェアに戻ると、テスト対象ソフトウェアのXXX画面とか、XXX画面のテキストボックスみたいに小さいスコープで考えるか、テスト対象のソフトウェア全体の動作をスコープとして考えていくのかといった感じ。9:59 PM Sep 17th from web
# 3章、4章で各Exploratory Testingについて説明してくれる。10:01 PM Sep 17th from web
# Scripting と Exloratory Testingはうまく組み合わせて使うと良いと言っている。10:02 PM Sep 17th from web
# James Whittaker曰く、「Exploratory TestingはIT産業の中でも最も挑戦的で満足感のある仕事」。 激しく同意。10:05 PM Sep 17th from web
# James Whittakerの本は見事なまでにバグを見つけることに力を注いでいるから好き。How to break Softwareのシリーズは特に。10:17 PM Sep 17th from web
# デベロッパーがバグを上手く見つけることができるなら、彼らはそもそもバグのあるコードを書かないのでは？ そこには死角がある。彼らはアプリケーションを"作る"ことに視点を置いている。10:27 PM Sep 17th from web
# デベロッパの視点はHow can I build thisでテスターの視点はHow can I break this.10:28 PM Sep 17th from web
# とは言ってもデベロッパーによるテスト、例えばTDDとか、を否定しないというか、UNITテストはそのコードを書いたデベロッパーがするべきと信じている10:30 PM Sep 17th from web
# バグを見つけるには[a second set of eyes]も必要。[a second 〜]って「別の視点」って感じか？10:34 PM Sep 17th from web
# この辺を意訳＋αすると、ブランチカバレッジ100%だったとしても、機能として間違ってたらだめだから開発視点でのテストもユーザ視点でのテスト両方重要ってことでおk?10:37 PM Sep 17th from web
# Exploratory Testingは3章の1/3まで読んだ。about 4 hours ago from web
# 今日のまとめ。テスターのタスクは3つの問いに答えること。about 4 hours ago from web
# 1. ソフトウェアは設計されたとおりに動くか？about 4 hours ago from web
# 2.ソフトウェアの機能はユーザが望んだ通り動くか？about 4 hours ago from web
# 3.ソフトウェアは十分に速くセキュアで信頼性が高く、その他色々か？ その他色々はISO9126にあるような品質特性で良いんだと思う。about 3 hours ago from web
# Jame Whittakerは軍事関係、OS、アンチウィルスエンジン、普通のアプリ、ゲーム、webアプリなど色々テストしてきたらしい。about 3 hours ago from web
# 彼のテスト手法というか考え方の一つは、ソフトウェアは入力・出力・データ・計算で成り立っているという考え方。about 3 hours ago from web
# Inputについて、Inputは必ず、ソフトウェアの実行・レスポンスを伴う。テキストボックスに文字を入力しただけではInputとは言えなくて、入力した内容をボタンを押すなりして、ソフトウェアに渡して初めてInputと言ってるabout 3 hours ago from web
# Inputにはatomicとabstractの2種類がある。atomicは4とか、1000とかまさしく即値。about 3 hours ago from web
# abstractなInputの目的はInputの内容を選択できること。例えば1から1000まで好きな値を選択してよいとか。about 3 hours ago from web
# abstractのInputではテスト手法の一つの同値クラスが出てくるabout 3 hours ago from web
# 「ブラックボックステストの場合、同値クラスで入力を考えるのは正しいけど、ほんとにそれであってるかはソースコード見ないとわかんないよ」とも言ってる。about 3 hours ago from web
# 確かに、ブラックボックスで入出力だけ考えれば、有効同値クラス・無効同値クラスの2種類しかないけど、実装上はもしかしたら有効同値クラス内でデータでも条件によって処理が変わってるかもしれないわけで・・about 3 hours ago from web
# テスターは「他のどれよりもベターな1つの入力を見つける」能力を鍛えろと言ってます。ベターな入力==バグを見つけられる入力about 3 hours ago from web
# oops、有効同値クラス・無効同値クラスが2種類って言ったのは純粋に種類が2個ってこと。about 3 hours ago from web
# 「How to test User Input」の節では「あんたのソフトウェアは特別ではないことに気づこう」と言ってる。about 3 hours ago from web
# これは、どんなソフトウェアだろうと、入力・出力・データ・計算の4つの処理で成り立ってるからという考え方に基づいている。about 3 hours ago from web
# 不正な入力に対する対策は3つ。Input Filters, Input Checks, Exception Handlersabout 3 hours ago from web
# Input Filterは、プルダウンリストとかみたいなユーザが自由に入力できずに、デベロッパーから与えられた値のみを選択できるようにするパターンabout 3 hours ago from web
# Input Filterに対してテスターは、「デベロッパーは正しい方法を選んだか？」と「フィルターの裏をかく方法」を考えるabout 3 hours ago from web
# 「フィルターの裏をかく方法」は自分も普段テストでやってる。ようはまともな方法で自由に値を入れられないなら、他の方法で無理やり不正な値を入力するとか。これは、セキュリティが重要なソフトでは超重要なことだと思う。about 3 hours ago from web
# 今日はInput Filterまでしか読んでないので、まとめは終了〜about 3 hours ago from web
