JSTQBテスト技術者資格認定試験というものがあります。

• http://www.jstqb.jp/

無料模試があったのでやってみました。

• http://naha.cool.ne.jp/overdrive/JtcbExam/

難しい...

結果は以下の点数で合格でした。

問題数＝40 あなたの得点＝30点 正解率＝75％

問題はランダムにでるようです。運が悪いと合格しなかったかもしれません。結構、勘で答えた解答もありました。まあ、事前に試験勉強すれば受かる自信はありますが。

(無料模試ですが)合格したので好き放題に書かせてもらえば、この試験に受かっても何の価値もないだろうな、と思います。用語の意味を知っているか知識を問う設問だけだからです。たとえば、ぼくは「インスペクション」の設問は正解しましたが、「テストスイート」の設問は間違えました。しかし、インスペクションの意味を知っていたからと言ってテストの技能が高いとは思っていませんし、テストスイートの意味を知らなかったからと言って技能に劣るとも思いません。

昔 も似たことを書いていますが、テスト技術者は優秀であれば良いかと言うとそれだけで済まない部分に難しさがあります。

なんでもいいからバグをたくさん見つけろ、ということになれば、(確率的ですが)プログラマの方が(プログラミングのできない)テスト技術者よりたくさんバグを見つけられます(自分で書いたコードは除きます)。経験がある人ほど、境界条件や異常処理のあたりでバグを多く見つけるはずです。

しかし、製品をリリースした後の本当に恐いバグは、なんでもない普通の操作で起きてしまうバグです。基本的な機能が最初から動かないことはないので(作った人が基本動作をチェックするので)、普通は、かつて動いていた機能がコードの変更によって動かなくなります。直接、その機能に関係するコードを変更していれば開発者が気づきます。なので、見逃されるパターンは、たいてい意外な副作用の結果です。

ソフトウェア知識のある人がバグの発見数を増やそうとすれば、「普通の機能、以前動いていた機能、最近コードの修正がない機能」の3条件が揃った部分を重点的にテストしようとは思わないはずです。なぜなら、ここにはバグのある確率が低いことを知っているからです。しかし、ここに見つかるバグは致命的なのです。ここにソフトウェアテストのジレンマがあります。

テスト専門家はモンキーテストを無価値だとバカにしますが、現場ではモンキーテストでバカになれる人も重要です。