テストオラクルという切り口で今は勉強中。エイゴニガテ。
==
明日3/2にJSTQBテスト技術者資格認定の試験があります。僕も問題集や教科書やこことかで勉強してみました。
一通りこなしてみて、復習・おさらい・新たな気づきのために自分なりにまとめてみようかと。
テストの基礎
テストがなぜ必要・重要なのか。上手なテストはどういうリスクを回避するのか。静的テストというテスト。テストプロセスってどんな風に行うの？
実はシステム開発の半分以上のコストがテスト工程に費やされている、というデータもあるとおり、コスト面で効率化が必要。また昨今のシステムトラブルなどをみても品質面でも効果性を求められる。じゃあ、そのテストについてもっと研究してみようよ、という章かな。
テスト＝バグ(欠陥)を見つけること、という視点、レビューなどの静的テストという視点、システム開発のサブプロジェクトとしてテストを考える、心理的な観点からだれがテスト（設計）すべきかな、どなど。
ソフトウェアライフサイクルを通じてのテスト
システム開発の手法によってテストの関わり方がかわってくる。ウォーターフォール型開発の中のテスト、反復型・アジャイル型開発の中のテスト。それ以外にも、構成単位の粒の大きさでテストをカテゴライズすることもある。コンポーネントテスト(あるいは、ユニットテスト、単体テストとも)、統合テスト(あるいは、結合テストとも)、システムテスト、受け入れテスト。テスト工程といったらこの呼び名が一番馴染み深いかも。これはテストのレベルというカテゴライズで、V字開発モデルではそれぞれが詳細設計、システム設計、要件定義などと対として扱われる。
その他にもテストのタイプというカテゴライズもある。これは機能テスト、非機能テスト、構造テスト、確認テスト、保守テストといった種類(タイプ)がある。それぞれにテスト評価基準があり、要件のカバレッジであったり、条件のカバレッジであったり。非機能テストにおいては品質特性（JIS X0129）と呼ばれるカテゴリを参考にする方法もある。システム開発をはじめたころは機能テストばっかりをやっていた気がするなあ。
こういった複数の視点でテストを分析していくことでより多くのバグを検出できるテスト設計が可能になる。仕様書ベースだけでテストケースを作成していても、見つからないバグもある。ステートメントカバレッジに注目しているだけでは見つからないバグもある。とか。
静的技法
ソースレビューとかテスト設計レビューとかペアプロとか。プロジェクトの早い段階でバグを作りこまない対策として最も一般的に知られているが、人によってはまちまちなのも事実か。開発担当者自身に気づかせるためのウォークスルー、技術的な指摘をメインにしたテクニカルレビュー、静的解析ツールを利用することで品質を均一にしするという試みもある。ここでの取り組みがあとあとの手戻りコストを小さくしてくれる。ただし、一長一短である。実際に動かしてみないとわからないバグも必ずある。
テスト設計技法
静的テストは「バグを作りこまない」「バグの件数を小さくする」という視点。テスト設計をするときは「より多くのバグを見つける」「より少ない手数でバグを見つける」という視点。前者は手戻りコストを抑え、後者はテスト実行のコストを下げる。
仕様ベースとかブラックボックスと呼ばれる技法は、入力（事前条件）と出力（期待される結果）に注目してテストケースを設計する技法。期待される結果を比較（テストオラクル）。要件・機能カバレッジをチェックすることが一般的。
構造ベースとかホワイトボックスと呼ばれる技法は、経路に注目するテスト技法。ステートメントカバレッジ・ブランチカバレッジ・コンディションカバレッジをチェックする。
どちらも長所短所をもっていて、例えばコンポーネントテストでは構造ベースが、より上位の結合テストでは仕様ベースで設計することがよさそう。ただし、設計においても複数視点での設計が必要になる場合が多く、システムテスト以降であれば仕様・構造両方で分析・設計するのが望ましいだろうな。
（続く）
ソフトウェアテストの用語がコンパクトにまとまっているよい本だと思います。
受験者にも、そうでない人にもオススメ
最近のコメント