JaSST Japan Symposium of Software Testing '06 in Tokyo に行ってきました。
昨今ソフトウェアに関するトラブルを新聞で目にしない日はないというくらい、ソフトウェアトラブルは日常化してきている。
ここはソフトウェアのテストをどのように実施すればいいか？ といった問いかけに対しての解を求めるために実施した試行や理論について発表し、議論し合う場である。
今回のゲスト講演は Rick Craig氏。いかにもアメリカのコンサルというカンジで、プレゼン力は高いし、愛想もいい。ときおりアメリカンジョークを織り交ぜる事も忘れずに、テストに置ける優先順位の決定法を彼自身の手法で説明してくれた。海軍出身とは思えん。
彼のリスクに基づいた試験内容決定ツールの内容はFMEAを簡単にしたようなものでした。一貫性をもって評価するように！という言葉がワタシにとっては重く心に響きました。評価レベルを５段階とか３段階に分けないことが重要であると。
開発レベルや、要求の質に応じて評価レベルは柔軟に変えるべきだと思っていたけど、これでは自分だけ納得できるもので、関係者には伝わりにくいものになってしまいますね。
開発レベルや、要求の質に応じて評価レベルは柔軟に変えるべきだと思っていたけど、これでは自分だけ納得できるもので、関係者には伝わりにくいものになってしまいますね。
でもオハナシいただいた内容は決して目新しいものではなく、今まで先人によって言われてきた事の一部でした。
その後いろいろな発表を聴かせていただいたが、直行表／直行表を応用した試験計画手法／実験計画法などが主で、目から鱗というテスト手法、テスト計画手法の発見はなかった。
我々の開発はこれらの直行表を実行すべき機能の集合体であるし、直行表を利用した試験はすでに実施してきている。
皆口をそろえて、試験計画は設計の時点、強いてはそれ以前に実施すべきものだとおっしゃっていた。確かにウォーターフォールの試験ではそのタイミングで計画すべきものであろうが、我々の開発はXP開発である。
XP開発では試験は毎回のイテレーションごとに、実施すべきものであると思う。
その都度ごとにユニットテスト（ホワイトボックステスト）と要求仕様に基づいたテスト（ブラックボックステスト）を手抜きしないで実施する事が、品質の向上への近道だと思う。もちろん要求仕様を詳細にネガティブテストのレベルまで明確化するというお膳立ても必要だ。
明日からは、これまで以上に仕様出しと試験確認に力を入れようと思う。
今後のアクションプラン まずは最低限ここから！
- Scan系の試験をマワス
- イテレーションごとの試験の明確化と詳細化、ユニットテスト内容の確認。
- 安全確認内容の意識の統一化
- 経験則に基づいた試験、設計の実施
