こんにちは！
今回はテストの種類とそれぞれの目的を説明します。4月からエンジニアとしての生活を始めた方、そろそろ研修が終わり実業務に関わり始めた方も多いのではないでしょうか。
よくわからない単語を耳にしながら仕事をしていくのはとても疲れるし嫌になってしまうかもしれませんが、今はわからなくて当たり前なので気楽に楽しんでいきましょう！
ということで今回は「テスト」に焦点を当てて説明していきます。今はテストに携わっていなくても、エンジニアとして働いていくとほとんどの方が経験することになります。
しっかり覚えておきましょう！
まずは開発工程をざっくり
開発工程は開発手法によって変わったりもしますが今回はウォーターフォールを元に説明します。
要件定義
要件定義では顧客やユーザーの要望やニーズを明確にしてそれをシステム要件として文書化します。
ここでは顧客へのヒアリングを繰り返し行い、ユーザーがシステムに求めるものを開発側がしっかりと理解して考えに違いがないようにします。
ここでのコミュニケーション不足はプロジェクトの失敗に直結します。少しでも不安なことがあれば納得できるまでコミュニケーションをとりましょう。
設計
決定した要件を元に各種設計書を作成します。
ここで作成した設計書を元に後々に実装をしていくのでとても大事な工程です。
またこの工程で作成する設計書はたくさんあります。それぞれの内容についてはここでは触れませんが次のようなものがあります。
- システム設計書
- アーキテクチャ設計書
- 詳細設計書
- データベース設計書
- インターフェース設計書
- UI設計書
- セキュリティ設計書
- テスト設計書
これらの設計書を設計工程で作成します。
実装
実際にコードを書く工程です。
「エンジニア」と聞いてイメージするのはこの工程だと思うます。(実際はコードを書いてる時間よりも他の工程に費やす時間が多いですが)
テスト
実際に作成したシステムのテストを行う工程です。
テストは複数の種類があり、それらを行う必要があります。
今回はこのテストの工程を詳しく説明します。
リリース
テストまで完了して品質が担保できたらシステムをリリースします
保守・運用
リリースして終わりではなく、障害が発生したときなどに対応する工程が保守・運用です。
テストの種類と目的
ここではテストの種類とそれぞれの目的を説明します。
ユニットテスト
ユニットテストの評価範囲は関数(メソッド)です。コードを書いていく中で記述した関数が仕様書通りの振る舞いをするかどうかをテストします。
このテストはテストコードを書いて自動実行することが多いです。ユニットテストは行わないこともありますが、行うことでバグの早期発見につながります。
コードを書いた人が同時にテストコードも書いて実行することが多いです。
モジュールテスト(MT)
MTは個々のモジュールが仕様通りに動くかのテストです。開発する時はモジュールごとに開発を行い、それぞれのモジュールを結合してシステムを完成させます。
一般的にモジュール毎に開発チームがあります。なのでMTはそのモジュールの開発チームが実施します。
結合テスト(IT, JT)
結合テストは各モジュールを結合して正常に動作することを確認するテストです。Integration TestなのでITと呼ばれることが多いですが、Joint TestからJTと呼ぶことがあります。
結合テストでの評価ポイントは、異なるモジュール間でのインターフェースや相互作用です。
システムでは複数のモジュールでできているので、モジュール同士でデータのやり取りなどが発生します。
MTではモジュール単体の動作を確認しましたが、モジュール同士のデータのやり取りが正常に行われるかまでは保証できていません。
そこを確認して保証するのが結合テストです。
システムテスト
これはシステム全体としての動作を確認するテストです。結合テストと似ていますが、評価の観点が異なります。
システムテストの評価観点は、出来上がったシステムがユーザー(お客様)の要件に合っているかです。
なのでここでのテストは要件定義で決定したユーザー要件と仕様に基づいて実施されます。
受け入れテスト
受け入れテストは評価の最終段階です。このテストはユーザーが要件に合っているかを確かめるために自ら行うことが多いです。
システム導入前の最後の段階で実施されます。
まとめ
今回はざっくりとした開発工程とその中のテストについて解説しました。
テストといっても種類がたくさんあることを知らなかった方もいると思います。今後エンジニアとして仕事をしていくと必ず出会うと思うので覚えておきましょう！
楽しいエンジニアライフを送りましょう！
コメント