どんなタイプでどのレベルまで行ったらボス戦に挑む？〜テストタイプとテストレベル

良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡

何かお久しぶりな感じだねー？
「スキ」の件数もアクセスも伸びないから拗ねてたわけじゃないよ🤡
単にギターの練習に時間使って書く時間が減ったんだ。ワークライフバランスっぽく言うとギターブログバランスを考えて更新は週に2〜3回ペースにすることにしたよー

じゃ、そろそろ本題のテストタイプは全てのテストレベルに当てはめることができると言うお話をしていくよ。

テストレベル？

テストレベルって何か覚えてるかな？
まずはテストレベルのおさらいをしておこうね？

・コンポーネントテスト
機能とか構成要素の一部と言った部品レベルに焦点を当てたテストレベル。

・統合テスト
コンポーネント間、またはシステム間の相互処理やインターフェースに焦点を当てたテストレベル。

・システムテスト
システムが実行する機能間のタスク処理、タスク処理を行う際の非機能的振る舞いといった製品、システム全体の振る舞いや能力に焦点を当てたテスト。

・受け入れテスト
エンドユーザーが使用可能で製品の販売、システムの導入の準備ができているかどうかを確認するためのテスト。

テストレベルごとの機能テスト

JSTQB FLシラバス（2.3.5 テストタイプとテストレベル）では銀行システムを例にしてるけど、今回は良い子のみんなにも馴染みのあるECサイトを例にして解説するよ。

・コンポーネントテスト
商品検索機能が正しく動作するか、商品詳細ページが正しく表示されるかどうか、カートに入れた商品が正しく表示されるか、決済が正しく行われるかなどの機能ごとに区切ってテストを実施するよ。

・コンポーネント統合テスト
商品検索機能とカート機能、決済機能が正しく連携されているかどうかをテストするよ。
機能間でのインターフェースの連携、データの整合性が保たれているかを検証するんだ。

・システムテスト
ユーザー登録や注文処理、在庫管理などのECサイト全体の機能に対してテストするよ。
例えば、ユーザーが正常に登録・ログインできるか、商品の注文が適切に処理されるか、在庫数が正しく管理されるかなどを検証するんだ。

・システム統合テスト
ECサイトが外部システムと正しく連携されているかどうかをテストするよ。
例えば、在庫管理システムや物流システムと連携されているかどうかを検証するんだ。

・受け入れテスト
実際のユーザーの視点からECサイトの操作や利用シナリオを検証していくよ。
例えば、商品の検索や注文、支払い手続きなどがスムーズに行われ、ユーザーが期待する通りの動作になっていることを確認するんだ。

テストレベルごとの非機能テスト

・コンポーネントテスト
商品検索機能や注文・決済機能とかの処理速度を評価するために、パフォーマンステストを実施するよ。

・コンポーネント統合テスト
ユーザーインターフェースからビジネスロジックにデータを渡す処理とかでセキュリティ上の脆弱性が存在しないことを確認するために、セキュリティテストを実施するよ。

・システムテスト
サポート対象のすべてのOS、ブラウザーやモバイルデバイスでECサイトが正しく表示され、操作できることを確認するために、互換性テストや移植性テストを実施するよ。

・システム統合テスト
クレジット利用状況を取り出すマイクロサービスが応答しない場合のリカバリや不正なデータ処理がないか、ECサイトの堅牢性を評価するために、信頼性テストを実施するよ。

・受け入れテスト
身体的な制限を持つ人が見やすさや音声読み上げとかを使ったECサイトを簡単に使用できることを確認するために、アクセシビリティテストを実施するよ。

非機能テストは種類が多いからテストレベルごとに違う分類の非機能テストを行うのが特徴的的だね。

テストレベルごとのホワイトボックステスト

・コンポーネントテスト
商品検索、カート追加、決済処理など、ECサイトの機能を実行するすべてのコンポーネントに対して、ステートメント（コード実行の行数）とデシジョン（条件分岐）をカバーするテストケースを設計し、コンポーネントの正確性と機能の網羅性を確認するよ。

・コンポーネント統合テスト
ECサイトのブラウザーインターフェースの各画面からデータを他の画面やビジネスロジックに渡す方法をそれぞれ実行するようテストを設計するよ。
また、バッファオーバーフローやセキュリティの脆弱性なども検証していくんだ。

・システムテスト
このテストでは、ECサイトのクレジット限度額申請におけるWebページの遷移順序をテストするよ。
テストケースは遷移順序や入力値のバリエーションに基づいて設計していくんだ。

・システム統合テスト
ECサイトが外部のマイクロサービスと正しく連携することを確認するよ。
マイクロサービスへ送信可能なすべての検索条件をテストケースとして設計し、データの受け渡しや統合の正確性を検証していくんだ。

・受け入れテスト
ECサイトが決済の資金移動における全てのサポート対象金融データファイル形式と値の範囲を正しくカバーしていることを確認するよ。
ユーザーの視点でテストケースを設計し、データの正確性や適合性を検証するんだ。

テストレベルごとの変更に関連したテスト

・コンポーネントテスト
自動化したリグレッションテストを各コンポーネント用にビルドし、継続的インテグレーションフレームワークに含めるよ。
例えば、商品検索のコンポーネントでバグ修正を行った場合、商品検索のコンポーネントに関連するテストをすべて自動的に実行できるようにするんだ。

・コンポーネント統合テスト
修正をコードリポジトリにチェックインする際に、インターフェース関連の欠陥に対する修正を確認するテストを設計するよ。
例えば、カート追加のコンポーネントでバグ修正を行った場合、カート追加のコンポーネントに関連するテストをすべて実行し、カート追加のインターフェースが正しく動作することを確認していくんだ。

・システムテスト
ワークフロー上のいずれかの画面を変更している場合、そのワークフローのすべてのテストを再実行するよ。
例えば、商品の注文画面を変更した場合、商品の注文から配送までの一連の流れをカバーするテストをすべて再実行していくんだ。

・システム統合テスト
マイクロサービスの継続的デプロイメントの一環として、マイクロサービスと相互作用しているアプリケーションのテストを毎日再実行するよ。
例えば、決済システムのマイクロサービスをデプロイした場合、決済システムと相互作用しているアプリケーションのテストをすべて再実行していくんだ。

・受け入れテスト
受け入れテストで検出した欠陥を修正した後に、ステータスが不合格となっているすべてのテストを再実行するんよ。
例えば、商品の注文画面でバグが発生した場合、バグを修正した後に、商品の注文画面のテストを再実行していくんだ。

全部やる訳じゃない

あくまで全てのテストタイプを全てのテストレベルに当てはめることができることの説明なので、これらの組み合わせを全部、実行する訳じゃないよ。

プロジェクトの予算や製品、システムの特徴、開発モデルや方針などなど現場の状況に応じて、どのテストレベルでどんなテストタイプを適用すればプロジェクトの目標やソフトウェアの品質を達成できるかを考えることが重要なことなんだ。

ここまで、テストレベルとテストタイプのお勉強をしてきたけど似たような言葉の上に「○○テスト」と言う呼び方なので、どっちがどっちか分からなくなりそうだよね？
JSTQBの試験とかでも、その辺の違いが分かってるかを試してくると思うので区別できるようにしておこうね。

次回はメンテナンス（運用）テストのお勉強をしようね。
「○○テスト」形式の呼び方なのにテストレベルにもテストタイプにも入れてもらえてない仲間外れで少しかわいそうなテストだね、、、

では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡