回答

問題の歴史:

非機能的側面のテストは、機能が論理的には完璧でも、一部のユーザーにとっては使いにくかったり、遅かったり、アクセスできなかったりすることが明らかになったときに始まりました。これらの欠陥は自動的には検出しにくいため、手動テスト担当者が重要な役割を果たしています。

問題:

テスターはしばしば機能面にのみ焦点を当て、パフォーマンス、使いやすさ、アクセシビリティを無視します。非機能的欠陥は形式化したり説明するのが難しく、その主観性は明確な評価を得るのを妨げます。

解決策:

テストでは、非機能的なチェックに意識的に時間を当てるべきです。パフォーマンスについては応答時間を記録し（たとえば、ストップウォッチで）、使いやすさについては不便を説明し例を挙げ、アクセシビリティにはチェックリストやツールを使用します（たとえば、スクリーンリーダーを使用するなど）。

主な特徴:

• 受け入れ基準を明確に定義する必要があります。
• 評価結果はしばしば主観的であり、報告書の根拠が重要です。
• すべての非機能的欠陥がリリース前に許容されるわけではなく、一部は重大です。

トリッキーな質問

すべての非機能的欠陥はテスターによってバグレポートとして記録されるべきですか？

必ずしもそうではありません。問題が主観的な場合、チームと話し合い、改善要望として記録するだけで済むことがあります。

テスターは自らパフォーマンスの指標を設定すべきですか？

要件や仕様書に記載されていない場合のみ、そうすべきです。そうでなければ、それに依存するべきです。

非機能テストのための特別なソフトウェアやツールは必要ですか？

いいえ、基本的なチェックは手動でも十分に可能です（たとえば、手動での時間測定、チェックリストによるアクセシビリティ分析など）。

一般的な間違いやアンチパターン

• 非機能的基準の無視。
• 測定可能な証拠なしの主観的な報告。
• 非常に一般的または曖昧なバグのタイトルと説明。

実生活の例

ネガティブケース

テスターは、カタログページの読み込みが10秒以上かかることに気付いたが、「おそらくみんなそうだろう」と思い、バグを記録しなかった。

利点:

• 議論のあるチケットでチームを混乱させなかった。

欠点:

• ユーザーエクスペリエンスが低下し、顧客は失望し、問題は上司が苦情を受けるまで知られなかった。

ポジティブケース

テスターは、カタログページが初回ログイン時に12秒かかることを詳細に記録し、ストップウォッチのスクリーンショットを添付し、可能な最適化の提案をしました。

利点:

• チームは問題の客観的な説明を受け、迅速に診断できました。

欠点:

• そのようなバグを文書化するのに多くの時間がかかる。