「ソフトウェアテスト設計コンテスト'13 関西地域予選会」を先ほど Ust 中継で視聴。
地元奈良のイベントに、鹿駆動勉強会に続き、今回も所用で参加できず。ざんねん。
# 前日ぎりぎりになって参加お願いしてたのに、スミマセン。。。
西先生の講演、初めのほうが聴けなかったが、
お話の中のキーワードを使って、大事と思ったところを簡単にまとめておく。
(あとで見たときに、わからなくなっていなければいいのだが)
(2013/4/7 追記)
ASTER のページに講演資料とこのときの動画が UP されています。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
技術は、以下を繰り返して 高度化 する。
___
↓ ↑
癒着 ↑ …ひとりの頭の中で全てがグチャグチャな状態 = 属人的
↓ ↑
剥離 ↑ …(頭の中から)ひっぺがして(要素として抽出して、分解して)、整理する
↓ ↑
培養 ↑ …専門化してノウハウ化、教育して組織につくように、さらに進化
↓ ↑
融合 ↑ …要素どうしが合わさって、さらに新しものに
↓____↑
技術を高度化するにはまず「分ける」ことから!
テストとは、
行動 + (お客様への)説明 + (お客様の)納得 である。
根拠 を示しており、一目瞭然 であること。 (一目瞭然 = 一枚絵、選択肢 ≠ たくさんの表)
それは(お客様にとって)、
直感的 であり、 不安の払拭 となるものでなければならない。
そのためには、
「テスト・エンジニアリング・プロセス」
すなわち テストのためのプロセス が必要である。
(ソフトウェアにもプロセスがあるように、テストにも)
テスト要求分析 とは、
テスト内容やテスト対象 を理解する
何をやればお客様が納得するか を理解する の二本立て
テスト対象の理解 とは、
自分たちの想定 ではないよね
機能一覧 だけじゃ足りないよね
テスト設計の品質特性
・保守性
・優先度が判断できる etc.
⇒ 工程を「分ける」から、考えることが違ってくる。違うところを気にすればよい。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
テストを可能な限りたくさんやる、でもなく、仕様書を漏れなく網羅する、だけでもなく、
お客様が納得するテストというのは、ほんとうに大変な話だ。
すべての不安要素をとりのぞくために、どんな根拠や説明が必要だろう?
そもそもすべての不安要素なんてキリがないのではないか?
「トレーサビリティが」「カバレッジが」だけでは「良いテスト」でないのなら、
それ以上何をやればいいのか? そして、どう説明できるのだ?
今回のお話は、それをテスト実施の観点ではなくて、
まず「設計」でどうにかしろ
というお話だったと理解する。
それで、テスト仕様書に対する根拠や納得感が違ってくる、ということだろう。
いまの仕事で「テストの要求分析」や「テストの設計」って、どうできるだろう。。。
これは私のこれからの「大きな」宿題である。
コンテストも見てみたかったです。
#ご参加のみなさん、がんばってください!
それと、
Ust 録画や、(Ust では全く読めなかった)西先生のプレゼン資料が、ネットに上がることを期待しよう。