テスターは作業を自動化する必要がありますか?


9

テストプロセスをセットアップしようとしています。テスト担当者が自動回帰テストを開発する必要があるのか​​、それとも開発者がそれを行う必要があるのか​​と思います。

そして、他のタイプの自動テストはどうですか?テスターはそれらを開発する必要がありますか?


それらを「テスト中の開発者」と呼び始めるだけで、あいまいさが解消されます。
エドワードストレンジ

@クレイジーしかし、2つの開発者チームがいる方がコストは高くありませんか?
Jader Dias、2011

5
何よりも高価ですか?テストが不十分な製品を販売していますか?開発者が製品ではなくテストを作成しているため、開発プロセスのボトルネックになっていますか?
エドワードストレンジ

回答:


12

テスターは自動テストを開発するべきだと私は言います-彼らはコードへの「外側の目」のアプローチを持ち、あなたが考えていないバグを発見するでしょう(あるいは、それは単に「かもしれませんか?」) 。

加えて、機能要件に対する彼らの理解は、開発者の理解よりも高いレベルかもしれません-したがって、プログラマーのハードコアな低レベルの知識の中間に位置しますが、BAのそれよりも高いレベルではありません。


しかし、彼らは開発者にそのテストケースを書くように頼むことができないのではないでしょうか?
Dias

1
上で述べた理由により、開発者は内部実装についてはるかによく知っており、外部からのソフトウェアとは異なる方法でソフトウェアにアプローチします。
ジェームスラブ

テストケースの実装が人によってどのように異なるかはわかりません。
Jader Dias、2011

5
@Jader、元のコードを書いた人とは別の人に自動テストを書いてもらいたいと思っています。それ以外の場合、テストはコードが記述されたとおりに機能するようにバイアスされます。
Marcie

3
過去数週間、私は開発者に彼のコードのフィクスチャを書くのを手伝ってくれました。彼は非常に優れた開発者ですが、定期的に詳細なカバレッジについて考えていないという理由だけで、コードのカバレッジのニュアンスを見逃しています。開発者がテストを支援する場合は、テスターに​​作業をレビューしてもらいます。
Ethel Evans、

11

自動化できる場合は、自動化してください。

自動化できないものを見つけるためにテスターを解放します。そして、彼らが新しいバグを見つけたら、それを自動化して自動テストに追加できる場合は、それを追加します。


しかし、なぜ彼らは開発者だけでなくなぜそうすべきなのでしょうか?
Jader Dias、2011

@JaderDias、前述のとおり、テスターはテストしようとしているコードについて先入観を持っていてはいけません
CaffGeek

3

私の意見では、開発者とテスターはさまざまなタイプのテストに責任があります。

開発者は、ロジックを記述しながら、単体テストと統合テストも記述する必要があります。これにより、開発者はこれまでに書いたものが意図したとおりに機能することを確認できます。さらに、これらのテストは、開発者が将来の変更を行うときに実行できるようになります。ロジックが完了すると、開発者は、書かれた内容が仕様を理解し、テスターに​​渡されるように機能することを保証できます。

この時点からのテスターは、ビジネスロジックが意図したとおりに機能することを確認するシステム全体のテストを作成する責任があります。

多くの場合、開発者はコードにあまりにも結びついているので、テスターは開発者のテストのクリーンアップを支援できますが、その逆はできません。


最後の文に興味があります-開発者が機能テストに貢献できるとは思いませんか?テスターがテスト構造の概要を示し、テストケースを特定し、開発者が実装のみを支援する場合はどうなりますか?
Miss Cellanie

1
自分で開発者であり、独自のテストを作成できるテスターを想像していると思います。彼らの仕事は、要件を確認し、ユーザーに話しかけてテストケースを特定し、ケースを作成することです。これにより、ロジック開発者はロジックを記述したときに、ロジックに自由に近づけることができます。また、テスターがロジックを「所有」することから十分に離れているため、客観的かつ反省せずにそれを破ることができます。
テイラー価格

2

私の経験では、テスターがテストケースを自動的にセットアップして実行する方法は、実際には開発者が行う方法とは異なります。テスト担当者は、テストケースから最大限の情報を引き出す方法、テストを迅速に実行する方法、テストを保守しやすい状態に保つ方法などについてさらに検討することになります。最も重要なのは、テスト担当者が開発者が見逃すテストカバレッジの微妙な違いを目にすることです。

テスト開発リソースが少ない場合、開発者は手助けできますが、テスターは自分の作業を注意深く検討する必要があります。開発者は実際のテストケースを作成する前にフィクスチャとテストツールで作業する必要があり、開発者は自分のコードのテストケースを作成しないでください。開発者にテストを手伝ってもらうことには特典があります-開発者を製品の他の部分に公開し、テストは開発者がより良い開発者になるのを助けることができます。ただし、ジュニア開発者の作業がコードレビューなしでは絶対に進まないのと同様に、開発者のQA作業では、テストの経験が豊富な人からQAレビューを取得する必要があります。

追加用に編集:私は5年の経験を持つSDETです。私はそれぞれ10年以上の経験を持つ素晴らしい開発者と仕事をしており、最近彼らと協力してテストのボトルネックを乗り越えています。


0

私が実際に見てみたいことの1つは、テストスクリプトを使用して進行状況を効果的に記録し、そのスクリプトを将来自動的に実行できるようにする、テスター向けの堅牢な自動化ツールです。特に、これにより、テスターがすべてのスクリプトを手動で実行しなくても、同じスクリプトを異なるオペレーティングシステムバージョンで実行できるようになる場合。

残念ながら、私が取り組んでいる製品については確かに、市場に出回っているツールのどれもがうまく機能しません。しかし、これを念頭に置き、あなたがしていることにうまくいく何かがある場合に備えて、市場で何が利用可能かを検討することは価値があります。


Visual Studio 2010(PremiumまたはUltimate、どちらを覚えていないか)には、UIテストを自動化する画面アクションを記録するものがあります。私は、Andrew Woodward MVPがこれをデモしているときに、信じられないほどのUI Testing SharePointのショーを行いました。
James Love

録音と再生は、評判がかなり悪い。それはかなり壊れやすく、維持するのが難しい傾向があります。はい、簡単で汚い「4つの異なるデータセンターでこれを実行する必要があるので、将来の使用のために保持したくない」というのは問題ありませんが、何度も繰り返してしまうため、維持するのは大変です。1つの小さな要素が変更され、突然100のテストを更新する必要があります。痛い。また、手動テストに代わるものではありません。手動テストは、人間が明示的にチェックしなかった他のすべてのものに気づくという前提で設計される傾向があります。
testerab 2011

かなり甘いのは、ポインタを動かしてマウスをクリックするよりも少し低いレベルに移動して、実際にクリックが発生した場所ではなく、どのボタンがクリックされたかを記録できるものです。そうすれば、このタイプのテストの耐障害性と実用性が高まります。たとえば、9つの異なるバージョンのウィンドウですべてのスクリプトを実行する必要がある場合、すべてのスクリプトを手動で実行しなければならないのは悪夢です。
glenatron、2011

一部のツールで、場所でなくIDでボタンを識別すること完全に可能です。このようにして行われた録音と再生のスクリプトは、残念ながら維持するのが大変です。繰り返しの問題は解決しません。実際にスクリプトを保持したり、12個以上のスクリプトを作成したりする場合は、テストの自動化を慎重に設計する必要がなくなることはないと思います。Auto-Itと共にRobot Frameworkのようなキーワード駆動の何かを使用することを考えましたか?
testerab 2011

0

ここで本当に重要な重要な違いの1つはこれです。テスターは単にチェックするのですか、それともテストするのですか?

Michael Boltonによるこのブログ投稿は、それをより良く説明していますが、本質的には、彼らは単に動作を確認することを望んでいるのか、それともシステムの問題を見つけようとしているのか?

アジャイルテストの象限を検討することも有用だと思います(ブライアンマリックはこれらについて最初に説明しましたが、リサクリスピンとジャネットグレゴリーの「アジャイルテスト」の本でそれらに出会いました。アジャイル開発方法論に従っていない場合でも、製品を批評するテストとチームをサポートするテストの区別は、自動化を検討し、誰が何を、なぜ行うかについての計画を立てようとするときに、本当に価値があります。

たとえば、開発者が作成したユニットチェックは変更検出器として機能し、定期的に再実行するときに回帰を早期に検出できるようにします。これらはチームをサポートするテストです。自動化されたシステムレベルの回帰チェック。定期的かつ迅速に再実行できるため、回帰を早期にキャッチしてチームをサポートし、開発者によるユニットテストを補完します。これにより、テスターが製品を批評するテスト(探索的テストなど)を行う時間を解放できます。または、製品のストレステストに自動チェックの一部を適用することもできます。

私がリンクしたLisa Crispinのプレゼンテーションについて私が本当に気に入っているもう1つの点は、自動化は手動テストのサポートにも使用できることを示しています-テストデータの作成、今日の焦点にしたいポイントにシナリオを取得するための自動化、例。

これらの2つの記事を検討すると、実行したいテストの種類を分析し、自動化に適している可能性のあるものを簡単に選択できるようになり、自動化のどのビットがテスターに​​よる実行に適しているか、および開発者による。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.