Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

今度は世界遺産駆動か!?

ソフトウェアテスト設計コンテスト'13 関西地域予選会」を先ほど Ust 中継で視聴。
地元奈良のイベントに、鹿駆動勉強会に続き、今回も所用で参加できず。ざんねん。

# 前日ぎりぎりになって参加お願いしてたのに、スミマセン。。。


西先生の講演、初めのほうが聴けなかったが、
お話の中のキーワードを使って、大事と思ったところを簡単にまとめておく。


(あとで見たときに、わからなくなっていなければいいのだが)

 

(2013/4/7 追記)

ASTER のページ講演資料このときの動画が UP されています。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
技術は、以下を繰り返して 高度化 する。
  ___
  ↓     ↑
 癒着 ↑  …ひとりの頭の中で全てがグチャグチャな状態 = 属人的
  ↓     ↑
 剥離 ↑  …(頭の中から)ひっぺがして(要素として抽出して、分解して)、整理する
  ↓     ↑
 培養 ↑  …専門化してノウハウ化、教育して組織につくように、さらに進化
  ↓     ↑
 融合 ↑  …要素どうしが合わさって、さらに新しものに
  ↓____↑

技術を高度化するにはまず「分ける」ことから!


テストとは、

 行動 + (お客様への)説明 + (お客様の)納得  である。

 根拠 を示しており一目瞭然 であること。  (一目瞭然 = 一枚絵、選択肢 ≠ たくさんの表)

それは(お客様にとって)、

 直感的 であり、 不安の払拭 となるものでなければならない。


そのためには、

 「テスト・エンジニアリング・プロセス」

 すなわち テストのためのプロセス が必要である。
 (ソフトウェアにもプロセスがあるように、テストにも)

 テスト要求分析 とは、

  テスト内容やテスト対象    を理解する
  何をやればお客様が納得するか を理解する  の二本立て

  テスト対象の理解 とは、
   自分たちの想定 ではないよね
   機能一覧 だけじゃ足りないよね

 テスト設計の品質特性
  ・保守性
  ・優先度が判断できる etc.

⇒ 工程を「分ける」から、考えることが違ってくる。違うところを気にすればよい。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 

テストを可能な限りたくさんやる、でもなく、仕様書を漏れなく網羅する、だけでもなく、

お客様が納得するテストというのは、ほんとうに大変な話だ。

 

すべての不安要素をとりのぞくために、どんな根拠や説明が必要だろう?

そもそもすべての不安要素なんてキリがないのではないか?

「トレーサビリティが」「カバレッジが」だけでは「良いテスト」でないのなら、

それ以上何をやればいいのか? そして、どう説明できるのだ?

 

今回のお話は、それをテスト実施の観点ではなくて、

 

 まず「設計」でどうにかしろ

 

というお話だったと理解する。

それで、テスト仕様書に対する根拠や納得感が違ってくる、ということだろう。

 

いまの仕事で「テストの要求分析」や「テストの設計」って、どうできるだろう。。。

これは私のこれからの「大きな」宿題である。

 

 

コンテストも見てみたかったです。

#ご参加のみなさん、がんばってください!


それと、

Ust 録画や、(Ust では全く読めなかった)西先生のプレゼン資料が、ネットに上がることを期待しよう。


広告を非表示にする