私たちが使用したすべての段階ですぐに言及する価値があると思います：
- 約50％のカバレッジを持つ単体テスト
- 単体テストの開始（およびその後の統合）、自動アセンブリおよびリリースのリリースによる継続的統合
- ScrumbanXPという名前のアジャイルの交差点
テストの自動化について話すときはいつでも、外部リソース（DB、ファイルシステム、サービスなど）に接続してインターフェイスをテストすることについて話します。
ステップ1.テスターはありません。
私が参加した最初の主要プロジェクトにはテスターはいませんでした。 バトルサーバーにアップロードする前に、開発者自身がシステムの主要部分をチェックしました。 このアプローチでは、バグがしばしばクロールアウトしました。
プログラマーがコードを愛し、書いたばかりの機能をテストすることに非常に熱心であることは誰にとっても明らかでした。 以前に記述された機能のテストについて、また他の開発者によるテストについて話す必要はありません。 プログラマー自身は、システムを操作するためのあらゆる種類のシナリオを再実行せず、すべてのページのすべてのタブに移動しません。
実際、このプロジェクトでは、同様のアプローチを行う余裕がありました。 ユーザーは手の届くところに座っていました。 それは会社の内部自動化のためのプロジェクトでした。 システムを操作したオペレーターとマネージャーが私たちのところに来て、機能について話し合い、エラーを指摘することができました。 したがって、迅速な修正を行い、修正されたバージョンを記入することができます。
エラーレポートは、壁の後ろで叫んでいた。 バグによる損失はわずかであり、誰もが状況に満足していました。
私が実施した調査から判断すると、テストプロセスをどのように調整しますか？ ほとんどの場合、このアプローチをテストする余裕があります。
ステップ2.テスト自動化を開始する
壁の外の人だけでなく、サードパーティのユーザーも使用する新しいシステムの作成を開始しました。 悪いリリースから私たちを守るテスターを雇う必要がありました。
テスターを雇いました。そもそも、単体テストの実行のように、テストを自動化することを決めました。 自動化は、テスターが絶えず同じスクリプトを繰り返さないようにするためのものでした。
アイデアはシンプルで、誰にとっても問題の解決策のように思えました。 CIが夜間に一連の統合テストを開始することを望んでいました。 午前中に到着します。テストがすべて緑であれば、リリースできます。 赤いテストがある場合、それを修正し、テストスイート全体を再度実行するなど。 すべてのテストが緑色になるまで。
テストを記録するために、さまざまなオプションを試し、 Seleniumで解決しました。 最初に、テストはSelenium API自体で作成されました。 時間が経つにつれて、低レベルAPIのラッパーが作成され始め、このラッパーはテスト用の一種のDSLに変わりました。
テスターがテスト用の製品を選別し、テスト自動化プロセスを設定している間、開発は停止しませんでした。 1-2回の反復ごとに新しいバージョンをリリースする必要がありました。 テスターは常にプログラマーを追いかける段階にありました。 バグを恐れることなく静かに新しいバージョンをリリースできるように、彼の目標は100％スクリプト化されました。
ステップ3.グリーンテストのために戦う
テストの自動化に関する問題は、私たちにとって予想外のものでした。 実際、私たちは彼らの準備ができていませんでした。
長いフィードバック
システムが大きくなるほど、作成するテストが増えます。 テストは本当にゆっくりと動き始めました。 彼らが14時間で合格した場合-それは信じられないほどの運でした。 時間が経つにつれて、テストは最終日の18.00から当日の9.00の間に収まらなくなりました。 テストからフィードバックを受け取りませんでしたが、ダウンタイムが発生しました。 また、ライトがオフになったか、サーバーが再起動したため、時間のロスが大きすぎました。
グリーンテスト？ いいえ、見たことがない
グリーンテストはかつてないほどです。 確かに、彼らはかつて、12月30日に始動し、100％のグリーンとして結果を出しました。 多分それは新年のための彼らへの贈り物だった。 常にこれ以上はありませんでした。
なぜ彼らは緑ではなかったのですか？ これにはいくつかの理由がありました。
- 脆弱なテスト -インターフェースは常に変化しており、テストはこれらの変化に追いついていませんでした。
- 柔軟なテスト -システムアーキテクチャは常に改善されており、コードの柔軟性を高める一般化されたソリューションが見つかります。 また、テストコード（説明）をリファクタリングして要約し、保守しやすくする必要があります。 たとえば、小さな変更を加えた多くの典型的なワークフローが必要です。 開発者
十分な柔軟性を備えたアーキテクチャを考え出す
これらのワークフローをすばやく実装します。 したがって、テストアーキテクチャは
同じ方法で改善し、アーキテクチャの改善に追いつく
テスターの不十分な資格のために行われなかったコード。 から
テストアーキテクチャはコードアーキテクチャの背後で「ペースを保てない」ため、プログラマ
機能をより速く実装し、ラグテスターが蓄積する - 軽微なバグ -テストは常に重大なバグを見つけるとは限らず、時々私たちが知っていた軽微なバグのために落ちましたが、それらを修正することは優先事項ではありませんでした。 これを行うために、彼らはTeamCity用のプラグインを特別に作成し、テストが失敗したかどうかを見ることができました。 軽微なバグがある一連の落下テストにより、テストがグリーンになりませんでした。
- 判読できないテスト -たとえば、大規模な複雑なシナリオがあります
結果をテストするアクションの数。 したがって、
テストをいくつかの小さなテストに分割することはできません（中間結果はチェックされませんが、
最後に、いくつかのアクションの結果として達成されます）。 そのようなテストのコード
理解しやすく読みやすいように最適化する必要がありますが、これもそうではありません
達成することができた。 - 長いシナリオ -長いシナリオを実装するには、たとえば10〜20ステップを実行する必要があります。 中間結果は重要ではなく、最終結果のみが重要です。 長いシナリオでは、いくつかの問題が発生します。
- 2番目のステップでエラーが発生した場合、スクリプト全体がエラーと見なされます。 この場合、赤いテストはテストしたもののエラーではなく、最初のどこかにあるステップのエラーを意味します（ログインインターフェイスを変更する可能性があります）。
- 長いシナリオでは、手順が頻繁に繰り返され、重複が発生します。
- 長いシナリオを中央から開始することはできません。これには、N番目のステップにあるシステムの特別な状態を準備する必要があるためです。 これにより、テスト構造に脆弱性が追加されます。
テストが不安定であり、テストを更新する時間がなかったため、次のことを行う必要がありました。
- 開発者を切り替えて、テスターがSpecFlowに切り替えられるようにします。そうしないと、テスターはC＃コードで大量のテストを保持できませんでした。 当時の検査部門の長は、 キュウリの受入検査のトピックに関するレポートを作成していました
- 70％の時間、テスターは現在のシステム機能セットに一致するように自動テストを書き直しました。 つまり テストそのもののための仕事でした。
- 上記の結果として、テスターも雇いました。
目標は達成されましたか？
私たちには目標がありました-環境に優しい統合テストを見て、バグを恐れずにバトルサーバーにアップロードすることです。 実際、私たちはこの目標を達成していません。
その結果、実際の状態でのシステムの最初の起動は、自動テストが多くのバグを見逃していることを示しました。 システムを手動で突いたときにこれらのバグが見つかりました。 10分間の手動テストで、最も重大なバグが発見されました。
私は自発的にすべての統合テストの作業をキャンセルすることを決定し、Google Docsでテストスクリプトを記述する手動テストを導入しました。 その後、主要なバグが終了し、テストがカンバンストリームに完全に統合されました。
現在の状態
現在のところ、私の会社では、テスターチームと一緒に、手動テスト+ Googleドキュメントでのテストスクリプトの作成というアプローチを採用しています。 テスターは、記入する前にすべてのスクリプトに手動で穴を開けます。
テストシナリオはプロジェクトアーティファクトの一部と見なされ、ソースコードと共に顧客に提供されます。
実際、優れた結果が得られます。 リリースでは、マイナーなバグ、または実際に機能するバグのみがあります。
テストの自動化に対して？
テスト自動化へのアプローチの適用可能性の限界を理解する必要があります。 たとえば、稼働中のサーバーで404エラーと500エラーをキャッチするバグを作成した場合、人件費は正当化されます。
時々変化する単純なアプリケーションがある場合、そのための統合テストのセットを作成することは理にかなっていますが、これを手動テストと組み合わせます。
手動テストを自動テストに100％置き換えたい場合は、上記の問題を回避する方法を検討してください。 おそらく最初に手動テストを使用し、次にこれらのテストをサポートする必要なく自動化が最大の効果をもたらす部品を自動化する必要がありました。
あなたの会社でテストがどのように発展したかを聞いてうれしいです。
参照資料
テスターがいない上位5つの（間違った）理由 、ジョエル・スポルスキー
ジョエルテスト：より良いコードへの12のステップ 、ジョエルスポルスキー
猿対ロボット。 パートI（TestLabs09） 、Maxim Dorofeev
猿対ロボット。 パートII（TestLabs09） 、マキシムドロフェエフ
猿対ロボット。 パートIII（TestLabs09） 、マキシムドロフェエフ
アジャイルチーム作業：開発+テスト