1.ブラックボックステスト

1.1 デシジョンテーブルテスト

デシジョンテーブルテストとは、複数の条件とそれに基づくアクションや結果を表にまとめてテストケースを生成する方法です。
この手法は特に、複雑な条件分岐やルールベースのシステムのテストに有効です。^※デシジョンテーブルを使用することで、様々な条件の組み合わせに対するテストケースを網羅的に考えることができ、テストの効率性やカバレッジを向上させることができます。

※デシジョンテーブル（決定表）とは、条件に基づいてアクションを決定するためのグラフィカルな表形式のモデルです。通常、条件、アクション、およびそれらの関係を表にまとめます。

1.2 状態遷移テスト

状態遷移テストとは、システムがある状態のときに特定の操作を行った場合に、システムが期待通りの状態に遷移するかどうかを確認します。また、各状態において適切な操作や入力を行った場合に、システムが期待通りの動作をするかも検証します。
状態遷移テストは、特にシステムが複雑な状態を持ち、それらの状態遷移がシステムの挙動に大きな影響を与える場合に有用です。ソフトウェアの開発やテストの段階で広く使用されています。

2.ホワイトボックステスト

2.1 ステートメントテストとステートメントカバレッジ

ステートメントテストとは、コード内の命令文を網羅するようにテストする方法です。
コード内の各行や文が期待どおりに機能するかどうかを確認します。
ステートメントカバレッジは、テストスイートがプログラムのすべての^※ステートメントを少なくとも一度は実行するかどうかを測定する指標です。これにより、コードの特定の部分がテストされているかどうかを確認することができます。

※ステートメントとは、コンピュータプログラムの構成単位となる、一つ一つの手続きや命令、宣言などのことを指します。日本語では「文」と訳されます。複数のステートメントを一つの文のように扱えるようまとめたものを「コードブロック」あるいは「複文」といいます。

2.2 ブランチテストとブランチカバレッジ

プログラム内の条件分岐（^※ブランチ）がすべて正しく機能するかどうかを検証する方法です。
ブランチカバレッジは、テストスイートがプログラム内のすべての条件分岐（ブランチ）をカバーした割合を示します。つまり、ブランチカバレッジは、テストがプログラム内のすべての条件分岐を通る度合いを測定します。

※ブランチとは、プログラム内の条件分岐や制御フローの分岐点を指します。具体的には、条件文（if文やswitch文）、ループ文（for文やwhile文）、またはその他の制御構造によって、プログラムの実行経路が複数の方向に分岐する点です。

3.経験ベースのテスト

3.1 エラー推測

エラー、バグ、故障の発生をテスト担当者の以下の知識に基づいて予測する技法です。

①経験と洞察に基づく推測
テスターが過去の経験や知識、そしてプログラムやシステムの理解に基づいて、どの部分に問題が発生しやすいかを推測します。特定の機能や処理が複雑である場合や、ユーザーが誤解しやすい部分などを特定するのに役立ちます。

②不正確な仕様やドキュメントの補完
仕様書や要件定義などのドキュメントに書かれていないエッジケースや特殊な状況に対しても、テスターが自らの経験や洞察に基づいてテストケースを推測します。これにより、不正確な仕様や不足しているドキュメントの欠点を補完することができます。

③アドホックなアプローチ
エラー推測は、ある程度のアドホックなアプローチを取ります。つまり、形式的な手法やツールに依存するのではなく、テスターの直感と経験に基づいてテストケースを設計します。

3.2 チェックリストベースドテスト

あらかじめ作成されたチェックリストを使用してテストケースを設計し、テストを実行する方法です。テストの網羅性や一貫性を確保するのに役立ちます。
また、テスト計画や実行の効率性を向上させることができます。しかし、この手法はあくまでガイドラインであり、他のテスト手法やアプローチと組み合わせて使用されることが一般的です。

4.コラボレーションベースのテストアプローチ

4.1 ユーザーストーリーの共同執筆

アジャイルソフトウェア開発プロセスにおいて、開発チームと利害関係者（ステークホルダー）が共同で^※ユーザーストーリーを作成するプロセスです。
開発チームはユーザーのニーズや要求を正確に把握し、ソフトウェアの開発をより効果的に行うことができます。

※ユーザーストーリーとは、アジャイルソフトウェア開発において、ソフトウェアの機能や要件を記述する手法の一つです。誰が、何を、なぜ行うかという視点を提供し、開発チームが開発作業を理解しやすくするのに役立ちます。顧客や利用者の視点から、システムが提供すべき価値や目標を簡潔に表現します。

4.2 ユーザーストーリーの受け入れ基準

ユーザーストーリーの受け入れ基準とは、ユーザーストーリーの実装をステークホルダーが受け入れるために満たさなければならない条件を指します。

受け入れ基準のポイントは5つあります。
①ユーザーストーリーのスコープの定義
②ステークホルダー間の合意形成
③ポジティブシナリオとネガティブシナリオの両方に対する説明
④ユーザーストーリーの受け入れテストのベースを提供
⑤正確な計画と見積りへの貢献

4.3 受け入れテスト駆動開発（ATDD）

受け入れテスト駆動開発（Acceptance Test Driven Development）とは、テストファーストのアプローチです。利害関係者と開発チームが協力して、要件やユーザーストーリーに基づく受け入れテストを作成し、そのテストを通過するようにシステムを開発するプロセスが採用されます。

5.まとめ

「テスト」と一言で言っても、プロジェクトの内容、コスト、工数によって用いる技法を使い分ける必要があります。最適なテスト技法を実施し、バグの早期発見をすることで、品質の良いシステムを提供することに繋がります。

 

お問い合わせ