テスト–おそらくアプリケーション開発の最も過小評価されている部分

なぜ私はあなた自身の仕事をテストするためにあなたにお金を払わなければならないのですか？

これは、クライアントとテスト予算について話し合うときに私が長年にわたってよく聞いた質問です。 初心者には、それは公正な質問のように聞こえます。 ただし、ソフトウェア開発に携わる人なら誰でも、テストがどれほど複雑で時間のかかるものになるかを知っています。 実際、テストはソフトウェア開発プロジェクトの最も重要な部分の1つです。

大規模なeコマースプラットフォームは、数百万行のコード、ギガバイトのデータ、および多くの統合ポイントを備えた非常に複雑なものです。 相互にリンクされた可動部品は非常にたくさんあります。 チェーン内のリンクが非常に多いため、何かがうまくいかないことが非常に簡単です。 このアプリケーションは、多数のデスクトップおよびモバイルデバイスにまたがる多数のブラウザーを介して、何百万もの異なる方法で使用されます。 開発プロジェクトは少なくとも6か月続き、多くの異なる人々がそれに取り組んでいます。 テストできる領域とシナリオの数はほぼ無制限です。 何でもうまくいくのは不思議です！

テストはいくつかの異なる領域に分割できますが、テストの各領域を考慮することが重要です。 すべてのプロジェクトは少し異なります。 テストの多くを自分で行うことを好むクライアントもいれば、外部委託することを好むクライアントもいれば、開発者がすべてを行うことを期待しているクライアントもいます。 テストも固定されたエンティティではありません。 多くのテストを行うことができ、少し行うことができます。 テストすればするほど、プロジェクトのリスクを軽減できますが、時間がかかり、コストも高くなります。

ユニットテスト

単体テストは、コードの小さな「単体」をテストして、期待どおりに機能することを確認するものです。 たとえば、フォームを送信すると、入力した詳細がデータベーステーブルに保存されます。 これはスタンドアロンのテストであり、ユニットが期待どおりに機能することを具体的かつ唯一の方法で確認します。 真のテスト駆動開発方法論を使用して、開発者は実際にコードを作成する前に最初にテストを作成し、テストに合格した場合にのみコードが完了したと見なすことができるようにします。 実際には、単体テストは、コア機能が期待どおりに機能していることを確認するために、アプリケーションの一部の主要な領域でのみ使用されます。 単体テストは機能上の問題が発生する可能性を減らすことができますが、開発時間も長くする可能性があります。

スモークテスト

あなたはおそらくあなたの開発機関がスモークテストについてたくさん話すのを聞くでしょう。 スモークテストは、アプリケーション全体の主要なユーザージャーニーと機能をカバーするテストケースの実用的なサブセットです。 少なくとも、開発者はUATに何かを渡す前にスモークテストを実行することが期待されているはずです。

UIテスト

ユーザーインターフェイス（UI）のテストは、非常に複雑で時間のかかる作業になる可能性があります。 ウェブサイトへのアクセスに使用されるモバイル、タブレット、デスクトップデバイス、オペレーティングシステム、ブラウザの膨大な範囲は、すべての組み合わせを手動で包括的にテストすることはほとんど不可能であることを意味します。 カバーする必要のあるさまざまなバリエーションがあるため、UIテストは自動テストの最適な候補です。 自動テストツールは、スクリプト化されたWebサイトの旅をたどり、期待される結果が達成されているかどうかをテストできます。 また、各旅程を記録して、それぞれを再生できるようにすることもできます。 この方法は完璧ではありませんが、Webサイトが直面する可能性のある主要なUIの問題の数を大幅に減らすことができます。

Bug Findersなどの一部のサードパーティテストサービスは、クラウドソーシングサービスを提供します。このサービスでは、世界中の何百人ものフリーランスの人間のテスターがWebサイトのテストに使用され、問題が見つかったときに支払いが行われます。 このアプローチは、何百ものデバイス/プラットフォーム/ブラウザーの組み合わせにわたってアプリケーションをテストするための比較的費用効果の高い方法です。 テストサイクルで約200の問題が発生するのは正常です。 多くの場合、課題は問題を分類して優先順位を付け、最も重要な問題に対処することにリソースを集中させることです。 すべてのWebサイトには、解決される可能性が低い低レベルの問題のバックログが常にあります。

回帰試験

回帰テストは、進行中の開発の非常に重要な部分です。 これは、アプリケーションのある部分への変更が別の部分に問題を引き起こしたかどうかをテストするように設計されています。 たとえば、お問い合わせフォームの検証に使用されるJavaScript関数への変更は、チェックアウト内で使用されるフォームに影響を与える可能性があります。 eコマースプラットフォームは複雑な性質を持っているため、回帰の問題は珍しくありません。そのため、ユーザーのエクスペリエンスがこれらの問題によって悪影響を受けないようにするには、確実な回帰テスト計画を考案することが不可欠です。

UAT

ユーザー受け入れテスト（UAT）は、あらゆる開発プロジェクトの重要な部分であり、クライアントが稼働前にプラットフォームの完全なエンドツーエンドテストを実行することを含みます。 UATは、私が最も頻繁に過小評価しているプロセスです。 それはまた、タイムラインがタイトなときに最初に苦しむプロジェクトの一部でもあります。 ただし、これにより障害率が高くなる可能性があります。 新しいWebサイトを構築する場合は、少なくとも2か月のUATを計画することをお勧めします。 あなたのeコマースウェブサイトはあなたのコマースビジネスのほんの一部であり、検索、チェックアウト、注文管理、支払い、発送、カスタマーサービス、財務、そしてチェーンの他のすべての部分を含むエンドツーエンドのプロセスはテスト済み。

UATは、複数のシステム間の統合を具体的にテストするSIT（システム統合テスト）と混同またはマージされることがよくあります。 SITは、チェーンのすべての部分が正しく連携していることを確認するエンドツーエンドのテストの一部です。

優れたUATには、テストケースとテスト計画の作成が含まれます。 これらは通常、手動テスターが実行し、結果に応じてテストに合格または不合格になる一連のスクリプト（実行する一連のタスクであるスクリプト）の形式を取ります。 エンドツーエンドのUATテストプランに500を超えるテストケースが含まれることは珍しいことではありません。

UATのAは、それが非常に重要である理由の1つです。 UATプロセスの最後に、通常、申請を受理したと見なされます。したがって、申請が期待どおりに機能することを確認するために、申請を徹底的にテストすることが重要です。 これは、未発見のバグが保証対象外になることを意味するものではありませんが、期待どおりに機能しない機能がある場合は、UATで検出する必要があります。 それが非常に重要であるもう1つの理由は、問題が公開される前に問題を取り上げる最後のチャンスであるということです。 バグや問題は、ユーザーエクスペリエンスに悪影響を与える可能性があります。

UATはクライアントに代わって多くの努力を必要としますが、これはしばしば過小評価されています。 一部のクライアントは、外部のテスト機関を使用してUAT中にそれらをサポートします。これにより、クライアントがUATを効果的に実行するための人的資源を持たないプロジェクトのリスクを大幅に軽減できます。

セキュリティテスト

一部の小売業者がセキュリティテストを十分に真剣に受け止めていないことに、私は時々非常に驚いています。 小売業者がWebプラットフォームで最後に侵入テストを実行したのがいつかわからないことは珍しくありません。 これらは通常、サイバー攻撃にまだ攻撃されていない（または攻撃されたことをまだ知らない）ものです。 サイバー犯罪の頻度と高度さが増し続けている現在の状況、特にヨーロッパでGDPRが間近に迫っている現在、セキュリティテストはますます重要になっています。 すべてのeコマースWebプラットフォームは、少なくとも年に1回、理想的には1年に2回、専門のサードパーティによって浸透テストを行う必要があります。 また、Nessusなどの特殊なソフトウェアを定期的に使用して、アプリケーションの脆弱性をスキャンすることをお勧めします。 Envoyでは、アプリケーションの脆弱性が非常に迅速に検出されるように、クライアントのWebプラットフォームを毎週スキャンする傾向があります。 少なくとも、本番環境にリリースする前に、アプリケーションのセキュリティスキャンを実行する必要があります。 新しいアプリケーションの脆弱性が導入された次の侵入テストまで、6か月待つのはよくありません。

性能試験

パフォーマンステストは通常​​、Webサイトが処理できるトラフィック、ページリクエスト、同時ユーザー、注文量を判断するために使用されます。 正確にテストするには、実際のユーザーの動作を模倣する必要があり、ご存知のように、実際のユーザーはさまざまなことを行うため、想像するよりも難しいプロセスです。 あなたができる最善のことは、検索、バスケットへの追加、チェックアウトなどの主要なユーザージャーニーを模倣することです。 ステージング環境ではなく、本番環境で負荷テストを実行するのが理想的です。これにより、より正確な状況が得られますが、テスト中のある時点でプラットフォームがオフラインになる可能性もあります。

ほとんどの小売業者は、通常、ブラックフライデーやクリスマスなどのピーク取引期間の前に、年に1回負荷テストを実行する傾向があります。 これが引き起こす可能性のある問題は、前回の年次テスト以降、アプリケーションに多数の変更が加えられた可能性があり、その一部がパフォーマンスに段階的な影響を与えた可能性があることです。 年次負荷テストで前年と比較してパフォーマンスの低下が示された場合、過去1年間のどの変更がパフォーマンスの低下に寄与したかを判断するのは非常に困難です。 これはまた、ピーク取引が始まる前にパフォーマンスの問題を解決するのに十分な時間を与えないかもしれません。

これに対抗するために、新しいコードをリリースする前に、パフォーマンスのベンチマークを実行することをお勧めします。 前回のリリースと比較してパフォーマンスが向上したか低下したかを判断することを目的として、各テストが同じ環境で実行される限り、これらを実稼働環境で実行する必要はありません。 このアプローチにより、開発チームはパフォーマンスの向上または低下がどこから来ているのかを理解できます。 もちろん、これには時間がかかるため、開発時間とコストが増加します

上記のリストはすべてを網羅しているわけではありませんが、ソフトウェア開発内のテストの範囲は非常に大きく複雑になる可能性があることがわかります。 各タイプのテストには時間と労力がかかり、追加料金なしですべてが標準として行われると想定するべきではありません。 テストに重点を置いている企業は、プロジェクト時間の最大40％をテストに割り当てますが、これは非常に驚くべき量です。 優れたテストは、プロジェクトのリスクを軽減し、長期的に見れば、バグの減少、パフォーマンスの向上、および顧客の全体的なエクスペリエンスの向上につながるため、利益を得ることができます。