2011年8月25日木曜日

探索的テストをいつやるべきか。

ども。コヤマンどぇす。

先日は水面下で打ち合わせをしている、あるイベントの打ち合わせだった。
(名前はまだ言えない)

ともあれ、その打ち合わせ後の飲み会中に
「探索的テストをいつやるべきか」
という話題になった。
それを通勤中の時間を使っていくつか考えている事を書いていく。

コヤマンの結論は「場合による」だ。
当たり前なんだけど、必殺技主義でないので、この回答にならざるを得ない。


―理由を述べる。

まず、探索的テストの前提として
ソフトウェアが「探索できる状態」である必要がある。
つまり、ある程度形になっていて、ある程度安定動作をしている必要がある。

なぜならば、例えば原因解明中のクラッシュ/ハングする問題があったとする。
どこで落ちるかわからない状態で探索を行って、途中でクラッシュ/ハングしたとする。
こうなると自分の操作が原因なのか、既知の問題なのかはパッと見ただけではわからない。

動作ログがあるなら切り分けは出来るが、動作ログを解析するツールなどが整備されている必要がある。
解析を開発担当者にやらせれば良いとお考えの方もいるかも知れないが、作る側からすると「どうせ既知の問題だろ」と考えるのでモチベーションも上がらないうえ、
徒労に終わってしまった場合には所謂時間の無駄遣いを強要することになるため、信頼関係の問題となる。
なので個人的にはオススメしない。


また、組織やチームの役割も関係する。

僕は統合テスト屋であり、主にシステム全体として見た場合の単機能の実現などがメインミッションとなるのだが
規模によっては製品単体の単機能であったり複数の組み合わせなとも
クライテリアとして存在する場合もある。

組み合わせの場合には単機能の品質次第であるが、早めに実施することをオススメする。
組み合わせの仕方による違いや、弱みみたいなものが早めに触ることにより浮き彫りになる。

逆に単機能の実現が目的なのであれば、ある程度機能が安定したあとに更なる品質向上を目的としてユーザの観点などを加えながら実施するのが良いだろう。


作りや重要度によっても影響を受けるのだが、これは多岐にわたるので割愛する。

重要度が高いものや、作りが特殊なものは早めに触る方が良い。
とはいえ、技術確立がなされていないなど、全く動作しないような状況ではあまり意味がない。


上記のようにさまざまな要因があると考える。よって「場合による」のだ。

と、考えたことをぼんやりと。

0 件のコメント:

コメントを投稿