この記事はCameron Lairdによるゲスト投稿です。
ソフトウェアテスト理論によれば、さまざまな種類のテストがあります。単体テスト、統合テスト、負荷テストなどです。しかし、ソフトウェア以外の、それでいてやはりソフトウェアに関わる他のテストも重要です。
テスターがやり方を知っておくべきその他のテストには、次のようなものがあります。
機能テスト
テスターがテストするものの大半は機能です。たとえば、ユーザーがすでに使われている名前で新規アカウントを登録しようとしたとき、テスト対象のシステムは「ユーザー名$NAMEはすでに使用されています」というメッセージを表示する必要があります。
もう少し複雑な要件は、たとえばショッピングカートの動作などを定義します。この場合、テストでやるべきことには、税や送料の計算、値引きの適用、顧客の意思の確認、フルフィルメントや会計などのシステムへの結果の転送が正しいかどうかの確認が含まれます。
従来、アプリケーションテスターの労力はこの種の機能に集中されてきました。しかし、テストスキルは他にもいろいろと役立てられます。
アクセシビリティ
LighthouseはGoogleが公開するオープンソースの自動ツールで、Webアプリケーションが特定のアクセシビリティ、パフォーマンス、SEOなどの基準を満たしているかを検証するのに役立ちます。
アクセシビリティは、年齢、能力、言語、場所にかかわらず、あらゆる人々に効果的にデリバリーするために欠かせません。それは、製品が誰一人として排除しないよう、誰にでも利用できる品質の高いサイトやツールを構築するということに尽きます。
セキュリティ
情報技術（IT)セキュリティは、もちろん、常に発展し続ける大きなテーマです。セキュリティの特定の側面をテストするのはフルタイムの仕事であり、専門家ではない人間が常に最先端に追随するのは非現実的です。
それでも、テスターがアプリケーションセキュリティの基本を学ぶことには価値があります。セキュリティの欠陥を早期に検出するために警戒できるだけでなく、セキュリティ技術を意識することで、機能の潜在的な弱点を検出できるようテストを設計するのに役立ちます。
たとえば次のような例があります。特定のシステムは、機密を要する処理についてはHTTPではなくHTTPSを使用するよう設計されていることがあります。HTTPSの使用が完全にセキュアであるとします―これはもちろん、良いことです―しかし、特定のハイパーリンク生成に”HTTP”を”HTTPS”に置換する処理が含まれているとします。エンドユーザーがHTTPではなくHTTPSベースでURLをリクエストした場合、最終的にユーザーは https://$SITE/… に誘導されるかもしれません。
https://… を使用してサービスをリクエストすることがセキュリティ脆弱性にはつながらないとしても、リクエストはエンドユーザーに意味のある結果を返しません。これは完全に機能のエラーであり、ユーザーにデリバリーされる前に社内テストで検出するほうがよいでしょう。
コンプライアンス
完全無欠のアプリケーションを想像してみましょう。エンドユーザーが望むあらゆることを適切かつタイムリーに行い、セキュリティは万全で、アクセシビリティも高得点をマークしています。まさにあるべき姿です―ただし、許諾されていない方法で利用しているサードパーティ製ライブラリに依存していることを除けば。
Kiuwan Insightsなどのライセンススキャニングソリューションは、このような欠陥を防ぐのに役立ちます。他のコンプライアンスに特化したツールはSarbanes-Oxley、HIPAA、PCI DSS、SOC 2、COBITなどの規制や標準へのコンプライアンスを保証するのに役立ちます。テスターは、少なくとも、自分の関わる市場に適用される規制を知っておくのが賢明です。
テキスト
ユーザーがヘルプアイコンを押したとき、「このページは意図的に空白のままです」と表示されたとします。これは十分ではありません。
狭い意味でのソフトウェアの欠陥ではないかもしれません。アプリケーションはヘルプサブシステムから取得したコンテンツを正確に伝えたのでしょう。これはもちろん良いことです。テストでは、ソフトウェアが正常に動作したことを報告する必要があります。
テストとしては、アプリケーション全体としては欠陥があることをできるだけ迅速にレポートするべきです。コンテンツ―あるいはドキュメント、その他どんな呼び名であれ―がソフトウェア開発とは別個に管理されているとしても、テスターの責任はエンドユーザーを代弁し、エンドユーザーのエクスペリエンスができるかぎり最善のものであるよう保証することです。
大規模なアプリケーションでは、コンテンツは隙間からこぼれ落ちやすく、不足したり不完全だったり、編集が不適切だったり、ローカライズが不正確だったり、そうでなくても、役に立つよりも混乱を招くものになりがちです。イギリス英語とアメリカ英語のつづりが混在しているといったささいなことでも、エンドユーザーのエクスペリエンスを損なう可能性があります。
アプリケーションに埋め込まれたコンテンツに関して、テストは何ができるでしょうか？テストの果たすべき役割の多くと同様に、以下のようなアプローチを組み合わせることでのみ、テキストによるコンテンツの正確さを適切に確保したと自信をもって考えることができます。
- 多くの出力または表示を自動で検証する
- 熟練したテスターが特定のページを重点的にチェックする
- ソースをスペルチェッカー、文法チェッカーなどにかけて静的スキャンする
- 報奨を出したり能動的にエンドユーザーにリーチすることでエラーを検出する
写真、図表、その他の画像
非テキストコンテンツもテキストと同様ですが、より困難です。適切な写真は、アプリケーションやサイトが狙っている印象を与えるのに大きな役割を果たします。写真が誤っていたら、スケートボードのチャンピオンと亡くなった台本作家の区別もおぼつかないとエンドユーザーに思われるでしょう。
そのようなエラーはソフトウェア開発者が修正できるようなものではないかもしれません。それでも、問題が修正されるまでは、顧客や閲覧者はソフトウェアにしかるべきチャンスを与えないでしょうから、テスターは非テキストコンテンツやコンテンツが伝えるメッセージに敏感であるべきです。
その他の自動化
多くの組織では、テストの責任範囲は限定的です。たとえば、アクセシビリティのテストに特別にテスターが配置されることはないでしょう。テストの役割が非常に狭い極端なケースでも、どんなツールが利用できるのかを知ることはテスターにとって価値があります。
特化したツールは、ソフトウェアアプリケーションの品質に関わるその他いくつかの特質を管理するのに役立ちます。広く適用できるツールには以下のようなものがあります。
- さまざまなWebブラウザーにわたって結果を比較できるツール(Chrome vs. Safari vs. Edge、デスクトップ vs. モバイルなど)
- ソースのテストカバレッジ、ソースの形式的品質、ソースのチャーンが制限値内に収まっていることを確認するためのダッシュボード
- ミューテーションテストを自動化するツール
たとえば、アプリケーションの大部分のカバレッジが85%であるのに、新機能を構成するソースのカバレッジスコアが30%だったとします。そのソースは直近3つのスプリントでアクティビティのホットスポットであり、「lintのチェック」はかろうじて合格するようなものでした。機能は正式な機能仕様に合格しているとしても、こういった他の側面からは、特別な注意を向ける価値があるように見えます。
少しばかり追加の時間を費やしてみると、驚くようなことが―アプリケーションの一般ユーザーがつまずく前に見つかってよかったと思うようなことが見つかるかもしれません。
結論
組織のメンバーの多くは、テストの貢献を見るとき、狭い視野に偏りがちです。そういった人たちにあなたを制限させてはいけません。テスターはユーザーを代弁しているのですから。これは非常に重要であり、アプリケーションが提示するさまざまな種類の正しさを徹底的に考えること、また正しさを保証するのに役立つツールやプラクティスについて考えることで、よりよくその役割を果たせます。
Cameron Lairdは、賞を授けられたソフトウェア開発者で著述家です。Cameronは、Python Software Foundationの投票権を持つほか、いくつかの業界のサポートや標準化組織に参加しています。長くTexas Gulf Coastに住み、農場自動化アプリケーションがお気に入りです。
（この記事は、開発元Gurock社の Blog 「Testing Different Kinds of Correctness」2020年9月17日の翻訳記事です。）