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