(名前はまだ言えない)
「探索的テストをいつやるべきか」
という話題になった。
それを通勤中の時間を使っていくつか考えている事を書いていく。
当たり前なんだけど、必殺技主義でないので、この回答にならざるを得ない。
ソフトウェアが「探索できる状態」である必要がある。
つまり、ある程度形になっていて、ある程度安定動作をしている必要がある。
どこで落ちるかわからない状態で探索を行って、途中でクラッシュ/ハングしたとする。
こうなると自分の操作が原因なのか、既知の問題なのかはパッと見ただけではわからない。
解析を開発担当者にやらせれば良いとお考えの方もいるかも知れないが、作る側からすると「どうせ既知の問題だろ」と考えるのでモチベーションも上がらないうえ、
徒労に終わってしまった場合には所謂時間の無駄遣いを強要することになるため、信頼関係の問題となる。
なので個人的にはオススメしない。
規模によっては製品単体の単機能であったり複数の組み合わせなとも
クライテリアとして存在する場合もある。
組み合わせの仕方による違いや、弱みみたいなものが早めに触ることにより浮き彫りになる。
とはいえ、技術確立がなされていないなど、全く動作しないような状況ではあまり意味がない。
0 件のコメント:
コメントを投稿