8

私たちにはたくさんの開発者がいますが、QA 担当者はほんの数人です。開発者は、自動化されたテストを作成することで、開発プロセス全体を通して QA に関与するようになりましたが、QA の実践はほとんど手作業です。

私が望むのは、私たちの開発手法が BDD と TDD であり、堅牢なテスト スイートを成長させることです。問題は、このようなテスト スイートを構築する際に、テストに対して何を信頼できるか、何を手動でテストし続ける必要があるかをどのように判断できるかということです。

4

6 に答える 6

7

最初の境界線は、手動でテストするのが実質的に簡単なものと、自動化された方法でテストするの が実質的に簡単なものは何ですか？

もちろん、それらは非常に簡単に理解でき、おそらく真ん中に大きなガックの山が残るでしょう。

私の次のふるいは次のようになります-一部のプロジェクトでは簡単になっていますが、ユーザーインターフェイスの問題は自動化された方法でテストするのが最も難しいものの1つです。ですから、しばらくの間それらをQA担当者に任せ、自動テストをバックエンドコードの小さなユニットに集中させ、アプリケーションの複数のユニットや複数の層にまたがるより大きな統合テストに徐々に拡張していきます。

于 2010-04-14T16:50:21.260 に答える
6

私のアドバイスは、自動化できるものはすべて自動化することです。「これでいいの？」という質問に答えるなど、得意なことは人間に任せましょう。または「これは使えますか？」。それ以外はすべて自動化します。

于 2010-04-14T16:54:18.200 に答える
5

Test Automation Pyramidに関する Mike Cohn の記事をご覧ください。具体的には、UI のどの部分をそのようにテストする必要があるかを検討してください。たとえば、まれなケースは、多くの場合、サービス層を通じてより適切にテストされます。

于 2010-04-14T21:26:29.233 に答える
4

自動テストとは異なり、手動テストでは次のことができます。

  • GUI テスト
  • ユーザビリティテスト
  • 探索的テスト
  • テストの実行時にバリエーションを使用する
  • 回帰バグではなく、新しいバグを見つける
  • 人間の目はすべての問題に気付くことができます。自動テストで確認できることはごくわずかです。

自動テストでは、手動テストとは異なり、次のことができます。

  • ストレス/負荷テスト
  • 自動テストスイートを使用してパフォーマンスをテストすることもできます
  • 構成テスト (IMHO これが最もメリットがあります)。記述が完了すると、異なる環境で異なる設定を使用して同じテストを実行し、考えもしなかった隠れた依存関係を明らかにすることができます。
  • 何千もの入力データに対して同じテストを実行できます。手動テストの場合、さまざまな手法を使用して最小限の入力データ セットを選択する必要があります。

また、自動テストで間違いを犯すことは、手動テスト中に間違いを犯すよりも簡単であり、可能性が高くなります。最も価値のある機能を自動化することをお勧めしますが、重要なリリースの前に手動でテスト (少なくとも健全性) を実行することをお勧めします。

于 2010-06-12T17:01:10.333 に答える
4

UI 要素の手動テストを推奨する Jim に +1。UI 自動化ツールを使用してテストを作成するのは比較的簡単ですが、テストのメンテナンスを最小限に抑えるのに十分な堅牢で包括的なテスト フレームワークを設計するには、十分な検討と予測が必要です。

優先順位を付ける必要がある場合は、追加のテストで最もメリットが得られる非 UI 領域を特定するために私が使用したいくつかの手法を以下に示します。

  1. 以前のリリースのバグ レポート、特に顧客から報告されたバグ (アクセスできる場合) を参照してください。多くの場合、いくつかの特定の機能領域がバグの大部分を占めています。
  2. 既存の自動テストを実行するときにコード カバレッジ ツールを使用し、カバレッジがほとんどまたはまったくない領域に注意してください。
于 2010-04-14T19:03:03.773 に答える
1

新しい機能を手動でテストして、要件を満たしていることを確認してから、回帰のために自動化スイートに追加しても問題はありません。（それとも伝統的すぎる？）

于 2010-04-27T20:31:06.233 に答える