テストプロセスをセットアップしようとしています。テスト担当者が自動回帰テストを開発する必要があるのか、それとも開発者がそれを行う必要があるのかと思います。
そして、他のタイプの自動テストはどうですか?テスターはそれらを開発する必要がありますか?
テストプロセスをセットアップしようとしています。テスト担当者が自動回帰テストを開発する必要があるのか、それとも開発者がそれを行う必要があるのかと思います。
そして、他のタイプの自動テストはどうですか?テスターはそれらを開発する必要がありますか?
回答:
テスターは自動テストを開発するべきだと私は言います-彼らはコードへの「外側の目」のアプローチを持ち、あなたが考えていないバグを発見するでしょう(あるいは、それは単に「かもしれませんか?」) 。
加えて、機能要件に対する彼らの理解は、開発者の理解よりも高いレベルかもしれません-したがって、プログラマーのハードコアな低レベルの知識の中間に位置しますが、BAのそれよりも高いレベルではありません。
自動化できる場合は、自動化してください。
自動化できないものを見つけるためにテスターを解放します。そして、彼らが新しいバグを見つけたら、それを自動化して自動テストに追加できる場合は、それを追加します。
私の意見では、開発者とテスターはさまざまなタイプのテストに責任があります。
開発者は、ロジックを記述しながら、単体テストと統合テストも記述する必要があります。これにより、開発者はこれまでに書いたものが意図したとおりに機能することを確認できます。さらに、これらのテストは、開発者が将来の変更を行うときに実行できるようになります。ロジックが完了すると、開発者は、書かれた内容が仕様を理解し、テスターに渡されるように機能することを保証できます。
この時点からのテスターは、ビジネスロジックが意図したとおりに機能することを確認するシステム全体のテストを作成する責任があります。
多くの場合、開発者はコードにあまりにも結びついているので、テスターは開発者のテストのクリーンアップを支援できますが、その逆はできません。
私の経験では、テスターがテストケースを自動的にセットアップして実行する方法は、実際には開発者が行う方法とは異なります。テスト担当者は、テストケースから最大限の情報を引き出す方法、テストを迅速に実行する方法、テストを保守しやすい状態に保つ方法などについてさらに検討することになります。最も重要なのは、テスト担当者が開発者が見逃すテストカバレッジの微妙な違いを目にすることです。
テスト開発リソースが少ない場合、開発者は手助けできますが、テスターは自分の作業を注意深く検討する必要があります。開発者は実際のテストケースを作成する前にフィクスチャとテストツールで作業する必要があり、開発者は自分のコードのテストケースを作成しないでください。開発者にテストを手伝ってもらうことには特典があります-開発者を製品の他の部分に公開し、テストは開発者がより良い開発者になるのを助けることができます。ただし、ジュニア開発者の作業がコードレビューなしでは絶対に進まないのと同様に、開発者のQA作業では、テストの経験が豊富な人からQAレビューを取得する必要があります。
追加用に編集:私は5年の経験を持つSDETです。私はそれぞれ10年以上の経験を持つ素晴らしい開発者と仕事をしており、最近彼らと協力してテストのボトルネックを乗り越えています。
私が実際に見てみたいことの1つは、テストスクリプトを使用して進行状況を効果的に記録し、そのスクリプトを将来自動的に実行できるようにする、テスター向けの堅牢な自動化ツールです。特に、これにより、テスターがすべてのスクリプトを手動で実行しなくても、同じスクリプトを異なるオペレーティングシステムバージョンで実行できるようになる場合。
残念ながら、私が取り組んでいる製品については確かに、市場に出回っているツールのどれもがうまく機能しません。しかし、これを念頭に置き、あなたがしていることにうまくいく何かがある場合に備えて、市場で何が利用可能かを検討することは価値があります。
ここで本当に重要な重要な違いの1つはこれです。テスターは単にチェックするのですか、それともテストするのですか?
Michael Boltonによるこのブログ投稿は、それをより良く説明していますが、本質的には、彼らは単に動作を確認することを望んでいるのか、それともシステムの問題を見つけようとしているのか?
アジャイルテストの象限を検討することも有用だと思います(ブライアンマリックはこれらについて最初に説明しましたが、リサクリスピンとジャネットグレゴリーの「アジャイルテスト」の本でそれらに出会いました。アジャイル開発方法論に従っていない場合でも、製品を批評するテストとチームをサポートするテストの区別は、自動化を検討し、誰が何を、なぜ行うかについての計画を立てようとするときに、本当に価値があります。
たとえば、開発者が作成したユニットチェックは変更検出器として機能し、定期的に再実行するときに回帰を早期に検出できるようにします。これらはチームをサポートするテストです。自動化されたシステムレベルの回帰チェック。定期的かつ迅速に再実行できるため、回帰を早期にキャッチしてチームをサポートし、開発者によるユニットテストを補完します。これにより、テスターが製品を批評するテスト(探索的テストなど)を行う時間を解放できます。または、製品のストレステストに自動チェックの一部を適用することもできます。
私がリンクしたLisa Crispinのプレゼンテーションについて私が本当に気に入っているもう1つの点は、自動化は手動テストのサポートにも使用できることを示しています-テストデータの作成、今日の焦点にしたいポイントにシナリオを取得するための自動化、例。
これらの2つの記事を検討すると、実行したいテストの種類を分析し、自動化に適している可能性のあるものを簡単に選択できるようになり、自動化のどのビットがテスターによる実行に適しているか、および開発者による。