読書会続き。やはり仕事が無い。

第 6 章：継続的な探索

探索的テスト

Eplore It! では、探索的テストとは、「システムについて学ぶためのテストの設計と実行を同時に行い、最後の実験から得た洞察を次に伝える」と定義されているらしい。

人がシステムと対話して実際の振る舞いを観察し、小さな実験を計画
学習内容に基づいて、実験を調整し、システムにすいてさらに学習し続ける
ソフトウェアが何をすべきかについての誤解が明らかになる

また、

探索的テストの目標は、
- プロダクトのリスク軽減
- 信頼を獲得すること
予想される出力のスクリプトやリストは無く、
- 代わりに、リソース（またはバリエーション）とミッションによって目標が特定される
セッションの結果としては、
- 見つかったバグを示したり
- 必要かもしれない新しいフィーチャーやストーリーを提案できる可能性

とあります。組織によっては、明確なタスクリストや成果物が無いと嫌がる場合もあるかなと思いました。

探索的テストは、テストに対する規律あるアプローチ
モンキーテストとは混同しない
ランダムに彷徨うことと、思慮深く探索することの違いを考え、目的を持って探索する

モンキーテストとは違うと認識してはいたものの、テスト手法の一つぐらいにしか捉えていなかったので、「目的・役割」については考えていなかったなと気づきました。

ペルソナ・業務・そして役割

「ペルソナを仕事または役割と組み合わせることは探索的テストにさらに適しています」とあります。

ペルソナは設計やデザイン時に使うことはあったものの、探索的テストで使うことは考えたことはありませんでした。
テスト設計時に Who を想定することに近いのかもしれませんが、あくまであれが因子を出すためなので違いそうです。

ここでは、認知バイアスの克服に関して使われています。

ワークフローとツアー

ワークフロー
- アプリケーションで期待されるフロー
- またはユーザーの行程とも言える
- １つの行程から始めて、そのバリエーションを探索する
- フォームがあった場合に、そのフォームを埋める行程があるが、そこに入力する内容のバリエーションを探したり
ツアー
- アプリケーションを複数の機能を使う場合などで、その利用順序を変えたりしてみる
- 「探索的テストツアー」で検索するといいらしい

顧客にとってのリスクと価値

ビジネスリスクと顧客の価値を見落としていないか。正直、探索的テストのフェーズでそれが見つかるのは危険信号な気もするけれど、「すでに検討すみだろう」と思い込まず、ここでも「最悪の事態」と「最高のこと」を質問することは大事なのだと思う。

ペアまたはグループで探索する

ペアやモブでの探索的テストが有用だという話が出てくる。
確かに並行のテストなんかは一人では厳しいが、それだけではなく、複数の観点を用いるということが重要ということらしい。

ちなみに読書会を一緒にしている人によると、彼の会社では今でもモブプログラミングはよく行われているらしい。

チャーター

私がQAをしていた頃には「チャーター」という言葉は使っていなかったが、探索的テストセッションの指針になるもの。

ここでは、タイムボックスを区切るセッションベースドの手法も同時に集中のために有用と紹介されている。

また、チャーターを書く際に、「ペルソナ、仕事、役割」も組み合わせると書き始めるのに適しているらしい。
他にもマインドマップを利用したり、とチャーターの記述にもいろいろな方法が紹介されている。

実行、学習、方向修正

チャーターを書くのは難しいということ。実際、私も書こうと思うと最初は書きにくい。テストである以上、網羅性なんかも気にしてしまうし。

チャーターを実行することでさらに学習し、新しいチャーターを書くことができる。
また、ペアリングすることで、実行者以外がメモをとりながら情報をえることができる。

追加のテクニック

ここでもまた、認知バイアスに関するテクニックが紹介されています。

「斜めテスト」カード、TestSphereカードのどちらもソフトウェアテストのためのものでは無いですが、バイアスを排除し創造的に考えることを助けてくれるようです。

こういうツールを楽しんで使えるチームでありたいものです。

効果的な探索のためのツールを活用する

テストデータの生成やシーン設定などをある程度ツールに頼ったり、ログを工夫して誤りを検出しやすくするなどのテクニックもあるようです。

確かに、テスト中はログを tail しながら実行したり、最後に grep したりしますよね。

第 7 章：品質特性のテスト

品質特性はフィーチャーの「アドオン」ではなく、「考慮しなければならない制約」と考える。

品質特性の定義

ここでは、品質特性を「開発の特性」と「運用の特性」に分類しています。
個人的には、こういう分類は初めて見たのですが、良さそうな分類に思えます。

「開発の特性」はデリバリーチームが所有するそうです。
多くの場合、品質特性は「運用」の特性をみなされがちですが、上記の分類をしておくことで、デリバリーチームが各特性に適切な品質レベルを開発時に設定できます。

早期の協調によるリスクの軽減

「顧客にとって重要な品質特性を検討することにより、チームはプロダクトのリスクについて話すことができます」とあります。
Janet の事例では、信頼性を重要と捉え、それに関するテスト用の環境や自動テストを用意したそうです。完全に最初からストーリーに組み込まれています。後から確認するでは無いということです。

品質特性は、機能要件または動作要件よりも優先度が高い場合がある
これらの種類の問題は通常、設計上の問題であり、リリースサイクルの後半に修正することはできない

まさにそうですね。

よって、デリバリーチームとしては、プロダクトオーナーの会話を待たずに積極的に対応すべきとあります。プロダクトオーナーは、品質の特性を「当然」と考えている可能性があるためです。

検討する方法として、新しいフィーチャーのコンテクスト図を書いて、他の機能やシステムとの相互作用を確認することが提案されています。
ただ、いずれにしろ「早期」に知ることが大事ということでしょう。

プレリリーステストのプランニング

ステージング環境や、ブルーグリーンデプロイでのデプロイ直前の環境、またはリリースフィーチャートグルを用いた本番環境での品質特性のテストについて書かれています。

企業コンプライアンス

おそらく ISMS のような認証期間の定期的な監査等のためにに統制されたアプローチを取れということ。
クラウド環境だと audit の情報もだいぶ扱いやすくなっているが、それだけではなくテストについても質問されるケースもあるので、同様に準備し、それが余計な手間なく提出可能なものかも合意しておくと良さそう。

You are done!

「AGILE TESTING CONDENSED」読書会ログ 6, 7 章