Geekly Articles each Day

テスト：手動または自動？

3年間の作業といくつかの大規模システムの作成をカバーするテストプロセスを整理した経験を共有したいと思います。 この説明は、ソフトウェア開発の他の側面と交差することなく、「手動」テストの自動化にのみ影響します。

私たちが使用したすべての段階ですぐに言及する価値があると思います：


テストの自動化について話すときはいつでも、外部リソース（DB、ファイルシステム、サービスなど）に接続してインターフェイスをテストすることについて話します。



ステップ1.テスターはありません。



私が参加した最初の主要プロジェクトにはテスターはいませんでした。 バトルサーバーにアップロードする前に、開発者自身がシステムの主要部分をチェックしました。 このアプローチでは、バグがしばしばクロールアウトしました。

プログラマーがコードを愛し、書いたばかりの機能をテストすることに非常に熱心であることは誰にとっても明らかでした。 以前に記述された機能のテストについて、また他の開発者によるテストについて話す必要はありません。 プログラマー自身は、システムを操作するためのあらゆる種類のシナリオを再実行せず、すべてのページのすべてのタブに移動しません。

実際、このプロジェクトでは、同様のアプローチを行う余裕がありました。 ユーザーは手の届くところに座っていました。 それは会社の内部自動化のためのプロジェクトでした。 システムを操作したオペレーターとマネージャーが私たちのところに来て、機能について話し合い、エラーを指摘することができました。 したがって、迅速な修正を行い、修正されたバージョンを記入することができます。

エラーレポートは、壁の後ろで叫んでいた。 バグによる損失はわずかであり、誰もが状況に満足していました。

私が実施した調査から判断すると、テストプロセスをどのように調整しますか？ ほとんどの場合、このアプローチをテストする余裕があります。

ステップ2.テスト自動化を開始する



壁の外の人だけでなく、サードパーティのユーザーも使用する新しいシステムの作成を開始しました。 悪いリリースから私たちを守るテスターを雇う必要がありました。

テスターを雇いました。そもそも、単体テストの実行のように、テストを自動化することを決めました。 自動化は、テスターが絶えず同じスクリプトを繰り返さないようにするためのものでした。

アイデアはシンプルで、誰にとっても問題の解決策のように思えました。 CIが夜間に一連の統合テストを開始することを望んでいました。 午前中に到着します。テストがすべて緑であれば、リリースできます。 赤いテストがある場合、それを修正し、テストスイート全体を再度実行するなど。 すべてのテストが緑色になるまで。

テストを記録するために、さまざまなオプションを試し、 Seleniumで解決しました。 最初に、テストはSelenium API自体で作成されました。 時間が経つにつれて、低レベルAPIのラッパーが作成され始め、このラッパーはテスト用の一種のDSLに変わりました。

テスターがテスト用の製品を選別し、テスト自動化プロセスを設定している間、開発は停止しませんでした。 1-2回の反復ごとに新しいバージョンをリリースする必要がありました。 テスターは常にプログラマーを追いかける段階にありました。 バグを恐れることなく静かに新しいバージョンをリリースできるように、彼の目標は100％スクリプト化されました。

ステップ3.グリーンテストのために戦う



テストの自動化に関する問題は、私たちにとって予想外のものでした。 実際、私たちは彼らの準備ができていませんでした。

長いフィードバック


システムが大きくなるほど、作成するテストが増えます。 テストは本当にゆっくりと動き始めました。 彼らが14時間で合格した場合-それは信じられないほどの運でした。 時間が経つにつれて、テストは最終日の18.00から当日の9.00の間に収まらなくなりました。 テストからフィードバックを受け取りませんでしたが、ダウンタイムが発生しました。 また、ライトがオフになったか、サーバーが再起動したため、時間のロスが大きすぎました。

グリーンテスト？ いいえ、見たことがない


グリーンテストはかつてないほどです。 確かに、彼らはかつて、12月30日に始動し、100％のグリーンとして結果を出しました。 多分それは新年のための彼らへの贈り物だった。 常にこれ以上はありませんでした。

なぜ彼らは緑ではなかったのですか？ これにはいくつかの理由がありました。



テストが不安定であり、テストを更新する時間がなかったため、次のことを行う必要がありました。



目標は達成されましたか？


私たちには目標がありました-環境に優しい統合テストを見て、バグを恐れずにバトルサーバーにアップロードすることです。 実際、私たちはこの目標を達成していません。

その結果、実際の状態でのシステムの最初の起動は、自動テストが多くのバグを見逃していることを示しました。 システムを手動で突いたときにこれらのバグが見つかりました。 10分間の手動テストで、最も重大なバグが発見されました。

私は自発的にすべての統合テストの作業をキャンセルすることを決定し、Google Docsでテストスクリプトを記述する手動テストを導入しました。 その後、主要なバグが終了し、テストがカンバンストリームに完全に統合されました。

現在の状態



現在のところ、私の会社では、テスターチームと一緒に、手動テスト+ Googleドキュメントでのテストスクリプトの作成というアプローチを採用しています。 テスターは、記入する前にすべてのスクリプトに手動で穴を開けます。

テストシナリオはプロジェクトアーティファクトの一部と見なされ、ソースコードと共に顧客に提供されます。

実際、優れた結果が得られます。 リリースでは、マイナーなバグ、または実際に機能するバグのみがあります。

テストの自動化に対して？



テスト自動化へのアプローチの適用可能性の限界を理解する必要があります。 たとえば、稼働中のサーバーで404エラーと500エラーをキャッチするバグを作成した場合、人件費は正当化されます。

時々変化する単純なアプリケーションがある場合、そのための統合テストのセットを作成することは理にかなっていますが、これを手動テストと組み合わせます。

手動テストを自動テストに100％置き換えたい場合は、上記の問題を回避する方法を検討してください。 おそらく最初に手動テストを使用し、次にこれらのテストをサポートする必要なく自動化が最大の効果をもたらす部品を自動化する必要がありました。

あなたの会社でテストがどのように発展したかを聞いてうれしいです。



参照資料

テスターがいない上位5つの（間違った）理由 、ジョエル・スポルスキー
ジョエルテスト：より良いコードへの12のステップ 、ジョエルスポルスキー
猿対ロボット。 パートI（TestLabs09） 、Maxim Dorofeev
猿対ロボット。 パートII（TestLabs09） 、マキシムドロフェエフ
猿対ロボット。 パートIII（TestLabs09） 、マキシムドロフェエフ
アジャイルチーム作業：開発+テスト

Source: https://habr.com/ru/post/J145974/

More articles:


All Articles