この記事はCameron Lairdによるゲスト投稿です。

テスターは顧客の目に入る機能が正しいことを保証する必要があります。しかし、あまりに多くの組織が—さらに少なくとも一部のテスターが—依然として、テスターにできるのはそれだけだと信じており、ソフトウェア品質に対してテスターが貢献できるその他多くのチャンスを逃しています。

以下は、目に見える機能以外で、テスターが容易に得点を挙げられる7つの方法です。

1.アクセス

通常、開発者が何に合わせて開発環境を最適化しているかと言えば、そう、開発です。たとえば、ウェブアプリケーションであれば、個々のプログラマーはFirefox向けにワークフローを構成しており、完全にFirefoxの中で作業しているかもしれません。

しかし、アプリケーションが品質保証(QA)まで来ると、状況は完全に異なります。アプリケーションはFirefoxで動作しなければなりませんが、Chrome、Safari、Operaやその他すべてのブラウザーで、またブラウザーごとにさまざまな設定で、さらにはリソースが枯渇した状況などでも動作する必要があります。一人の顧客がすべてのブラウザーを利用するわけではありませんが、多くの製品またはサービスは、幅広いブラウザーで適切に動作する必要があります。ですから、QAは広範囲にわたってテストする責任があります。

幸運なことに、このような責任に応えられるツールがあります。さまざまなブラウザーを多様な方法でエミュレートできるツールがいくつかあります。このようなツールを使うと、各ブラウザーを個別に整備したり起動したりするよりずっと早く簡単に幅広い動作のテスト結果を集積できます。

この領域でもう1つ注目すべきは、Googleが提供するLighthouseです。このツールは、いくつかの観点からウェブページの品質を判断します―たとえば、視覚障がいのあるユーザーにとってページを読みやすくするのに役立つ標準への準拠という観点からアクセシビリティを判断できます。全面的なテストに視覚障がい者向けのブラウザーを含めるのは有益であり、Lighthouseや関連ツールはそのようなテストに役立ちます。

2.インタラクション

典型的なエンドユーザーの目に入るものを超えた機能に対するテストの2番目は、特定の要素間のインタラクションのテストです。
たとえば、一定の期間が経って、有効なカードの期限が切れたとき、Eコマースサイトはどのように振る舞うべきでしょうか？これはエラー対応ではありません。ユーザーの入力は、その時点ではすべて正しかったのです。これは時間の経過にともなう特殊なインタラクションであり、特殊なアクションを必要とします。

もう1つ、ほとんどのユーザーが遭遇することのないインタラクションの例は、エンドユーザーの複数のエントリが矛盾を示唆する場合にどうするべきかです。もし5歳の子供が抵当入札をリクエストした場合、何を意味するでしょうか？何を意味するべきでしょうか？このような応答を定義することのビジネスバリューは、QAが時間を費やして定義し検証する価値があるでしょうか？

3.例外処理

もちろん、明らかなエラーの処理は重要です。たいていのユーザーは正しいデータを入力し、それに応じた結果を受け取ることに関心がある以上、意図しないエラーはユーザーエクスペリエンスをだいなしにする可能性があります。

たとえば、入力されたパスワードがサイトのポリシーに従っていないと言うメッセージは、同じパスワードに対する似たようなメッセージでも、パスワードがサイトの要求する長さに満たないというメッセージよりもずっと不満と混乱につながる可能性が高いでしょう。エラーメッセージは、アプリケーションに苦しめられているのではなく、支援され保護されているという印象をユーザーに与えるのに大きな役割を果たす可能性があります。

4.キャパシティプランニング

負荷が計画されたキャパシティを超えた場合、何が起きるでしょうか？システムは壊滅的な障害を防ぐために機能を限定するかもしれません（グレースフル・デグラデーション）。？私たちはシステムに常に予備のキャパシティがあることを望んでいますが、それを保証する一環として、予備のキャパシティがない場合の動作を理解し、計画する作業があるのです。

理想的には、システムは「予備の大容量ストレージが合計使用量の22%未満になってはならないが、現在の予備は14%しかない」といった警告を生成すると良いでしょう。そうすれば、スペースを使い果たす顧客がいないようオペレーターが調整する機会を与えられます。

5.ローカリゼーション

これは同じテーマのもう1つのバリエーションです。別のロケールを設定したとき、アプリケーションはどのように応答するでしょうか？たいていのエンドユーザーは、わざわざロケールを変えることはほとんど、あるいはまったくありせん。それでも、ユーザーがそれぞれのニーズに対して受け取る結果は正しくなければなりません。従って、すべての範囲をテストすることが求められるでしょう。

6.公平性

良いユーザーインタラクションとは、正しいだけではなく、一貫性があり、予測可能で統一性のあるものでなければなりません。Smithというよくある姓では、Fernsbyという珍しい姓よりも処理が大幅に遅くなる―あるいはその反対の－アプリケーションは、ユーザーに迷惑をかける可能性があります。アプリケーションが「公平」または「不公平」であると感じさせるものが何であるかをユーザーが正確に言い表せないとしても、良いソフトウェアは人間の公平性に対する期待に応えます。

7.コンプライアンス

ユーザーは、ソフトウェアがサードパーティ製ソフトウェアを内包する際のライセンス要件に準拠しているかどうかを知ったり気にかけたりすることはまずないでしょう。しかし、QAはライセンス要件を検証し、訴訟やその他のペナルティの可能性を摘み取るのに適した立場にいるかもしれません。

この領域で役に立つさまざまなセキュリティやコンプライアンススキャナー(Kiuwanなど)があります。同様に、スタイルガイドへの準拠、カバレッジしきい値やソフトウェアエンジニアリングが要求する関連メトリクスを満たしているかのテストも、QAが役に立てる領域の候補です。

結論

テスターがテストするものの大部分は目につく機能です。しかし、機能をテストするスキルは、顧客が目にするものを超えた要件にも適用できます。QAは、このような検証のさまざまな面を明確にし、効果的に管理するのが良いでしょう。

（この記事は、開発元Gurock社の Blog 「7 Types of Testing Beyond What Customers See」2020年10月14日の翻訳記事です。）