私が現在働いている職場には「設計内検証」と呼ばれる仕事上の役割があります。 自分がそこに入ったときには既に存在したので細かい経緯とかはよく知らないのですが、 いわゆる品質保証のQAプロセスによるテスティングとは分けるためにそう呼ばれているのだと思います。 （実際後者のことを「検証さん」「検証チーム」などと呼ぶ場面が散見されます）

そこはそこでイロイロ思うところがあるでしょうが、とりあえずこの文脈では 「検証＝テスティング」と近似して考えてこの先の話を書きます。 あえて「設計内」なんてつけなくても、テスティングだって設計の一部なのは当たり前じゃん、 とかいうのもざっくり置いておいて:-p

QAのテストは開発の後期にならないと行われない（少なくとも建前上は品質保証のためだし）のに対し、 設計内検証はもっと開発チームの（物理的にも精神的にも）近くにいて、 開発したそばから、あるいは同時にテストを行っていきます。 単体テストやモジュールテストのようなホワイトボックステストではなく、 できあがったexeやexe群に対するテストです。

で、これまで何人かの設計内検証の方と一緒に仕事をさせてもらいましたが 今回ここに書くのはその中でも Nさんとその後任であった Mさんのことです。

このお二人は（たぶん本人達は意識していないでしょうが）「探索的テスト」がとてもうまかったです。 開発を進めながら一緒にやっていくテストとしては、様々なテスト技法の中でもとりわけ 探索的テストが重要だと私は考えています。 （「アート・オブ・アジャイルデベロップメント」でも探索的テストの必要性が繰り返されていますね）

私の理解では探索的テストは決して「いきあたりばったり」とは違っていて 「テスト設計をリアルタイムに行っている」状態だと感じています。 つまりかなりの資質が求められる筈ですが、これがうまかったということですね。 「Microsoft Technet : Windows アプリケーションの探索的テスト プロシージャ」 から引用すると以下の通りです。

運用上の用語では、探索的テストは平行して製品探索、テスト設計、およびテスト実行を行なう対話的プロセスになっています。探索的テストセッションの結果としては、製品に関するメモと見つけたエラー、およびテストケース概要 (TCO と呼ばれ、製品の主要機能のテスト方法を簡潔なステップで記述) が得られます。訓練を受けたテスト担当者がテストすると、一貫し、貴重で、しかも監査に耐える結果が得られます。

「対話的プロセス」とありますが、テスト対称のプログラムとの対話はもちろん、必要に応じて開発者とも（量やタイミングや方法において）ちょうど良いバランスのコミュニケーションが必要になります。Nさん、Mさんはその点においても要領を得ていました。ここもポイントでしょう。

例えばMさんがプロジェクトのWikiに付けていた「気になるメモ」はかなり精度の高い情報源で、これにより助けられた場面は幾度となくありました。 決してきちきちっとしたフォーマットではありませんが、開発者にわかりやすい書き方に長けていたのでしょう。これもまた資質ですね。

デベロッパーテスティングとしてのユニットテストは開発者側の責任ですが、それより上のレイヤのテストとして設計内検証の方に探索的テストを任せられる安心感はかなりチーム全体としても効いていたと思います。

ちょっと横道に逸れますが、おそらく私の職場の「設計内検証」と「開発者」が限りなく同一に重なっていったものが 咳さんのところのチームなのではないかと想像しています。 やはり偉大なリーダーとそのチームは何歩も前に進んでいるんだなぁ。

私には想像の及ばないイロイロの末、今はMさんと一緒に仕事をしていない状態なのですが、 それはチームにとっても大いに残念だし、個人的に聞きたいことも実はあった私としても残念です。

まぁ、それはともあれ。

私はテストエンジニアではないし、JSTQBあたりを取ったりもしてないのですが、 探索的テストをうまく回していく方法の一つとしてなかなか面白いと前から思っていたので、 今の職場の「設計内検証」について書いてみました。