"Rapid Software Testing"のスライドを読んでみた：(3)Key Idea(後編)

　"Rapid Software Testing"のスライドを読んでみたシリーズの最終回です。今回は、"Rapid Software Testing"のKey Idea(後編)です。
(※前々回及び前回の詳細は、"Rapid Software Testing"のスライドを読んでみた：(1)概要及び"Rapid Software Testing"のスライドを読んでみた：(2)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を一読下さい。

　ここから本題に入ります。

「どうやってテストを成し遂げるか？」(スライド88～92ページ)

　手順を知ること。

(1)テスト手順

(1-1)テストの行動は、複数あるテスト戦略の一部を満たす一連の調査である。

(1-2)テストケースは、関連したインスタンスやテストの変化やテストのアイディアの1つである。

(1-3)テスト手順は、テストを実行する方法である。

(1-4)ポイント

何の役割を演じるか？
何の役割でツールを使うか？
誰が手順を制御するか？
文章化すべきか？どうやって？

(2)テスト手順の4要素

(2-1)設定

(必要に応じて)テストのために製品を入手
(必要に応じて)インストールのプラットフォーム
(必要に応じて)テスト実行のためにテストデータとツールを準備
製品が"十分にクリーン"な開始状態を保証

(2-2)操作

製品を練習するためのインプットのプラットフォームと製品を制御する。
製品を正しいデータで正しい順番で正しい機能や状態を練習させる。

(2-3)観察

　評価できるために(直接または間接のどちらかのアウトプットを集める)製品がどのようにふるまうことについて情報を集める。

(2-3)評価

　バグ検出するためのoracleを適用する。

(3)テスト完全性を最大限にすること

(3-1)焦点を絞れ!

既知の(クリーンな)状態からテストを始めよう！
単純や確定的な行動を選ぼう！
仕様のモデルへのテストの段階を追跡しよう！
確立され構成された実験の順番を追ってみよう！
仕様の予測、観察、記録させよう！
(自動テストの援助を得ながら)簡単に再生させよう！

(3-2)焦点をぼかせ！!

違う状態から始めよう！(クリーンである必要はない)
やりがいのある行動で複雑なものを選ぼう！
色々なモデルからテストを生成しよう！
実験的手順やツールを質問しよう！
全ての予想を見てみよう！
よりテストが再現できる代わりにテストを厳しくしよう！

「全ての製品をどのようにテストするか？」(スライド93～109ページ)

　多様なリスクベースドな戦略を利用しよう！

(1)テストプロジェクトのコンテキスト

(1-1)使命

重要な問題を見つける
品質を評価する
標準認証
プロセス委任を果たす(?)
ステークホルダを満足する
説明責任を保証する
品質保証について助言する
テストについて助言する
品質について助言する
効率を最大化する
コストを最小にする
時間を最小にする

(1-2)要求

製品の使命
ステークホルダ
品質基準
参照資料

(1-3)テストラボ

テストのプラットフォーム
テストツール
テストのライブラリ
問題トラッキングシステム
事務所の設備

(1-4)テストチーム

専門知識
負荷
団結
動機
リーダシップ
プロジェクトの統合

(1-5)開発

製品
プロジェクトライフサイクル
プロジェクト管理
構成管理
欠陥予防
開発チーム

(2)テスト戦略

(2-1)戦略

(2-2)兵站

(2-3)計画

(2-4)良いテスト戦略は...

製品の仕様
集中的なリスクベース
多角的
実践的

(2-5)計画 = 戦略 + 兵站

(3)戦略を立てる1つの方法

製品を学習する
潜在的な重要な問題を考える
製品の問題を探す方法を考える
全般の製品を探す方法を考える

　以下の方法も考える。

優位にリソースを確保できるとしたら...
異なる技術で混合することからなったら
本当に実際に動作できる何かからなったら
期待することが実現できる仕様の使命を果たせたら

(4)「優位なリソースを獲得する」意味とは何か？

(4-1)使命

　顧客にとって解決する問題

(4-2)情報

　製品かプロジェクトがテストにとって必要なことについての情報

(4-3)開発関係

　プログラマと共に獲得する方法

(4-4)チーム

　誰かがテストをサポートすること

(4-5)設備とツール

　テストを管理するために要求されるH/WやS/W、ドキュメント。

(4-6)スケジュール

　プロジェクトにおけるイベントの順番、持続、同時発生すること

(4-7)テストアイテム

　テストされた製品

(4-8)納品物

　テストプロジェクトの観察できる製品

(5)「...テストする方法」は？？

　一般的なテスト技術

機能テスト
ドメインテスト
ストレステスト
フローテスト
シナリオテスト
要求テスト
ユーザテスト
リスクテスト
自動チェック

(6)どれ位テストを実施したら十分なのか？

　多様な中途半端なやり方

バグを見つけるための単一の技術は無い。
技術を完全にやることができない。
全ての考えられる技術をやることができない。
中途半端なやり方を適用する

　「たとえ誰も戦略が完全にできないことでも、多くの違った視点、アプローチ、技術を使おう！」

(7)簡素化した要因がその問題を見つけることとしての価値(またはリスク)

一般的に製品の問題
テスト合格かテスト失敗を考える代わりに問題 vs 問題なしを考慮する。
効果的なテストは顧客が製品にどう価値があるかに関連することとして標準の理解が必要

(8)テストって何？

顧客に提供すること。
もしテストの使命が何か理解しなくかつ合意していないなら、「急速に」先がなくなる。

　そうならないようにするには、

　「使命を知る」→「共感し始める」→「リスクを追跡する」

(9)簡素的な要因としてのコスト

できるだけ注意深くquick testsをやってみよう！
Quick testは、価値としては安価である。しかし、小さな準備や七機または実施する時間が要求される。

　例えば

入力を強制的に攻撃
狂気なクリック
Shoeテスト(訳注：キーボードを押しっぱなしにして、自動的にキー入力を繰り返す安価なストレステスト。メッセージウィンドウのOKボタンを押しっぱなしにするようなこと。)
Blink Test
エラーメッセージの持ち越し
リソースの枯渇
複数のインスタンス
クレイジーな設定
安っぽいツール

(10)テストを繰り返されることはできるか？

　一部分だけは...

制御できる要因がテストの目的を実現するために重要かもしれないことが正確にできない。
それで、「繰り返しテスト」することはいくつかのテストが重要な部分を繰り返すことを信じるという意味である。
たとえ、「たった1%にテスト」を繰り返しても、あらゆる点でテストを繰り返していることを言うことに対し公平であるだろう。

　「繰り返すことを強要するのは選択肢ではない。」

(11)テストは繰り返されるべきか？

(11-1)コストと価値を考慮すること。

(11-2)いままでまだやっていない複数のテストから工場することを考慮すること。

(11-3)テストすることは、質問することである。

　何故、同じ質問を繰り返し聞くのか？(繰り返し繰り返し...以下略)

(11-4)繰り返しテストすることは、何故～なのか？、何故～でないのか？を知るべき。

(11-5)バグを探すために色々突っつく

微少な振る舞い
ランダム
データの置き換え
プラットフォームの置き換え
タイミング/同時並行の変化
シナリオの変化
状態の汚染
感性と期待

(12)"A Heuristic Test Strategy Model(経験則によるテスト戦略モデル)"

　プロジェクト環境(進め方のリスク)＋品質基準(oracleのリスク)＋製品要素(対象範囲)
→テスト(多様性、コストvs価値、スキル、経験)
→把握された品質(報告)

「どうやってテストを記録するか？」(スライド110～129ページ)

ドキュメントのモジュールはテストのストーリーを教わることを手助けすることを簡単に利用する。

(1)テストドキュメントについての共通した要求

新しいテスターにとって必要だ。
法的責任をそらすために必要だ。
他のテスターとテストを共有するために必要だ。
再現性のために必要だ。
説明責任のために必要だ。
テスト戦略について考えさせるために必要だ。

　「これらの要求は間違っている。この問題は分かりますか？」

(2)ドキュメントの第一法則

(2-1)文章化するべき

(2-2)本当の意味

　「いつ、どのように目的を供給するときは、文章化するべき」

誰か、このことを読み取れますか？
理解できますか？
コミュニケートするための情報として良い方法ですか？
文章化のコストは何ですか？

(3)テストドキュメントの共通する問題

最適なテストを実施することからテスターをいつも妨げたり、気が散る。
書いた人は、テストを理解していない。
書いた人は、自分で整理しない。
テンプレートは、貧弱な思考を隠すのを助長する。
完全に失敗する。
読み手のやる気が失せたり、保守コストがかさんだりする。
誰もドキュメントの要求を知らない。
書式が多く、保守コストがかさむ。
異なる聴衆者にとっての情報が共に混ざる。
ありそうなユーザの代わりにまれな聴衆者に応じる
社会生活の情報を妨げる
長期的なゴールと短期的なゴールが衝突する
ほとんどの方々は読まない。

(4)自動的記録を考慮せよ

探索的テストは製品が毎回のテストで何でも自動的記録が網羅されるとき、よく機能する。
Spector(www.spectorsoft.com)のような外部記録ツールを利用することもできる。
自動的記録は、テストされたことのスクリプトを振りかえるようなものを手にすることを意味する。

(5)ノートを取る

(5-1)網羅

(5-3)手順(手がかりになる要素のみ)

(5-4)テストアイディア

(5-5)バグまたはリスク

(5-6)問題、質問と例外

もし、変化したまたは加えたら、テストを実施することが容易になるだろう。
どうやって、...は働いているのか？
テストを実施することで重要か？どうやってテストすべきか？
奇妙な...を見た。

(6)高度で説明責任な探索的テスト

(6-1)チャータ

　セッションで明確な使命

チャータは、テストすべきことやどのようにテストされるか、問題を探していることを提案する。
チャータは、詳細な計画である必要は無い。
一般的なチャータは、最初に必要なことかもしれない。
特定のチャータは、良い具合に焦点が合っている、だが設計することにより手間がかかる。
　例：「クリップアートの挿入をテストせよ。負荷とフローの技術に焦点を当て、様々な文章に挿入することは必ず実施すること。リソース漏れや超過時間になる性能劣化について考慮する。」

(6-2)タイムボックス

(6-2-1)テストが継続する時間を固定するように努力することにフォーカスする。

(6-2-2)タイムボックスの時間

短時間：60±15分
標準的時間：90±15分
長時間：120±15分

(6-2-3)ポイント

正確な報告に十分な時間で要約する
スケジューリングを柔軟に許可するのに十分な時間で要約する。
流れを修正することを許可するのに十分な時間で要約する。
まとまったテストが完了するのに十分長い。
効率良く報告するのに十分長い。
非常に正確なタイミングに気をつける。

(6-3)見直し可能な結果

(6-3-1)読み取れるセッションシート

(6-3-2)チャータ

　テスト領域

(6-3-3)開始時間

(6-3-4)テスター名

(6-3-5)概要

継続時間
テスト設計と実行
バグ調査とバグ報告
セッションのセットアップ
チャータまたはチャンス

(6-3-6)データファイル

(6-3-7)テストのメモ

(6-3-8)バグ

(6-3-9)問題

(6-4)報告(フィードバック)

テスターが複数の質問に答える。
セッションのメトリクスはチェックされる。
チャータは調整してもよい。
セッションは延長してもよい。
新しいセッションは、チャータされたかもしれない。
指導が発生する。

(7)TBS(Test Bug Setup)の概要の報告

Test, Bug, Setupは、直交したカテゴリである。
チャータの割合の見積は、各々のカテゴリへ機能する。
5～10%は、十分によい。
行動が同時に行われているなら、最も高い優位な行動を報告する。
優位に行く順番は、Test→Bug→Setup
本当に欲しい全ては、テストすることを邪魔することを追跡することである。
見積にチャンスなテストを含めない。

(8)行動の階層

　全テスト

(8-1)非セッション(推定)

(8-2)セッション

チャンス
チャータ上

　Test
　Bug
　Setup

(9)対象範囲

(9-1)特定のカバレッジ領域

(9-2)セッションシートのチャータセッションでリストされた文字ラベル。

(9-4)特定のカバレッジ領域の妥当性をチェックすることの報告を利用せよ

(9-5)正しい要素でテストしているか？

(9-6)リスクベースドテスト戦略か？またはカバレッジ領域のセットが偏っているか？曲解された報告か？

(10)テストサイクルを推定することのデータを利用

(10-1)テストサイクルで完全にチャータを利用したテストはどれだけあるか？

　例えば、40サイクル。

(10-2)1日辺りにチームメンバーでできたセッションはいくつあるか？

　例えば、4名のテスターが3日テストしたら、12。

(10-3)セッションの手順はいくつあるか？

　例えば、66%はチャータによるテスト設計と実行である。

(10-4)推定

　[(10-1)の値]/([(10-2)の値]×[(10-3)の百分率]) = 40/(12×0.66) = 5日

(10-5) ベースとなるデータが集まった。

　複数の条件や予想の裏側で予測が変わったとき、予想結果を更新するだろう。

「どうやって効率的に報告するか？」(スライド130～142ページ)

　正しい質問を引き起こす説得力のあるストーリを教えることを学べ。

(1)報告で考慮すること

安全な報告者
クライアント
ルール
報告の重大さ
報告の件名
他のエージェントの報告
媒体)
正確さと信頼の水準
「コミュニケーションに責任を取れ」

(2)ダッシュボードのコンセプト

大きな専用のホワイトボード「消すな！」
プロジェクト用会議室
プロジェクトステータスのミーティング

(3)テストサイクル報告

製品領域 vs テストの成果
テストカバレッジ
品質評価 vs 時間

(3-1)製品領域

(3-1-1)種類

file または edit
view
insert
format
tools
slideshow
online help
clipart
converters
install
compatibilly
general GUI

(3-1-2)15～30領域

　シンプルに！

(3-1-3)副領域を避ける

　さもないと、混乱するぞ！

(3-1-4)領域は、粗目で等価な価値にすべき

(3-1-5)領域は、共にいつでも程よくテストしやすいことを含めるべき

　「製品領域」は、タスクを含めることができるかリスクを含めることができるか、しかし最後はタスクもリスクも入れる。

(3-1-6)領域間の重複は最小にせよ。

(3-1-7)領域は、クライアントまたは取締役会を使わないように「筋を通す」すべき。

(3-2)テストの成果

(3-2-1)成果の度合い

(3-2-1-1)なし

　テストしていない。テストの計画は無い。

(3-2-1-2)開始

　まだテストしていない。しかし、まもなく開始するつもりである。

(3-2-1-3)低

　回帰テストやスポットテストだけやっている。保守的なカバレッジ。

(3-2-1-4)高

　テストの成果に焦点。カバレッジは増加。

(3-2-1-5)停止

　領域ではテストできるのに、一時的にテストは中断されている。

(3-2-1-6)ブロックされた

　問題にブロックしているのが原因で、効率的にテストできない。

(3-2-1-7)出荷

　後のテストで手順の締めくくりな状況

(3-2-2)その他

重大な問題または「ブロックされた」「なし」「停止」のような停滞するものは、赤を表示する。
一度最後のテストで緑色のshipは完了し、他の全ての列が緑である。
「開始」「低」「高」といったその他は、他は黒や青、但し1色のみの中立な色を使う。

(3-3)テストカバレッジ

(3-3-1)レベル0

　この領域は良い情報が無かった。

(3-3-2)レベル1

　整合性検査。主要な機能と単純なデータ。

(3-3-3)レベル1+

　更なる整合性検査。しかし、いくつかの機能はテストしていない。

(3-3-4)レベル2

　批判的な常識なテスト。全機能は触った。

(3-3-5)レベル2+

　いくつかのデータや状態、エラー網羅は、レベル2を越えた

(3-3-6)レベル3

　複雑なケース。強力なデータ、状態、エラー、ストレステストをやっている。

(3-4)品質評価

(3-4-1)　:-)

　テストが邪魔されないか止まらないことの驚異がない領域で問題ないことを知った。または、何かに明確な疑惑がないことを知った。

(3-4-2)　:-|

　テストが止まるような重要な問題はまだ見つからない。

(3-4-3)　:-(

　テストが邪魔されるかテストが止まるようなことがあることを知った。

(3-5)時間

(3-6)コメント

問題ID番号
開始が遅れたか抑止した理由
ブロックされた問題の性質
何故、領域がスカスカなのか。

(3-7)ダッシュボードを利用しよう

更新：1週間あたり2～5回
進捗
言い訳
高度技術の進み具合

「Rapid testingは、自己管理である。実践的であることが要求されるが、誰も許可していない。」(スライド143～147ページ)

(1)Rapid Testingのテーマ

テストの中心にテスターのマインドを向けること。
不可解さや複雑さに取り組むことを学ぶこと。
説得力のあるテストストーリーを教えることを学ぶこと。
単に話すことでなく、実践を通じテストスキルを開発すること。
プロセスへガイドしたり組み立てたりすることに経験則を利用すること。
邪魔せずにプロジェクトのコミュニケーションに役に立てること。
全テスト活動でコストvs価値を考慮すること。
チームや戦術を多様化すること。
仕様を単に読むだけでなく、ユーザを理解すること。
テストに焦点を当てた管理を動的にすること。
コンテキストは、選択することを推進すべき、時間と共に進化することも。

(2)始めるには...

(2-1)リソースを優位に取れ

(2-2)探索に焦点をあてよう

　テスター達で3時間バグ狩りしよう！

(2-3)パズルを解決するように実践しよう！

　ジグソーパズル、ロジックパズル、数独などの考えるパズルで解決しよう！

(2-4)ガイドワードの経験則を使ってみよう！

　Heuristic Test Strategy Modelを使おう！

(2-5)手順を解答してみよう！

　いくつかの手順をシンプルに取りあげる

(2-6)ランチタイムにテストコーチ会議を始めよう！

　リスクのブレーンストーミングをやる。

(2-7)システム思考を実践しよう！

　"The Art of Systems Thinking"や"An indroduction to General Systems Thinking"を読め

(2-8)テストドキュメントからカバレッジやリスクの概略を取り込もう！

(2-9)テストの価値vsテストのコストを問おう！

所感

　全体を通じ、印象に残ったことをキーワードとして表現すると、「テストや製品の価値」「観察と学習」「質問」「垂直(論理)思考と水平思考」「フィードバック」の5要素に集約され、テストを通じて組織が賢くなるきっかけになると思います。また、テストコミュニティの知人である、@snskさんが以前、「テストは知る技術である。」と仰っていたことを思い出し、テストの本質を突いていると感じました。
　明日、2015/02/20(金)に開催されるJaSST'15東京でMichael Bolton氏が基調講演されますが、聴講後に感じたことを後日blogにまとめたいと思います。