Testingという用語をJSTQBの用語集から引用すると、
「全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。」
なので、活動全体を示すのですが、
よく、「CheckingとTesting」という対比した使われ方をするとき、Testingは創造的だったり学習の要素が入ったりという意味合いを持つなーという印象を持っています。
最近、JaSSTで情報を得たり話をしたりする中で、自分や自分の周りの活動はどうなんだろう？と考えてみるようになりました。
で、描いてみた→何人かに見せてフィードバックもらってみて今に至る。↓
まずはテスト対象に出会う前に備わっている知識や経験や能力があります。ここで持ち合わせているものが活動に影響するのですが、その話はまた別の機会に書きます。
テスト対象に出会うと様々な情報が入ります。その情報を分析して、不明な点や気になる点を調べたり質問したり仮説を立てて検証したりします。そうして新たな情報を得て更に分析します。そのサイクルをぐるぐる回して共通理解を得たら、そこからテストのスコープを決めたりスクリプトにするテストを決めたりします。ぐるぐる回している間はTestingですが、スクリプトになる時点では期待結果がわかっているのでCheckingになっていると思います。
スクリプトにしないけれど、気になるから「一度やっておく」テストもあります。こちらもすでに想定済みのものなのでCheckingかな？って思います。
上記の流れに対して、分析したのだけれど理解しきれていなかったり誤解していたりということが起こることがあります。たぶん誰にでも起こると思います。この「わかったつもりになる」状態がある、ということに気付きました。この状態に陥るとテスト実装や実行の時点でなにかトリガーがかかって後で気付くことになります。気づいた時点でTestingのループに戻るなぁ、と。
この図があると、なるべくこっちのルートを辿らないようにしたいよね、って話ができるなぁとも思いました。
更に、残念ながら情報を得たらそのまま考えずにテストを作ってしまうルートもあります。悪い意味のCPM(コピーペーストモディファイ)はこちらのルートで作成されるので、概してテスト実行時に気づけばラッキーという状態になります。これもなくしたいよねって話がしやすくなりました。
あと、この図で探索的テストってどこのことを言っているんだろうね？という話もできるなぁって思っています。
探索的テストって、Testingとイコールではないというのが今の私の考えです。本当はスクリプトにできるんだけど様々な理由でスクリプトになりきれない(あるいはする必要がない)ものがあって、それを補うための探索的テストってやるよね？
スクリプトの品質が悪いことを補う探索的テストもやるよね？
この図でTestingとしているループで実装物を触っている場合を探索的テストと呼ぶ人もいるよね？
今後、こういう話をいろんな人としていきたいなぁって思っています＾＾
・・・って、本当はとてかでここまで言いたかったんだよぉぉ(笑
