はじめに

備忘録的なもの

JSTQB Foundation の「テストとは何か？」について印象に残っている部分のメモ起こしです。

テストとは何か？

ソフトウェアシステムは、様々な分野で使われています。ソフトウェアが期待通りに動作しないと、なんらかの不都合をユーザーと開発者に与えることがあります。

不都合は、大きく分けて4つあります。

経済的な損失

経済的な損失には、トラブルが発生したソフトウェアの修正や再テストにかかるコスト、クレーム受付などトラブル対応にかかるサポートのコストがあります。

時間の浪費

システムのトラブルによって起こるソフトウェアの修正作業は、本来別の開発に当てるはずだった開発者の時間を浪費させます。

信用の失墜

品質の低下は信用の失墜につながります。会社そのもののブランドイメージの低下になってしまいます。

損害や死亡事故

ソフトウェアの用途によっては、動作が正しくないと死亡事故にも繋がります。

ソフトウェアが本番で使われる前に、期待通りの動作をするかを確認するソフテウェアテストをします。動作しない場合に、その故障が発生しなくなるところまで見届けることで、本番で運用するときにソフトウェアの故障が発生する可能性を低くすることができます。

テストで目的をはっきりさせることで、テストにかける工数や期間、テストを行うメンバーのスキル、開発担当者との関わり方など色々なことが変わってきます。 JSTQBに明記されている、共通して必要と思われるテストの目的は以下になります。

作業成果物の評価

作業成果物のレビューは、正しく書かれているかの確認以外にも、「間違ってはいないが誤解を招きやすい記述がされていないか」「構成に一貫性がなく非常に読みづらい」といった他の観点でも見る必要があります。

要件を満たしていることの検証

どのテストレベルでも作業成果物が要件を満たしているか検証する必要があります。

妥当性の確認

受け入れテストでは、要件の検証だけでなく、それを使うユーザーが期待していると思われる動作内容を確認します。

品質レベルの確証

一部のテストの結果に合格しているだけでは不十分で、全テストレベルで計画したテストの結果や欠陥修正の結果を、マトリクスを使って確認します。

欠陥の作り込みの防止

過去に行ったテストにて検証した故障と修正した欠陥の原因分析を行い、その後の開発を行う際に分析結果を取り入れることで、同じ欠陥を作り込むことを防止します。

故障や欠陥の発見

より多くの故障や欠陥を発見して、ソフトウェアの欠陥を特定して修正します。

意思決定のための情報提供

テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることの確証を得ます。欠陥の修正が完了しないままリリースをしなければいけない場合には、欠陥がどこまでのインパクトとなるか？、欠陥の回避策、ここまでを考慮して有用な情報となります。

ソフトウェアシステムが、契約上、法律上、または規則上の要件や標準に準拠していることの検証

ソフトウェアが使われる業界ごとに、要件や標準を遵守する必要があります。

テストは、ソフトウェアに存在する欠陥に起因する故障を発見することを目的としています。デバッグは故障の基になる欠陥を見つけて、原因を解析・修正を目的としています。

その後、テスト担当者がテストを行い、欠陥の修正で故障が解決したことを確認します。

テスト担当者はテストに責任を持ち、開発担当者はデバッグに責任を持つことになります。ただし、役割が変わることもあります。アジャイル開発では、テスト担当者はアジャイルチームの一員となります。役割分担にとらわれずに、テスト設計をレビューしたり、デバッグのためにソースコードを調べたりすることもあります。