昔の経験を探索的テストで思い出した。
20年前に遡る。結構規模のでかいプロジェクトのテストチームに配属されていた。
新人のときにいたテストチームで、とある機能の結合テストを手伝っていたとき。
いつも、バグ多めのプログラムを描く方がいた。
その方の機能テストをした時、担当したテストケースの一部では、たまたまなのかほとんど出なかった。なんで出ないのかな？と思って聞いてみたら、通信する相手先が、かなり優秀な…最高のプログラムを描く人の機能だった。
想定して、色々なエラー処理を入れていたらしい。
苦手とする機能の実装を予想して、どんなデータが来ても対応できるようなコードを書いていたそうな。
すげえと思った。
でも、バグ多めの人の機能で出ないのはおかしい…前はこんな感じの操作をしたときに出たよな…と、規格書に、書かれていないことをやったら、ビンゴ。
すぐに機能担当者に報告した。
その周りの実装を再チェックしてもらった。
自分がテストの担当をする機能のコードを描いた人たちの癖は、なんとなく掴んでいた。どういうエラーを毎回出すか、どういう処理に弱いのか。
担当者ごとの弱点マップみたいなものを書いて、テスト依頼される前に配ったりしていた。
当時のプロジェクトでは、テストチームが関わるのはシステムテストから。たまに工程が押してきたときは、ヘルプで結合テストから入ったりもした。
なので、弱点マップを渡すタイミングには悩んだりした。自分たちが関わるときに渡すとすごく嫌な顔をされるけど、単体テストをやっているときに渡すとニコニコしてくれる。これってなんだろう？っと。
20年経って思い返すと。
この弱点マップって、テスト観点だったり、探索的テストのチャータなのかもしれないな、と。
新人の私は、境界値分析とか同値分割とか、テスト技法と言われるものは何も知らないおバカさんだった。
V字とか、フロントローディングとか多分なかった時代かなあ。
という意味を考えると、アドホックな探索的テストをやっていたのかなーと思う。
根拠はないけど（=アドホック）、この人はここでよくバグを出す（=チャータもどき？）から、叩いてみよう（=探索的？）、というもの。
こういうテストをする人、多分いるんじゃないかなーとも思う。
技法を知らなくても感覚で捉えた内容は、結構間違っていない。
その感ってやつの根拠・仮説を証明して、きちんと分類できるようになるためにテスト技法をそこから勉強した気がする。
こんなきっかけも、あるかな、と思った振り返りでした。
とりとめもない内容を読んでくださってありがとうでした！
