目次
テストの実行手順
1. テスト環境を整備
まずテストを実行する前に、必要なテスト環境を整備する必要があります。テスト環境は開発環境や本番環境と同等であるべきであり、テストに影響を及ぼす要因（ネットワーク、データベース、ハードウェアなど）が整っていることを確認してください。
例：テスト環境を整備・テスト用サーバー、データベース、ネットワークなどの準備・インターネットがつながる状態を確認・admin userでログインした状態を準備
2. テストデータを準備
テストデータを準備してください。テストを実施するためには、テスト計画で定めた適切なテストデータを用意する必要があります。正常なデータや異常なデータ、境界値データなど、さまざまなデータパターンを踏まえた上でテストをします。
例：テストデータを準備・テスト計画で定めたテストデータを整理し、作業前に分からない部分がないか確認。
3. テストの事前条件を確認
テストを実行する前に、テストの事前条件を確認してください。特定の状態や設定が必要な場合は、それが整っていることを確認してから、テストを実施します。事前条件が満たされていない場合、行ったテスト結果が正確でなくなる可能性があるからです。
例：テストの事前条件を確認・定めたアカウントで正常にログインしているか確認・テキスト入力されている状態か確認・通知がONの状態か確認
4. テスト結果を記録
テスト結果を正確に記録し、優先度を設定します。テストを実行した際には、テスト結果を正確に記録することが非常に重要です。テストケースごとに実行結果や発見した不具合を明確に記録し、必要な情報を残します。これにより、テスト結果の分析や不具合の追跡がスムーズに行うことができ、期限の遅れを防ぎます。
また、結果がエラーだった場合、適切な形式で記録し、優先度を設定します。不具合の重要度や影響度に基づいて優先度を設定することにより、不具合対応者との相違が少なくなります。
例：テスト結果を記録・ログインボタンをクリックした際に、エラーメッセージ「ユーザー名が無効です」が表示・必須フィールド「氏名」が空欄のまま登録をクリック、エラーメッセージが表示されない・大量のデータを使用した検索テストの実行中に、検索結果の表示に異常な遅延が発生
※テストの自動化の検討
テストの効率化と網羅性を高めるために、可能な限りテストの自動化を検討します。自動化により、繰り返し実行が必要なテストや大量のデータを扱うテストを効率的に実施することができます。
テストを実行し、結果を正確に記録することができたら、開発者に伝え修正してもらいます。
修正後のテストケースも同じくテストし、改善されているか確認します。
以後、この作業の繰り返しです。
リリースへ！
まとめ
テストを理解し、さまざまな工程を経てリリースとなります。リリース前の不具合の処理と、リリース後の不具合の処理では、かかるコストが大幅に違います。しかし、ミスはつきものです。できる限りテストの段階でコストを減らせるように努めましょう。
テストに関する用語
単体テスト
単体テスト（ユニットテスト）は、プログラムを構成する比較的小さな単位（ユニット）が個々の機能を正しく果たしているかどうかを検証するテストです。
通常、関数やメソッドが単体テストの単位（ユニット）となります。
↓↓以降のテストはQAエンジニア、もしくはQAテスターが担当↓↓
結合テスト
結合テストとは、単体テストを終えた各モジュールを組み合わせて、意図した通りの動作や挙動になっているかを確認するテストです。
一般的なウォーターフォールモデルの開発においては、プロジェクトの中盤から終盤にかけてさまざまな組み合わせの結合テストが複数回に渡って実施されます。
受け入れテスト
受け入れテストとは、外注したシステムの納品時に、実際に利用する環境またはそれに近い環境でシステムを使用し、問題がないかを確認するテストのことです。
基本的にシステムを発注した側がこのテストを行うことになっていますが、受け入れテストを外部に委託するという選択肢もあります。
運用テスト
開発が完了したシステムを、運用部門が業務の流れに沿って検証し、実際の稼働状況において不具合が発生しないかどうかを検証するために実施されるテスト。
運用テストは原則的に運用部門の主導で実施され、システム部門はそれを補助する役割を担う。
テスト計画
「テストの計画を立てること」
・テストで何をしたいのか考える。 （バグを無くしたい！）
・何処をテストするのか決める。 （特にここはバグがあると困るから重点的にテストする！）
・テストの期間を決める （7/1から7/31まで1か月間）
・テストに掛かる工数を決める。 （5人で800時間）
テスト設計
「テストする内容を設計すること」
・どうやってテストする？ （テストの手順は？使用するデータは？）
・どのようなパターンでテストする？ （どのようなパラメータの組み合わせパターンにする？）
・結果はどうなる？ （機能仕様書から読み取れる？テスト側で確認する手段ある？）
直交表
直交表は一部実施にもかかわらず、高次交互作用の評価を断念することで少ない実験で要因効果を知るためのツールです。 工業実験の成果を上げるためにはより多くの因子を扱う事が有効ですが、原理的には掛け算で実験数が増えてしまいます。そこですべての組み合わせを評価せず、一部の組み合わせを実験して統計的に要因効果を評価するために直交表が使われます。戦後日本の製造業発展は直交表の効果と言う人もいるほど効果的な手法で、二水準系、三水準系など多くの種類があります。
直交表は「不具合が起こる要因のほとんどは2つまでの要因の組み合わせによるものだ」という考えに基づいています。３つ以上の偶然が重なって起こる事件というのは、世の中には滅多にないのです。
テストケース
（正常テスト・異常テスト）
テストケースとは、ソフトウェアテストを実施する際に用意する、実行条件や入力データ、期待される出力や結果などの組み合わせです。
ソフトウェアやシステムが期待通り動作するかを確認するために用意するもので、一つのプログラムをテストするために複数のテストケースを作成することが多く、複雑・大規模なソフトウェアでは膨大な数のテストケースを作成することもあります。
テストケースは基本的に「このような条件・状況でこのような入力を与えると、このような結果になる」という形で表現されています。
人が読んで分かるような文書として作成し、人がそれを読んで一件ずつテストする場合と、一定のデータ形式で記述あるいは自動生成し、テストツールを用いて自動的に検証する場合がある。
