ただし、自動テストは、プログラムが開発者の意図した方法で使用されるという前提に基づいています。 自動化されたテストのみに依存している場合、コードにエラーがすぐに表示されますが、同時にアプリケーションインターフェイスの品質についての見当がつかなくなります。
手動テストに関しては、そのようなプロセスは従業員を使い果たすため、あまり注意が払われず、特別なメンタリティを持つスペシャリストのみがパフォーマーの役割に適しています。 ただし、「手動」テストは自動テストよりも決して劣っていません。 ここでのポイントは、アプローチの適用領域が異なるため、今日は各ソリューションの長所と短所を検討します。
/写真verkeorg CC
自動テスト
Project A Venturesの品質管理エンジニアであるSarah Fittje氏によると 、テストに多数の反復タスクが含まれる場合、自動化するのは理にかなっています。 典型的な例は回帰テストであり、これにより重大なバグを検出できるため、最終製品をリリースする前に定期的に完全に実施することが重要です（ちなみに、興味がある場合は、SarahのQAスペシャリスト向けのガイドをご覧ください ）。
同時に、自動テストを設定することで多くのお金を節約できるとは考えないでください。 書かれたスクリプトの作成と維持には、すべてのテスターが持っているわけではない特定のQAスキルが必要です。したがって、会社はスペシャリストにもっとお金を払わなければなりません（ただし、テスターのスタッフは削減できます ）。
また、優れた機能を備えた大規模なアプリケーションに自動テストを実装することは非常に困難です。そのため、全体像のビジョンを失うリスクがあり、すべての機能をテストでカバーすることはできません。 ただし、プロジェクトの最初の日から自動テストシステムをセットアップすると、品質管理サイクルを高速化し、アプリケーションの一貫したチェックを確立する機会が得られます。
ただし、自動化されたテストでは、インターフェイスの外観の欠陥や製品とのユーザーインタラクションの品質を判断することはできないことを理解することが重要です。 自動化を適用するための指示を考慮してください。
GUIテスト
このタイプのテストは、アプリケーションのフロントエンド部分をチェックすることを目的としています。 自動化なしでは、ユーザーとWebブラウザー、モバイルデバイス、およびその他のシステムのインターフェイスとのすべての可能な組み合わせを考慮することは非常に困難です（上記のように、このようなテストではUXを評価できないことを理解することが重要です）。
回帰テスト
開発者はこのタイプのテストを使用して、アプリケーション機能の改善に起因するバグを見つけます。 頻繁な更新の圧力の下で、開発者は途方もないペースで作業する必要があり、時には妥協をする必要があります。これは、バグがソフトウェアコードに「スリップ」することを確実に活用します。 各リリースの欠陥を手動で追跡することは非常に問題です。
機能テスト
これは、機能要件が満たされていること、つまり、アプリケーションが期待どおりに実行されているかどうかを検証するためのテストです。 目的の機能がどの程度正確に実装されているかが判断され、標準に準拠するための分析が実行され、ソリューションのセキュリティが評価されます。 機能テストの繰り返しは、アプリケーションにわずかな変更を加えた場合でも多くの時間がかかります。そのため、すべてのアクションを手で実行するのは採算が取れない場合があります。
手動テスト
自動テストは高品質の達成に役立ちますが、現時点では手動テストに完全に取って代わるものではありません。 これは、ユーザーが自動テストで考慮するのが難しい完全に予期しないアクションを実行できるという事実によるものです。
ユーザーはアプリケーションに慣れている間、ミスをしたり、必要なステップを完了したり、予期しない値を入力したりすることができます。 ユーザーは製品についてあまり知りませんが、最終的にそれを使用するのはユーザーです。 したがって、顧客の承認は、インターフェース品質の最も価値のある指標です。
人の行動特性と直感がプログラムの動作を評価する上で重要な役割を果たし始めると、手動テストに注意を払う価値があります-ユーザーの代わりに自分を置くことがより重要です。 テスターは、機能をチェックするプロセスで創造性を発揮できます。予期しないアイデアを思いつき、異常なユースケースを模倣します。これにより、自動テストでは「気付かない」重大なエラーを発見できます。
いくつかのユーザーテストケース：
ユーザビリティテスト
このテストは、ユーザーの観点からアプリケーションの使いやすさを検証するのに役立ちます。 コンピューターはそのような漠然としたタスクをその目標で解決することはできません-マシンには明確な言葉遣いが必要です。
アドホックテスト
プログラムの1つの側面をテストすることを目的とした1回限りのテスト。 このタイプのテストには正式に定義されたルールはありません;即興です-テスターは利用可能なツールを使用してバグを検索できます。 実際、アドホックテストは、起こりうるエラーを「推測」する試みです。
複合オプション
前述したように、テストの種類によって適用範囲が異なります。 自動テストは手動テストに置き換わるものではありませんが、大規模で統一された一連のアクションを実行するときに作業時間を節約するために使用できます。 手動テストには長い時間がかかりますが、高品質の製品を実現したい場合は手動でテストする必要があります。 現時点では、これらのアプローチの組み合わせのみが、製品の機能と使いやすさの点で高い標準を提供できます。
そのようなアプローチの例として、Sarah Fitzhi は 、テストプロジェクトでの新機能の実装が成功した後、QAチームが自動回帰テストを開始したとき、natueオンラインストアのテストプロセスを挙げています。
「自動テストの実行中に、回帰テストの中間結果を考慮して、新しい機能を同時に手動でテストしました」とSarah氏は言います。 「手動または自動テスト中にバグが検出された場合、それらは修正され、テストが再開されました。」 すべてがうまくいった場合、サラのチームは最終バージョンの発売前にテストを繰り返しました。
別の例は、TestGrid.ioのエンジニアであるSteven Allenです。 彼は 、iOSでは本格的な自動テストが長い間利用できなかったと言います。 数年前、Appleは自動化ツールをリリースし始めましたが、まだ完璧ではありません。 したがって、自動化ツールのみを使用しても機能しません。手動テストに頼らなければなりません。
開発者は、より効率的に作業を行うためにテストを自動化しますが、アプリケーションを使用するためのすべての可能なオプションをスクリプトで記述し、すべてのエラーを考慮することはできません。 たとえば、ユーザー名を入力するための追加フィールドがログイン画面に表示されるが、他のすべてが正常に機能する場合など、見落としやすいものがあります。
Lucid Softwareの品質保証スペシャリストであるJoseph Millar氏は、次のように述べています。 -開発者がスクリプトに間違いを犯した場合、大量のエラーを見落とすリスクがありますが、手動テスト中にこれらの欠点が検出される可能性があります。 したがって、アプリケーションを開発するときには両方の方法を使用することが非常に重要です。 1つは時間を節約するため、もう1つは「研削」のためです。
PSその他の資料： クラウド、ネットワークテクノロジー、サービスの開発に関するダイジェスト 。