好きなタイプはツンデレかな？〜テストタイプ Part1
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
良い子のみんなはどんなタイプが好きかな？
僕はツンデレな性格で体は柔らかくてモフモフしてて狭い所とか高い所に行きがち、そして夜には目が光ったりする、そんな子がタイプなんだ。
久しぶりにタイプの子がいっぱいいるお店とか行きたくなってきたよ。つまり、猫カフェだね！
僕の好みはどうでもいいとして、前回はアシスタントの知識とJSTQBでの分類が一致してなかったので改めてテストタイプについてお勉強していこうね。
テストタイプとは？
テストタイプは、以下に列挙する特定のテストの目的から見たソフトウェアシステム(あるいはシステムの一部分)の特性をテストするための活動を束ねたものである。
JSTQB FLシラバスでは目的とソフトウェア特性から4つのタイプに分類されてるよ。
• 機能の品質特性、例えば完全、正確および適切であることなどを評価する。
機能を対象としている機能テスト
• 非機能の品質特性、例えば信頼性、性能効率性、セキュリティ、互換性、使用性などを評価す る。
非機能を対象としている非機能テスト
前回、GPTさんとBardさんが説明してくれたセキュリティテストやユーザビリティテストはこの分類に含まれてるね。
コンポーネントまたはシステムの、構造またはアーキテクチャーが正しく完全で仕様通りである ことを評価する。
ソフトウェアの中身である構造、ロジック、制御の流れを対象としているホワイトボックステスト
欠陥が修正されていることを確認するなどの変更による影響を評価し(確認テスト)、ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを探す(リグレッショ ンテスト)。
欠陥の修正やテストの対象に何らかの変更があった場合に変更した内容のせいで欠陥が出ないかを確認する為の変更関連のテスト
今回はこの目的と特性で分類されたテストタイプ4種の中から機能テストを紹介するね。
機能テスト
機能って何？
機能とはソフトウェアが「何を」すべきかを示しているとされてるよ。
テストする対象によって機能の分け方とかも変わってくるので設計資料や仕様書を見たり、有識者に確認しようね。
あんまり無いけど機能一覧と言うわかりやすいものが用意されてることもあるから、そんなプロジェクトに当たるとラッキーだと思っておこうね。
機能テストの確認ポイント
機能テストでは、ソフトウェアが実行する機能がどう振る舞うかを確認して行くテストタイプだよ。
元になる情報である機能要件は、ビジネス要件仕様、ユースケース、機能仕様などの作業成果物で記述してることも多いけど、まったく文書化していない場合もあるから要件定義担当、設計担当にしっかり確認しておこうね。
機能テストを作る時はソフトウェアがどう振る舞うのかに焦点を当てて、コンポーネントやシステムの機能のためのテスト条件やテストケースをブラックボックス技法で導き出すことができるんだ。
ブラックボックステスト技法については別の章で解説されてるから、別の機会に書く予定にしてるよ。
どのテストレベルでやる？
機能テストは全てのテストレベルに適用できるテストタイプとされているんだ。
システムテストや統合テストでは会員管理機能全般や他機能との連携をテストするけど、コンポーネントテストでは会員管理機能の中の登録機能をテストするとかテストレベルによって確認するポイントが異なるのでテスト範囲がどこからどこまでで、何を重視するかを把握しておかないと他のテストレベルと同じことをテストして工数の無駄遣いにもなるからね。
機能カバレッジ
対象の機能に対してテストが十分かどうかを機能カバレッジを用いて計測しておくのも重要なことだね。
テスト対象と機能の範囲の機能要件や仕様書から抜き出したテストすべきポイント（要素）がテストの中にどれだけ含まれているかの割合が機能カバレッジ（網羅率）だよ。
テストした範囲の内、テストすべき要素がどの程度確認済みか計算すふことで、どこがテストできていて、どこが足りてないかを確認できるんだ。
機能テストはシステムや製品のソフトウェアの振る舞いがユーザーや顧客の要求、要件を満たしていることを確認する為のテストで、テスト分析の時に仕様をしっかりと把握してテスト設計、テスト実装へ反映、テスト実施でカバレッジを確認して進めることになるよ。
次回は信頼性、性能効率性、セキュリティ、互換性、使用性とかを対象としている非機能テストのお話をするね。
では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡