"Rapid Software Testing"のスライドを読んでみた:(2)Key Idea(前編)
前回は、"Rapid Software Testing"の概要についてまとめました。
(※詳細は、"Rapid Software Testing"のスライドを読んでみた:(1)概要を参照下さい。)
今回は、"Rapid Software Testing"のKey Idea(前編)です。
"Rapid Software Testing"の資料(再掲)
下記サイトの右側の囲みにある"RST Slides(pdf)"を参照下さい。 →http://www.satisfice.com/info_rst.shtml
念のため、ファイルの参照先を下記に示します。
→http://www.satisfice.com/rst.pdf
注意(再掲)
本稿は、英訳が誤っている可能性がありますので、"Rapid Software Testing"の資料で紹介したスライド(英語)をご確認下さい。また、スライドの内容を抜粋してまとめていますので、詳細を知りたい方はhttp://www.satisfice.com/rst.pdfを一読下さい。
「バグが発生したとき、どうやって知るか?」(スライド52~64ページ)
(1)Oracle
Oracleは、テスト中に現れる問題を認識することを意味する。
(2)Oracleは「完全でない!」そして、テスターは「判断しない!」
(2-1)もし何かがバグであっても『確実に』知る必要ない。
もし何かがバグであっても『決断すること』が仕事ではない。
(2-2)誰かが重要だという意見の製品の価値を取り扱う『かもしれない』と理にかなった信念を形成することが必要である。
- そう考えた理由を言うことができるようになるべき。
- 良いoracleを引用できるようになるべき。さもないと、信頼性を失うだろう。
(3)Oracleの一般的な例
- 意見は人の状況に左右される
- 合意しないことはは人々の状況間にある
- 知られている良い例のアウトプット
- 知られている悪い例のアウトプット
- 有益な情報の参照ドキュメント
- アウトプットがチェックされた過程やツール
- テスターがパターンを識別することを手助けする過程やツール
- 例えば混乱またはいらだちなどを感じること
- 関連したことの間の一貫性のある望ましいこと
(4)Oracleで重要なテーマの一貫性
[1]熟知していること
この製品は類似問題のパターンに一貫性が無い。
[2]説明できること
製品は説明できる能力があると一貫性がある。
[3]世界
この製品は、世界を示す状態を物体と一貫性がある。
[4]歴史
[5]印象
[6]製品比較
[7]要求
[8]ユーザの望み
[9]製品
[10]目的
[11]規則と標準
(5)『内から外へ(the Inside Out)』からのoracle
(5-1)軸
- 暗黙⇔明確
- テスター⇔他の人々(テスター以外?)
(5-2)暗黙なテスター
テスターの感覚とメンタルモデル。
(5-3)暗黙なテスター から 明確なテスターへ
観察可能な一貫性。
(5-4)暗黙なテスター から 暗黙な他の人々へ
ステークホルダの感覚とメンタルモデル。
(5-5)暗黙なテスター から 明確な他の人々へ
共有された中間成果物
(6)全てのOracleは経験則である
(6-1)我々はよく前もって確信した結果が合っているか結果が間違っていることを確立するoracleを持っていない。
→だから、我々は経験的にoracleを利用しているのです。
(6-2)単一なoracleは、プログラム(または機能)が全ての時間や状況で正しく働いているかどうかを教えてくれない。
→だから、我々は多様なoracleを利用しているのです。
(6-3)あなたにとって、いくつかのプログラムは動作しているようだけど、事実は全てのoracleでばかげたことが起こることに失敗するかもしれない。
→だから、謙虚かつ批判的に考えることを始めているのです。
(6-4)あなた(テスター)は、複数の結果についての深い真実を知ることができない。
→だから、バグのようであることは何でも報告するのです。
(7)Oracleの問題の違いに対処
(7-1)問題を無視
「だからどうした?」と問うこと
(7-2)問題の単純化
- テスト容易性を問うこと
- 自動的なOracle→内部エラー検出または外部出力の分析
- 水準を下げる
(7-3)問題を替える
- 並列なテスト
- 生きた知恵→専門家や熟練者を見つけよ
(7-4)問題を分割統治する
[1]抜き取り検査
一連の出力以外の実態を詳細な検査を行う。
[2]Blink test
目立つパターン用データの圧倒的な束を見直すか比較する。
[3]容易な入力
分析しやすい出力を入力に利用する。
[4]容易な出力
入力にかかわらず、出力が明らかに間違っている。
[5]初めにUnit Test
断片から全体へ自信を得る。
[6]徐々にテスト
ある期間にわたったテストによって自信を得る。
(8)品質基準は様々
- 能力
- 信頼性
- 使用性
- カリスマ
- セキュリティ
- 拡張性
- 互換性
- 性能
- 設置性
- 開発
「どうやって適切な時期に正しいテストを生み出せばよいか?」(スライド65~87ページ)
- 探検としてテストを扱え
- 早まった形式化を抵抗せよ
(1)探索的テストは自己制御されたテストである。
- 探索的(Exploratory)なふるまいは、自己制御である。
Exploratory:価値を探し求めている
- 筋書き(Scripted)なテストのふるまいは、自己制御はない。
Scripted:実行できるタスク
(2)探索的テスト(Exploratory Test)と筋書きなテスト(Scripted Test)を一緒にしてみよう!
探索的テスト(Exploratory Test)の中で筋書きなテスト(Scripted Test)を活かし、筋書きなテスト(Scripted Test)の中に探索的テスト(Exploratory Test)を活かそう!
(3)Testingの形式的で連続的なつながり
[1]非形式的
特定の方法で実施しないか、仕様の要因に合っているか否か確認しない。
[2]形式的
特定の方法で実施、または仕様の要因に有っているか否かを確認する。
[3]非形式的⇔形式的の軸
<非形式的>自由にテスト - 探索的に調査 - 分析的探索 - 製品の対象範囲の概略 - テスト条件の概略やマトリクス(※) - 特定のテストデータ - ざっくり/生成されたテストスクリプト - 人のチェック - 人間トランシーバ(?) - 機械チェック<形式的>
※この範囲までが探索的テストとしたい。
(4)Testing
経験によって学習する。また、調査(研究)、質問、モデリング、観察、推測でも学習する。
(5)探索的な働きは、構造的プロセスである。
(5-1)(Michael Boltonが教えている)テストは...
スキルを有するテスターまたは劣ったテスターか監督しているマネージャにより構造的なプロセスである。
(5-2)テストの構造は、色々な出所からやってみる
- テスト設計経験則
- Chartering
- タイムボックス
- 認識されている製品リスク
- 仕様テストの特性
- テストされている製品の構造
- 製品を学習する過程
- 開発の活動
- プロジェクトによって与えられた制約と資源
- テスターのスキル/才能/興味
- 全てのテストの使命
(6)経験則は、問題解決能力への有用な構造をもたらす。
(6-1)形容詞
見つけるための奉仕
(6-2)名詞
問題解決または決断することのための誤りを犯しがちな手段。
(6-3)技術手法は、経験則を利用することで有効的な手段の中の貧弱な理解の状況を良く変えさせる。(Billy Vaughan Koen, Discussion of The Methodより)
(6-4)経験則
[1]命令ではない。
経験則はスキルのある実践者のガイダンスや統制である。
[2]コンテキスト依存である。
[3]お互いに反対しているときに有用かもしれない。
特にテスターが実施するとき。
[4]完全で厳密な分析に代用できる。
(6-5)経験則のタイプ
- ガイドワード
- 経験則の要因?(Trigger Heuristics)
- 経験則の代用
- 経験則モデル
- 経験則の手順またはルール
- 認知的経験則
(6-6)経験則は適用されるけど、なかなかできない。
例1:呑んで運転は危険だ
例2:明日の百より今日の五十("A bird in the hand is worth two in the bush.")
例3:虎穴に入らずんば虎子を得ず("Nothing ventured, nothing gained.")
例4:時々、人はパソコンのそばにpasswordを隠す。(パソコンのそばを見てみよう!)
(7)探索的テストは、構造化されたプロセスである。
- 優秀な探索的テストは、1つの構造が他の全ての構造に影響をもたらす傾向がある。
- 探索的なテスターは、テストが説得力のある話で積み上げている。
- 探索的テストがバックボーンを与える。
(8)テストすることは、3つ+αのストーリーを構築することである。
(8-1)レベル1
「製品の状態についてのストーリー」
色々なクライアントにとって重要である方法でどうやったら製品が失敗する?
(8-2)レベル2
「どうやってそれをテストするかについてのストーリー」
- どうやって設定し、操作し、観察するか?
- 「製品はいくらか役に立つ?」
(8-3)レベル3
「テストの価値についてのストーリー」
- テストのコストとリスクについて...
- どうやって製品がテストしやすくなるには、...である。
- 「どうやって知る?」
(8-4)レベル3+
「ストーリーの価値についてのストーリー」
- メタストーリー?
- 何が起きたか知っているか?
- 報告できるか?
- 報告することで目的を達成できるか?
- 「何故、その仕事を喜ぶべきか?」
(9)もし、不満なら焦点をぼかしましょう!
- 過去のテストや見つけたパターンを見逃そう!
- 次の僅かなテストで古いパターンを破ってみよう!
- MFAT(そのときの複数の要因)を選ぼう!
- 見解を変え、広げよう!
(10)もし、混乱したら焦点を絞りましょう!
- テストをシンプルにしましょう!
- できるだけ製品を使いながら、保守して、製品の状態を小さく乱そう!
- 頻繁に行動を繰り返そう!
- 頻繁に知っている状態に戻ろう!
- OFAT(そのときの1要因)の経験則を選ぼう!
- 見解を精密にしよう!
(11)テスト設計と実行
(11-1)製品または仕様とテストアイディア
実際にテストしながら違うテスト設計を探索することで優秀なテスト設計をアーカイブする。
(11-2)テストアイディアと製品
自己管理とテストアイディアの簡潔な文章でテスターをガイドしよう。その間に、テスタ自身がガイドできるように訓練し、増加するcheckingの仕事への責任がかかれるようにしよう!
(12)自由に時間が使える自己管理を許容することは良い。
(12-1)どれくらい、進捗を報告するか?
毎分?毎時間?毎日?
(12-2)もし、全て自律的であったら、以下をリスク投資できますか?
- 学習
- 思考
- アプローチを洗練
- より良いテスト
(12-3)もし、自由に時間が使えなかったら...
(12-4)よい投資で以下ができるかもしれない
- 製品のあらゆることを学習した
- よりパワフルなテストを考案した
- バグを見つけた
- より良い仕事ができた
- 長い袋小路に向かうのを避けた
- マネージャが驚き、好印象を与えた
(13)"Plunge in and Quit"(急落したらやめる)
- とても複雑かゾッとするテストする度に、急落する! 少し急落した後、非常に混乱するか自身が動かなくなるのが分かったら、やめる!* 成功裏に終わることに合意せずに何かを始める、結果として計画は必要無い。という意味
- いくつかのサイクルは、計画を見つけるために良い方法である。
(14)探索的枝分かれ;気を散らすことは良い!
新しいテストのアイディアは、探索的テストのセッションの中で継続的に起こる。
(15)"Long Leash(長い紐)"経験則
- 自身で気を散らせると...
- 見つけることを知ることができなくなる
- 定期的に使命に備えた状況を見積もる
所感
JSTQBのソフトウェアテスト標準用語集で"Test Oracle"の用語があり、"oracle"がイメージしにくいと感じていましたが、Michael Boltonの「テスト中に現れる問題を認識すること」の解説でガッテンしました。また、製品と取り巻く事/取り巻く物/取り巻く人に対し、問いかけることもテスターの可能性を拡げることではないかと思いました。
次回
残りのKey Ideaについて、まとめてみます。