仕事始め - テストツールのチューニング -
明けましておめでとうございます。扁桃炎も治ってきて、モチベーションもアゲていこう。新年早々、まとまりのない文章をつらつらと。
==
テストとは品質向上を主目的としたライフサイクルプロセス。なので、回帰テストケースやテストツールは適宜その有効性をメンテナンスしなくてはならない。でなければ、人は一度構築されたテストケースやテストツールを信頼しきってしまい、細かな修正の積み重ねや見落とし、油断などによってバグを検出できなくなる。それもいたって初歩的・単純なものだったりもする。
そこで、どうやってそういった問題を回避していけばいいんだろう。
当然&基本的なことだけれども、なかなか癖がつかない。これが成功するかどうかは、会社の文化・チームの文化にも影響される。仕様書やヘルプがそのまま放置されがちな組織ではまずここから。
一人が油断しても他の人が見逃さない、の手法。でも、誰かが承認したんだから承認していいだろう、といった同調・迎合の空気に飲み込まれる可能性が高いか。
今まで電子データでのやりとりだったものを、紙ベースに変えたり。レビューの場所を変えたり。時間帯を変えてみたり。チェックシートを無駄に作り変えてみたり。効果あるかな。。。
テストケース中に「このテストケースだけで十分か?」といった自問を入れる。うまくいきそうだけれども、どうやって十分かどうかをテストするのか、が難しい。
他にどんな手法があるだろうか。
| 固定リンク
この記事へのコメントは終了しました。

コメント
あけましておめでとうございます。
「手順の中に手順の見直し作業を入れておく」ことって重要ですね。これって考慮されていないタスクですね。
投稿: ただいま修行中 | 2007年1月 5日 (金) 21:23
あけましておめでとうございます。
今年も勉強させてくださいませ。
全然アイデアという話しではないのですが、XPではテストとコードだけを恒久的な成果物として保存しようとしますよね。これって、身軽な旅というだけでなく、本気でテストをメンテナンスする気にさせる効果もあるんだなーと思いました。
ヘタに(?)完全な仕様ドキュメントがあると、テストがこれに同期していなくても「まぁいいか」的な気持ちになりますけど、テストが唯一の恒久的な仕様書だと思うと、テストをメンテしないとハマルので、必然的にやりますよね。(自分はそこまでXPをやれてないので経験談ではありませんが...)
ドキュメントドリブンな開発では、なかなかそういう動機づけが行われないですよね。うーむ。
投稿: geo | 2007年1月 6日 (土) 00:17
>ただいま修行中さん
今年もブログ拝見させていただきますー。どうぞよろしくお願いいたします。
「手順見直し」という手順はいかにうまく導入できるかがポイントかなって思ってます。
>geoさん
こちらこそいろいろな切り口で勉強させてくださいませー
テストドリブンもそれ以外の手法も自分でやってみて、どこがよくてどこが悪いかを
きちんと経験するとさらに理解が深まるのかなって思ってます。僕もXPをきちんと経験していないので
なかなか勉強が進まないんですがね・・・
コードメンテナンスはほぼ誰もがやることですが、テストメンテナンスってテストドリブンによって
地位が高まるって気がしてます。
(まあいいか → メンテナンスしないと気持ちが悪い への変化?)
投稿: softest | 2007年1月 6日 (土) 16:18