新しいアプリケーションをテストするための戦略

ソフトウェアアプリケーションは複雑で、複数のコンポーネント間でリアルタイムに通信がおこなわれます。データベース、API、サーバー、さらにはハードウェア デバイスが連携して、シームレスなユーザー エクスペリエンスを提供します。

すでに本番環境にデプロイされているアプリケーションの場合、テスターはこれまでの開発経験から、どの機能が重要であるかや、どのテスト作業に焦点を当てるべきかを知っています。しかし、ドキュメントが少なく、過去のデータもない、まったく新しいアプリケーションを構築する場合、テストすべき機能をどのようにして知ることができるでしょうか。

今回、紹介する5つのヒントは、上記のようなケースにおいて役立てることができます。

1．あなたが知っていることから始めましょう

新しいアプリケーションが開発される前に、ステークホルダーは既に、製品に対して期待されていることについて、おおよそのイメージを持っています。既存ユーザーからの調査、ユーザビリティテスト、そして会社のビジネスゴールとビジョンに基づいて、顧客向けに構築する必要のあるアプリケーションのタイプを把握しています。

これは、テスト戦略の設計を開始するのに適しており、ステークホルダーにヒアリングをおこない、製品に関して多くの情報を入手するようにしてください。アプリケーションについてさまざまな視点を与えることができる開発者、ビジネス関係者および技術リーダーも該当します。
収集された情報は、アプリケーションの機能、ユーザーの期待、テストする重要なモジュール、およびテストを完了して製品をリリースする必要があるタイムラインを理解するのに役立ちます。

また、役立つドキュメントやリソースがある場合は活用してください。これらには、法的文書、ヘルプドキュメント、事業計画、および高レベルの要件が含まれる可能性があります。

2．競合他社の調査をおこないましょう

アプリケーションを学ぶための優れた方法は、競合他社の調査をおこなうことです。
たとえば、旅行予約アプリケーションを開発しているとします。 Expedia、Kayak、Orbitzなどの他のアプリケーションを参考にして、アプリケーションがそれらと比較してどのように機能するかを確認できます。

これらのアプリケーションが自分のアプリケーションと比較して、消費するメモリの量、旅行予約プロセスのさまざまなフロー、アプリケーションに存在するさまざまなモジュール、ユーザーが最初から最後までたどることができるクリティカルパスを観察できます。 これらの観察結果をドキュメント化し、アプリケーションをテストするためのガイドとして使用してください。

3．アジャイル手法を採用しましょう

会社がスクラム、XP、かんばんなどのアジャイルプロセスに従うことを決定した場合、テスターはユーザー ストーリーに基づいて何をテストするかを理解する必要があります。
各イテレーションには、設定された時間枠内で開発およびテストする必要がある一連のユーザー ストーリーがあります。テストする機能はユーザー ストーリーから明らかにすることができ、ストーリーが再生される順序は、テスト作業の優先順位付けに役立ちます。

ストーリーに含まれるテストの作業量を考慮することが重要です。
一部のストーリーは、他のストーリーに比べて作業コストが少なくて済みます。たとえば、ページのフォントサイズが15から16ポイントに変更されたストーリーは、アプリケーションの新しい支払い機能の実装を扱ったストーリーよりもテストが少なくて済みます。
後者の機能が期待どおりに機能しない場合、リスクと影響が大きくなるため、より多くのテスト作業をそれに費やす必要があります。

4．さまざまなテストアプローチを試してください

アプリケーションを学習し、テストするモジュールの優先順位を付けるのに役立つテストアプローチがあります。新しいアプリケーションに役立つアプローチは、セッションベースの探索的テストとリスクベースのテストの２つがあります。

セッションベースの探索的テスト

これは特定のモジュールに対して、決められた時間テストすることに焦点を当てたタイムボックスによるテストセッション（英文）です。この方法は、スクリプトテストのように詳細なテストケースを作成する代わりに、アプリケーションに関する迅速なフィードバックを得たい場合に、あらゆるドメイン、プロジェクト、アプリケーション内で使用することができます。これらのセッションでは、製品をより自由に探索することができ、セッションの目標の範囲内で創造性を発揮することができます。

すべてのセッションノートはチャータードキュメントに記録されます。
ドキュメントには、セッションの目標、セッションで使用された必要なリソース、セッション中に異なるタスクを実行するのにかかった時間を含むタスクの内訳、テストのアイデアや観察、セッション中に発見された問題、（必要であれば）スクリーンショットなどの詳細が含まれます。

これらのセッションを実施することで、学習と実行が同時におこなわれ、製品の機能に関してより良いアイデアが得られます。スクリプトや自動化されたテストでは見つけられないようなバグを発見したり、リスクの高いエリアや時間のかかるタスクを特定して、自動化の良い候補とすることができます。

リスクベースのテスト

リスクに基づいたテストでは、影響度の高い重要な個所に対して焦点を当てることができます。

たとえば、2つのストーリーをテストするとします。
ストーリーAは、映画をストリーミングするための新しいビデオプレーヤーを実装するためのもので、ストーリーBは、ビデオプレーヤーに関連するヘルプドキュメントをクリックしたときに、別のブラウザタブで開くようにするためのものです。
ストーリーAが期待通りに動作しなかった場合、顧客やビジネスへの影響が大きくなります。
ストーリーBは、期待通りに動作しなかった場合、問題にはなるものの、顧客が気づかない可能性が高く、ビジネスへの影響も大きくありません。

このような状況を考えると、上記のストーリーをテストするのに2日間ある場合、ストーリーごとに1日ずつ時間を費やすことは意味がありません。その代わりに、リスクの高いストーリーAには約1日半、ストーリーBには半日以下を費やします。

どのモジュールがよりリスクが高いかを判断するために、開発チームはリスク分析をおこないます。これは通常、モジュールに関連するさまざまなリスクを特定し、それらにビジネスと技術の異なるスコアを割り当てることで構成されます。リスクスコアを合計することで、テスト作業の優先順位を決めることができます。

どのモジュールのリスクが高いかを判断するために、チームは正規のリスク分析を実施します。これは通常、モジュールに関連するさまざまなリスクを特定し、それらにさまざまなビジネススコアと技術スコアを割り当てることで構成されます。リスクスコアを合計すると、テスト作業に優先順位を付けるのに役立ちます。

5．過去の経験を頼りましょう

以前のアプリケーションをテストすることで、膨大な経験とドメイン知識を蓄積できます。
その知識を利用して、新しいアプリケーションをテストする際に予想される脆弱性を推測することができます。アプリケーションによっては、フロントエンドの JavaScript のエラー、コンタクトフォームの自動タブリングに関連する問題、 Webページのデスクトップ版とモバイル版の間で発生する一般的なレンダリングの問題などをすぐに探し始めることができます。

新しいアプリケーションをテストすることになった場合、その製品に関するドキュメントや情報が少なくても迷うことはありません。上記の戦略は、誰もが集中的にテストを開始し、より多くの調査をおこなうのに役立ちます。

作者について：

Raj Subrameyerは、国際的な基調講演者、ライター、およびキャリアコーチであり、技術的なバックグラウンドを豊富に持っています。 彼のBlog（rajsubra.com/blog/）では、読者の生活に役立ち、インスピレーションを与えるニュース、リソースを投稿しています。

（この記事は、開発元 Ranorex 社 Blog 「5 Strategies for Testing a New Application」2020年5月7日の翻訳記事です。）