受け入れられないこともビールで流し込むのが大人〜テストレベル Part5
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
受け入れ難い嫌なことがあっても、世間の苦みをビールの苦味と共に流し込んで次の日も働きに行くのが大人ってヤツだよね？
そんな苦味がわかる大人の僕が今回、お伝えするのは受け入れテストのお話だよ。
受け入れテストの目的
• システムの全体的な品質に対する信頼の積み上げ
• システムが完成し、期待通りに動作することの妥当性確認
• システムの機能的/非機能的振る舞いが仕様通りであることの検証
エンドユーザーが使用可能で製品の販売、システムの導入の準備ができているかどうかを確認するのが目的だよ。
また、法的要件、規制的要件、標準を満たしているかを確認する場合もあるんだ。
システムテストまでのテストレベルと違って、欠陥を見つけることは目的に入ってないんだよね。
もちろん、受け入れテストで欠陥が検出されることはあるけど、ここで大量の欠陥が見つかると重大なプロジェクトリスクと見なされるんだ。
受け入れテストまでのコンポーネントテストからシステムテストまでで重大な欠陥は報告、あるいは修正された状態であることが前提だから、他のテストレベルでの
「欠陥がより高いテストレベルまで見逃されることの防止」
と言う目的が果たせてないことになるから今までのテストなんやったん！？やり直ししなあかんのちゃう？ってことになるよね。
受け入れテストの種類
受け入れテストにはいくつかの種類があるよ。
代表的な受け入れテストを紹介しておくね。
ユーザー受け入れテスト
ユーザーが本番環境に相当する環境で想定するシステムの使用方法に合致していることを確認するために行う受け入れテストだよ。
運用受け入れテスト
運用担当者、システムアドミニストレーターが本番環境に相当する環境で運用面に焦点を置いた受け入れテストだよ。
ユーザー向けにシステムを適切な稼動状態に維持できるかを確認することに重点を置いているんだ。
パックアップや復旧、メンテナンス、セキュリティと言った運用面をテストするのがポイントだね。
契約による受け入れテストおよび規制による受け入れテスト
契約書に記述した受け入れ基準、政府、法律、安全の基準などに合致しているかを確認するための受け入れテストだよ。
準拠してないと販売できなかったり、システムとして使用してはいけないと言った厳しめの規制もあるし、海外に展開する場合は国によって規制も違うからテストケースを作る時はしっかりとテストベースを確認しようね。
ユーザーまたは独立したテスト担当者が行うことが多く、規制による受け入れテストの場合は規制機関が結果の証明や監査を行って承認する場合もあるよ。
アルファテストおよびベータテスト
ソフトウェアプロダクトを市場へリリースする前に、潜在的または既存のユーザー、顧客や運用担当者からフィードバックを受けるために行う受け入れテストだよ。
JSTQB FLシラバスでは誰が担当するかが以下の内容で記載されているんだ。
アルファテストは、開発組織内にて開発チームの代わりに潜 在的または既存の顧客、および/またはシステムの運用者もしくは独立したテストチームが行う。ベータ テストは、潜在的または既存の顧客、および/またはシステムの運用者が彼ら自身の作業場所で行う。
アルファテストは開発環境や本番環境相当で行うのが一般的でユーザーもその環境にアクセスできる権限がある人だから、その組織、または組織と関係のあるユーザーのみが行うと考えるのがいいね。
ベータテストは本番環境で組織外の一般ユーザーも参加することを前提としているテストだよ。
MicrosoftやGoogleがベータ版リリースとかたまにニュースで目にすると思うけど、ユーザーがそのベータ版を使ってフィードバックしたりするけど、これもベータテストだね。
テストベースとテスト対象
さまざまな形態の受け入れテストでテストベースとして使用できる作業成果物の例:
• ビジネスプロセス
• ユーザー要件またはビジネス要件
• 規制、法的契約、標準
• ユースケースおよび/またはユーザーストーリー
• システム要件
• システムドキュメントまたはユーザードキュメント • インストール手順
• リスク分析レポート
運用受け入れテストでは、テストケースを導くためのテストベースとして、以下の作業成果物も使用で
きる。
• バックアップ/リストアの手順 • 災害復旧手順
• 非機能要件
• 運用ドキュメント
• デプロイメント指示書およびインストール指示書 • 性能目標
• データベースパッケージ
• セキュリティ標準または規制
典型的なテスト対象
さまざまな形態の受け入れテストで典型的なテスト対象の例:
• テスト対象システム
• システム構成および構成データ
• 完全に統合されたシステムのビジネスプロセス
• リカバリーシステムおよび(ビジネス継続性および災害復旧のテスト用の)ホットサイト
• 運用プロセスおよびメンテナンスプロセス
• 書式
• レポート
• 既存または変換(コンバージョン)した本番データ
主にシステムを対象としたテストベースとテスト対象が書かれているけど、販売する製品の場合は取説とかユースケース、ユーザーストーリー、規制、法的契約、標準と言ったテストベースとそれに対する製品の動作がテスト対象になるよ。
見つけておきたい典型的な欠陥と故障
さまざまな形態の受け入れテストで典型的な欠陥と故障の例:
• システムのワークフローがビジネス要件またはユーザー要件を満たさない。
• ビジネスルールが正しく実装されていない。
• システムが契約要件または規制要件を満たさない。
• セキュリティの脆弱性、高負荷時の不適切な性能効率、サポート対象プラットフォームでの不適 切な操作などの非機能特性の故障。
受け入れテストは欠陥を見つけることが目的ではないけど他のテストレベルで確認してない（できていない）本番環境相当の環境でしか発生しない欠陥はここで見つけると言う考え方になるんだ。
アプローチと責務
受け入れテストは顧客、ビジネスユーザー、プロダクトオーナー、またはシステムの運用担当者の責任で行われるし、他のステークホルダーが関与することもあるよ。
シーケンシャル開発モデルではテストの最終段階、イテレーティブ開発モデルでは各イテレーションの最後に行うことが多いんだ。
開発モデルによるタイミングの違いにも注意しようね。
欠陥を見つけると言うより、ちゃんと使えるよね？と言う目的になっていること、受け入れテストの種類、テストベースやテスト対象が他のテストレベルとどう違うか？逆に共通点はどこにあるか？と言うポイントを押さえておきたいね。
小さい範囲から少しずつ広げて確認観点も段階ごとに変わるテストレベルのお話はここまでだよ。
次回は、、、何を書くか決めてないよー
気分転換のネタにするか？
このままの流れでテストタイプの話にするか？
それは明日の僕が考えてくれるはずだから
今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？