各テストの概要と意識したいこと【再入門】

はじめに

自分が業務でテストを行っている際に、「テスト時に改めて頭に入れておきたいことを言語化したい」と思ったことがきっかけで記事にまとめてみることにしました。
今までは作成された仕様書に沿ってテストを行うことが多く、このままでは身に付いていかないと感じたので、記事にすることで "テスト" というものについて改めて向き合うことにしました。

こんな人におすすめ

• テストの概要を知りたい
• テストの際に意識する視点を持ちたい

テストとは

不具合を見つけ解消することで、 「ユーザーの要求を満たし、価値を提供するソフトウェア」を完成させるためのブラッシュアップ作業。
ざっくりいうと、このような位置付けではないかと思います。
もちろん設計・製造段階でバグに気付けるのが良いのですが、　一発で完璧な仕様かつ100%バグのないソフトウェアを開発する、というのはほぼ不可能なのではないでしょうか。
そこで、更に品質の良いソフトウェアにしていくために必要な工程としてテストが存在します。

開発工程とテスト工程の紐づけ

今回は、主にウォーターフォール型のソフトウェア開発やソフトウェアテストにおいて用いられる一般的な手法である「V字モデル」をベースにしていきます。

各テストの概要

このセクションでは、各テスト概要とテストの種類について記載します。

単体テスト

ソフトウェアの最小単位であるモジュールごとに行うテストのことで、主に詳細設計書通りに動くかどうかを確認します。製造したプログラマ自身が担当することが多いです。

種類	内容
機能確認テスト	各モジュールが詳細設計書通りに動作することを確認する。
制御フローテスト	プログラムの論理構造に沿って、命令や分岐が全て実行されるかどうかを確認する。
データフローテスト	データや変数が「定義→使用→消滅」の順に行われているかを確認する。 静的解析ツールなどを用いる。

結合テスト・機能テスト

【結合テスト】
複数のモジュールを組み合わせて行うテストのことで、詳細設計で定義したモジュール間の連携方法が実現されているかを確認します。具体的には、モジュール間のデータが正しく受け渡されているか、処理の順序が正しいかといった動作順序やタイミングを確認します。

【機能テスト】
組み合わせたモジュールを一つの機能としてテストを行い、機能として正しく役割を果たしているかを確認します。プロジェクトによっては、単体テストの次に機能テストのみを行う場合があるので、その際は結合テストは機能テストの一部として行います。

種類	内容
状態遷移テスト	状態遷移図、状態遷移表に基づいて動作を確認する。
機能確認テスト	複数のモジュールで実現される機能が詳細設計書通り動作することを確認する。 モジュール同士の連携も確認する。

システムテスト

個々のモジュールや機能を統合した状態で、要件定義の内容が実現されているかどうかを確認します。
テストは最終的に製品として出荷する状態、またはサービスとして提供する状態に近い形で行います。

種類	内容
確認テスト	一度テストされている事項を再度確認する。 修正確認テスト、リグレッションテスト、スモークテスト、リリースチェックテスト等。
評価テスト	単純には判定しにくい品質に対して程度を判断する。 セキュリティテスト、ユーザビリティテスト、障害許容性テスト等。
負荷テスト	動作しているソフトウェアに負荷をかけて行う。 性能テスト、ロングランテスト、大容量（ボリューム）テスト、記憶域（ストレージ）テスト、高頻度テスト、負荷（ストレス）テスト等。
環境テスト	ソフトウェアを取り巻くプラットフォーム周辺機器に注目して行う。 構成テスト、互換性テスト、両立性テスト等。
機能確認テスト	ユーザーの要求を満たすために、ソフトウェアの各機能の働きが詳細設計書通りに動作することを確認する。 OSや環境、複数の機能、設定値、入力値などを組み合わせて行う。

テストで意識したい、2つの視点

テスト担当者が持つべき視点として、「verification&validation」「Never Must Want」を常に意識することが大切だといわれています。

verification & validationとは

一般的には「検証と妥当性確認」と訳されていて、略して　「V&V」ともいいます。

verification（検証）

verification（検証）とは、仕様書通りにソフトウェアが作成されているかを確認することです。検証の際はソフトウェアを実際に動作させます。

validation（妥当性確認）

validation（妥当性確認）とは、ユーザーの要求通りにソフトウェアが作成されているかを確認することです。ソフトウェアを実際に動作させるだけでなく、仕様書の妥当性チェックも行います。

家計簿アプリを例に考えてみる

【verification(検証)により見つかる欠落】

• 収支計算機において、特定の入力値に対する計算が誤っている。
• 仕様書に記載されている、家計簿の集計期間の設定機能が備わっていない。

【validation（妥当性確認）により見つかる欠落】

• データを１件登録すると一覧画面に戻ってしまうため、連続登録の際に使い勝手が悪い。
• UIが複雑で使いづらく、データを入力するのに手間取る。

Never Must Wantとは

顧客の要求を「あってはならないこと」「できなければならないこと」「できたら良いこと」の３つに分け、テスト時にそれらが満たされているかを確認するフレームワークです。

Never(あってはならないこと)

Never(あってはならないこと)とは、そのテスト対象を使用するうえで "絶対に起こってはいけないこと" です。例えば、人の生命や財産に影響を及ぼすような事態を想定します。

Must(できなければならないこと)

Must(できなければならないこと)とは、そのテスト対象を使用するうえで "できなければならないこと" です。ユーザーが思った通りに要求を達成できるかどうかを確認します。

Want(できたら良いこと)

Want(できたら良いこと)とは、そのテスト対象を使用するうえで "できたらいいなと思うもの" です。
製品に求める要望は、テスト実施中に思いつくことがあります。仕様通りではあるが改善した方が良い点やユーザビリティへの気づき等があれば、次の派生開発やプロセス改善の際に役立つのでメモしておくと良いでしょう。

家計簿アプリを例に考えてみる

【Never(あってはならないこと)】

• 顧客が入力したテータの破損や紛失
• 会員情報の漏洩

【Must(できなければならないこと)】

• 支出をカテゴリー別に集計し表示する機能
• データの定期バックアップ

【Want(できたら良いこと)】

• 予算を設定して、実際の支出と比較することができる機能があると便利
• 銀行口座やクレジットカードから取引履歴を自動的に同期する機能があると便利

さいごに

いかがでしたでしょうか。
テストは何なのか、目的や意識したいことを少しでも落とし込めたでしょうか。

正直なところ、私の場合きちんとテストに向き合うまでは「テストが怖い」とすら感じていました。自身が作成したソースコードのバグを見つけたときは苦しいし、まだまだ知見が浅いなぁと悔しい気持ちになっていました。

でも一番怖いのは、不具合が潜んだ状態のソフトウェアを提供してしまうこと。

テストで見つかってよかった、くらいの気持ちでテストに挑めるようになりました。