答え。

検証と妥当性は、テストにおける製品の期待と要件の適合性を定義する2つの重要な概念です。

問題の歴史:

ソフトウェア工学では、製品が仕様に適合していることを示す検証と、ユーザーの期待に適合していることを示す妥当性の概念が分けられ、品質の異なる側面を説明するために使用されます。

問題:

専門家はこれらの用語を混同し、アプローチを誤って適用します：テクニカルな要件に基づいてのみテストし、ユーザーの経験を無視するか、逆に「正しい/使いやすい」という論理のみに頼り、形式的な要件を忘れます。

解決策:

• 検証（私たちは製品を正しく構築しているか？）— 製品がすべての仕様要件（テクニカル仕様、ドキュメンテーション）を満たしていることを確認します。
• 妥当性（私たちは正しい製品を構築しているか？）— 製品がユーザーの問題を解決し、実際の期待に適合していることを確認します。
• 両方のアプローチを使用します：テクニカル仕様に基づいた検証と、実際の探求的テスト、ユーザースシナリオ、受け入れテストを通じた妥当性。

重要なポイント:

• 検証 = 要件の形式的検査。
• 妥当性 = ユーザーへの共感、実際のシナリオの模倣。
• 両方のステージがエラーを完全にカバーするために必要です。

引っかけ質問。

「製品は検証に合格したが、妥当性に失敗した」とはどういう意味ですか？

それはテクニカル仕様に適合しているが、使いやすくなく、ユーザーの問題を解決せず、市場には必要とされないということです。

妥当性を検証より先に開始できますか？

いいえ、まず基本的な要件セットが確認されなければならず、そうでないと不完全な機能性によりユーザー体験を評価することができません。

検証において使いやすさの欠如はバグのように見えますか？

いいえ、これはUXの問題であり、ユーザースシナリオの妥当性ステージでのみ明らかになります。

一般的なエラーとアンチパターン

• テクニカル仕様にのみ焦点を当て、UXを無視する。
• 受け入れテストをスキップする。
• 実際に製品を使用する人々とのコミュニケーションが不十分。

実生活の例

ネガティブケース

ドキュメントの要件にのみ準拠してテストしました。リリース後、ユーザーは注文手続きのステップの論理が理解できないことが判明しましたが、形式的には記述されたケースに適合しています。

利点:

• すべての仕様の要件が実現されています。

欠点:

• ユーザーの関与が低く、苦情があり、製品を拒否されました。

ポジティブケース

探索的テストを利用し、実際のユーザーとのUXテストを実施しました。使いやすさの問題を発見し、注文プロセスを改良しました。結果 — ポジティブなフィードバックと高いコンバージョン。

利点:

• 製品は有用で直感的、需要があります。

欠点:

• UXの改良にはより多くの時間とリソースを要しました。