JSTQBシラバスが求めているテスト技術者（２）

JSTQBテスト技術者の試験も無事終了。シャーペンとか消しゴムとか解答用紙見直しとか久しぶりな1日でした。

==

試験前にまとめ記事は書いておきたかったが、続きを。

テストのマネジメント

テストを誰がやるか。実装をした開発担当者なのか、プロジェクト内のチームメンバーなのか、社内のテスト専門部隊なのか、社外の品質マネジメントを専門とする部隊なのか。基本的には後者に行くにしたがってプロジェクトとの関係が薄くなり、独立性が高くなる。開発担当者の思い込みやステークホルダーのプレッシャーなどの要因がなくなり、欠陥検出の観点でいえば精度があがるといわれる。ただし、独立性が高くなるほど当のメンバーの品質意識が薄れてしまい、欠陥作りこみの観点でいえば品質が低下する可能性も秘めている。誰がやるか、という問いであれば「テストツール」という選択肢もあり、その場合も同じようなことが言えそうだ。思い込みは全くないが、テストツールに依存しすぎると逆に品質低下の坂を転げ落ちる可能性もある。

プロジェクトに影響するリスク（＝プロジェクトリスト）と、プロダクトに影響するリスク（＝プロダクトリスト）という区分をした場合、前者はテストというプロセス自体に影響がでる。後者はテストというプロセスが影響を及ぼす。すなわち、テストというプロセスがプロダクトリスクの対策になりうる。

それにしても終了基準ってけっこうあいまいなところが多そうだな。

テスト支援ツール

最後の章はテストを支援するツール。静的解析ツールやキャプチャリプレイツール、不可試験ツールが有名。テスト実行ツールあたりは、ここらへんは日立）加藤さんの講演とかをきくとまとまっていて理解しやすいと思う。テストマネジメントの支援ツールなどは比較的どのプロジェクトでも効果が出そうな気がする。私見では。

==

テスト工程ってけっこう感覚的に行っているケースが多いが、体系的なテストプロセスを学習してみると、まさにプロジェクトの中のサブプロジェクトだね。僕らが期待するような解の公式はない。複数の視点・観点で分析しないとなかなかひとつ高いステージの品質にはあがらない。仕様ベースと構造ベース。「バグを作らない」と「バグを見つける」。個人単位の品質意識の向上と個人の能力に左右されないプロセス。

（続く）