政治家のその場しのぎの制度みたいな作り方したシステムはきっとバグだらけ〜テストレベル Part4
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
昨日はライブバーでビールを飲みながらガンダムを組み立ててたよ。
細かいコンポーネントを組み合わせて統合して一つのガンダムと言うシステムを作り上げる感じだね。
無理やりこじつけたけど今回はシステムテストのお勉強をしようね。
システムテストの目的
• リスクの軽減
• システムの機能的/非機能的振る舞いが設計および仕様通りであることの検証
• システムが完成し、期待通りに動作することの妥当性確認
• システムの全体的な品質に対する信頼の積み上げ
• 欠陥の検出
• 欠陥がより高いテストレベルまたは運用環境まで見逃されることの防止
システムテストはシステム全体の振る舞いや能力に焦点を当てたテストだよ。
ステークホルダーがシステムテストの情報からリリースに関する意志決定を行うことも多いから見落としは避けたいテストレベルだね。
他にもシステムテストでは、法的要件、規制的要件、または標準を満たすことを確認する場合もあるんだ。
そう言った背景があるからテスト環境も最終的なターゲットまたは本番環境に準じることが理想とされているよ。
ここで言う「本番環境に準じる」は製品として販売するなら初期の試作品とかじゃなく製品版に違い試作品、システムであれば納入先の顧客の本番環境に近い環境（ステージング環境）とかになるよ。
そろそろ良い子のみんなも気づいたと思うけど、
今までのテストレベルでも「リスクの軽減」、「欠陥の検出」は共通の目的になっていたよね？
「品質に対する信頼の積み上げ」もテストレベルごとに対象は違うけど目的が同じになってるよ。
コンポーネントテストと統合テストではより高いテストレベルに欠陥が残るのを防止する目的だったのが、「運用環境まで」が追加されているから注意が必要だね。
テストベースとテスト対象
テストベース
システムテストでテストベースとして使用できる作業成果物の例:
• システム要求仕様およびソフトウェア要求仕様(機能および非機能)
• リスク分析レポート
• ユースケース
• エピックおよびユーザーストーリー
• システム振る舞いのモデル
• 状態遷移図
• システムマニュアルおよびユーザーマニュアル
テスト対象
システムテストの典型的なテスト対象の例:
• アプリケーション
• ハードウェア/ソフトウェアシステム • オペレーティングシステム
• テスト対象システム(SUT)
• システム構成および構成データ
システム全体の振る舞いや能力に焦点を当てるのがテスト目的だからテストベースもシステム全体の振る舞いや能力を示すドキュメントになるし、ユーザーストリーからのシナリオも考えたりもするよ。
テスト対象はシステム全体の振る舞い、能力、データの流れとかを見ていくことになるね。
ネットショッピングだと会員登録やログインして買い物をしてお金を払うと言う流れの中で会員管理、商品管理、決済管理と言った機能同士、システム同士の動きが一通り問題なく動いたかを確認していくよ。
見つけておきたい典型的な欠陥と故障
システムテストの典型的な欠陥と故障の例:
• 正しくない計算
• 正しくない、または期待通りではないシステムの機能的または非機能的振る舞い
• システム内の正しくない制御フローおよび/またはデータフロー
• エンドツーエンドの機能的タスクを適切かつ完全に実行できない
• システム環境でシステムが適切に動作しない
• システムマニュアルおよびユーザーマニュアルに記載されている通りにシステムが動作しない
さっきのネットショッピングのシステムを例に考えると、
・商品の数とか値段の計算がおかしくなったり、注文した金額と決済金額が違う→「正しくない計算」
・注文した後の注文情報に間違った会員が紐づいてしまったり、注文後に在庫が減っていない→ 「正しくない制御フロー、データフロー」
と言う欠陥を見つけたいね。
統合テストでは見つけきれない一通りの処理の中でデータベースやシステム間のやり取りから発生する故障はシステムテストで見つけることが期待されるよ。
アプローチと責務
システムテストは通常、独立したテストチームが仕様を元にして行うことが多いとされてるよ。
だから仕様に欠陥があるとシステムで期待される振る舞いへの正しい理解が欠落したり、誤解が生じてしまうこともあるんだ。
その結果、偽陽性や偽陰性による時間の浪費、欠陥検出効率の低下と言う残念なシステムテストになってしまうよ。
プロジェクトの早い段階でテストベースになる仕様書や各種資料のレビューにテスト担当者が参加してテストベースの品質を上げることで有益なシステムテストが可能になるんだ。
システムテストの目的で何が重要なのか？どんな環境が望ましいのか？他のテストレベルとの違いはどこにあるか？どんな欠陥が見つかりやすいのか？仕様に欠陥があるとどうなるか？仕様の欠陥を防ぐ対策はどうするか？と言うポイントをしっかり押さえておこうね。
いよいよ、次回は最後のテストレベル「受け入れテスト」のお話だよ。
では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？