アジャイルとDevOpsのテスト自動化に関する一般的な問題は何ですか?
最新のソフトウェア開発とQAは、テストの自動化に重点を置きすぎており、探索的テストには十分ではありません。
より自動化されたテストでより高品質のソフトウェアをリリースしていますか?私はそうは思わない!
私は最近、ソーシャルメディアネットワークで次のような投稿に出くわしました
今日のほとんどのテストおよびQAイベントで私が目にするのは、ほとんどがDevOps、継続的インテグレーション、およびテスト自動化です。
それはすべて非常に素晴らしいことですが、多くのくだらないテストケースが自動化されているのを目にします。
統合テストと機能テストでは、すべて自動化されていますが、報告されたバグはほとんどありません。
UATでは、テストチームが前のフェーズでバグを特定できなかったため、ユーザーはますます多くのバグを見つけています。
良いテストケースの書き方を人々に教えないと、完全に自動化されてしまいます…
そして、私の…の解釈は「がらくた」です。 :-)
とにかく、何を見てみましょう 本当に 現代のQAとテスト自動化の世界で起こっています。
アジャイル開発内の「テスト自動化」のほとんどは悲惨な状態にあります。ソフトウェア業界は、主に彼らが構築しているソフトウェアが高品質であるという自信を得るために、「テスト自動化エキスパート」を雇うために莫大な金額を注ぎ込んでいます。それでも、UAT中に目立ったバグやその他の問題が見つかったり、実稼働環境に侵入したりします。どうしたの?
注意:テスト自動化では、私は主に言及しています 玉ねぎ テスト自動化。自動テストは現在、最新のソフトウェア開発プロセスの中心にあります。その目的は 助けて 高品質のソフトウェアを繰り返し提供しますが、それは本当ですか?
問題の真実は、ほとんどのアジャイルチームでは、テスターはもはやテストを行っていないということです。
アジャイルやアジャイルなどの開発慣行や文化のおかげで、手動テストはその美徳を失いました DevOps 、QAスペースに隔たりを生み出しました-コーディングできる人とできない人。
「私は100%自動化エンジニアです」、「80%自動化20%手動」、さらに悪いことに「手動テストが嫌い」などのことをよく耳にします。ショッキング!
DevOpsでは、すべてを自動化する必要があると考えられています。手動で介入する場所はありません。手動テスト。
今日、アジャイルチームのほとんどのテスターは、「テスト自動化」の要求に追いつくのに苦労しています。スプリントのすべてのストーリーを自動化するというプレッシャーがあり、徹底的な探索的テストを行うための十分な時間がありません。
特にアジャイル開発における問題は、QAがユーザーストーリーを取り、その受け入れ基準を自動化することです。そうしている間、彼らの主で唯一の焦点は、テストに合格するためだけに、限られたコーディングスキルと格闘することです。
当然、これは、テストの自動化のみに関心があり、ビルドパイプラインに合格することを確認する場合に、焦点を絞ります。これは、受け入れ基準にあったもの(正しいか間違っているか)が機能していることを証明するだけであり、全体像を忘れがちです。
ますます多くの「従来のテスター」が、コーディングのレッスンを受けてより技術的になることにより、「アジャイルテスト」に移行しています。
誤解しないでください。これはすべて良いです。テスターとして、私たちは常に、機知に富んだ状態を維持するために、新しいテクノロジーを学ぶよう努めるべきだと信じています。システムを高品質でテストしたい場合は、技術スタックを理解する必要があります。
しかし、ほとんどの手動テスターがこれらのイニシアチブをとる本当の理由は、「自動テスト」が手動テストよりも優れているという共通の信念があり、コーディングは楽しいですよね?
注意:手動テストにより、私は ない スクリプトに従い、手順を実行する古い学校の方法を参照します。私はいわゆる「探索的テスター」と呼んでいます。実際のテストを行い、興味深く思慮深いシナリオを実行してシステムの動作を調べることに興味がある人です。残念ながら、探索的テスターの市場は大幅に落ち込んでいるようです。これは非常に明白です。 IT求人サイトで「手動テスター」と「自動テスター」の検索クエリをいくつか実行するだけで、自分で結果を確認できます。
それでは、テスト自動化の取り組みのほとんどが何の価値ももたらさない理由を見てみましょう。
私が繰り返し見ているよくある間違い:
しばらく前に私はブログ記事を書きました なぜテストを自動化したいのですか ?まだ読んでいない場合は、読む価値があります。
その記事の要約は、定期的に実行したいテストを自動化することです。定義上、これらはシステムがまだ機能していることを確認する回帰テストです。
ただし、自動チェックで多くのリグレッションの問題が見つかった場合は、開発者のスキルと開発プロセスに疑問があります。 UI自動テストは、コーディングがお粗末な場合に[費用をかけて]または[補償]してはなりません。
アジャイルチームの「テスト自動化エンジニア」の大多数は、ユーザーストーリーを見て、その受け入れ基準を自動化します。ほとんどの場合、これはセレンとキュウリの組み合わせによって行われます。
最新のWebアプリケーションは、バックエンドとフロントエンドに明確に分割されています。バックエンドは主に、簡単にアクセスできるエンドポイントを備えた多数のRESTWebサービスまたはAPIで構成されています。
アプリケーションのロジックは、APIレイヤーでテストできます。ただし、ほとんどのテスト自動化エンジニアは、せいぜい面倒なUIレイヤーで機能を検証することに頼っています。
そこに次のようなテストツールがあります 空手 APIテストを簡素化するREST-Assured。開発中にこれらのツールを利用する必要があります。悲しいことに、一部のテスト自動化エンジニアは HTTPの基本 、APIテストシナリオを作成できることは言うまでもありません。
UIテストの自動化については、 ヒノキ 素晴らしいツールです。これは、フロントエンド開発者向けのTDDツールのようなものです。開発者は、新しいUIコンポーネントの動作に関する非常に迅速なフィードバックを受け取ります。
空手とサイプレスはどちらも「開発テストツール」、つまり開発をガイドおよびサポートするツールとして機能します。どちらも軽量で、統合が簡単で、提供できます 開発への自信 。
次に、SeleniumまたはCypressを使用して、システムをエンドツーエンドで実行するほんの一握りのシナリオのみを設計できます。これらのシナリオは、軽量の回帰パックを形成し、提供します 事業継続への自信 。
「テストを自動化する前に、機能が完全に開発されて安定するまで待つ」というようなことをよく耳にします。意識のあるテスターなら誰でも、新機能のバグが回帰バグよりも多いことを知っています。安定した機能よりも、現在開発中の機能の問題を見つける可能性が高くなります。
テストの自動化に時間を費やす場合は、開発と並行して、より多くの価値を提供できるときにテストを実行してください。
それだけのために、すべての「テスト」を自動化しないでください。ゲームにいくつかの思考プロセスを入れます。高レベルと低レベルのアーキテクチャ図を研究します。何がうまくいかない可能性があるかを尋ねます。統合ポイントを調べて、潜在的な障害ポイントを探します。
全体的なテストアプローチで(うまくいけば)行うのと同じように、自動化でリスクベースのアプローチを取ります。何かが失敗する可能性はどのくらいですか、そして失敗の影響は何ですか?答えが高い場合は、これらのシナリオを自動化して、ビルドごとに実行する必要があります。
各スプリントでは、多くの場合、そのスプリントのユーザーストーリーに関する自動テストを作成し、他の機能との統合を忘れてしまいます。統合テストが弱いか、まったくありません。
「テスト」の自動化には時間がかかることを忘れないでください。また、テストを自動化することで、実際にテストを行うのではなく、問題の機能がいくつかの受け入れ基準を満たしていることを確認するだけであることに注意してください。
君は できません テストを自動化しますが、既知の事実のチェックを自動化できます。
したがって、「テスト」の自動化に費やすたびに、テストしないことで無駄になっている時間を考えてください。
DevOpsカルチャーの誕生以来、この怠慢がますます見られます。
DevOpsでは、配信パイプラインとデプロイスクリプトがソフトウェアの開発と配信の要ですが、テストされることはほとんどありません。
過去数年間、私は機能的なバグよりもはるかに多くの「環境問題」を見てきました。 CIサーバー、展開スクリプト、テスト環境などの問題などの環境問題。
環境問題は、開発とテストの取り組みに深刻な影響を及ぼします。これらは多くの開発者とDevOpsの時間を消費し、デプロイメントプロセスを大幅に遅くしますが、テストを考慮してこれらの問題を防ぐことは考慮されていません。
最新のソフトウェア配信の一部としてそれらを受け入れるだけです。
私たちは機能的な動作を自動化するために多くの努力を費やし、最も重要な「もの」を完全に無視します。さらに悪いことに、デプロイメントが機能しているかどうかを示すためにSeleniumテストに依存する必要があります。
シナリオは王様です!結局のところ、バグを明らかにするのはシナリオです。
その特定のシナリオについて誰も考えていなかったため、深刻な問題が本番環境に漏れることがよくあります。実行される自動テストの数は関係ありません。シナリオが考えられなかった、またはテストされなかった場合、sodの法則はそこにバグがあることを示しています。
残念ながら、ほとんどのアジャイル開発環境では、このすべての重要な「シナリオワークショップ」アクティビティに十分な献身が与えられていません。
上記の問題が典型的な開発シナリオでどのように現れるかを見てみましょう。
開発者は単純な変更をプッシュし、自動テストがグリーンになるまで30分待ってから、新機能またはバグ修正を本番環境にデプロイする必要があります。 30分の待機は、テストが最初に合格した場合のみです。テストまたは環境の問題が原因で失敗した場合は、さらに時間がかかる可能性があります。
自動テストが実行され、QAがランダムな障害を調査しているため、開発者や製品の所有者は新しい実装を検証し、喜んでリリースしましたが、ビルドがグリーンではないため、できません。
しばらくすると、ビルドがグリーンになるか、テストの失敗に管理者が不満を感じ、とにかくリリースすることを決定します。次に、BOOMは、本番環境で数分後、500台のサーバーエラーが急増します。
失敗は同様のパターンを示しているようです
それでも、開発または配信プロセスの一部としてこれらの問題をチェックするためのプロセスはありません。
テスト自動化エンジニアの焦点は、機能テストを自動化することです。パフォーマンス、セキュリティ、復元力には重点が置かれていません。そして、インフラストラクチャのテストは確かにありません!
機能的な問題を見つける可能性がほとんどない機能テストの自動化から、開発を悩ませているより深刻で一般的な環境問題に焦点を移す時が来ました。
テスト自動化、 間違って行われた場合、または思考プロセスがない場合 は時間の無駄であり、誰にも価値を提供しません。安っぽい自動テストは、莫大なメンテナンスコストを招き、開発を妨げる可能性があります。結局のところ、唯一の解決策はテストをビンに入れることです。
最新のソフトウェア開発では、「テスト自動化エンジニア」の努力のほとんどは、適切なテストやシステムの調査に集中するのではなく、自動化コードとの戦いと「テスト」の機能に費やされています。
自動化コードを書くのに文字通り十分な時間がありません そして 探索的テストを実行します。私たちはストーリーを次々と自動化し、統合テストを忘れ、全体像を忘れます。
多くの場合、大量の自動テストを実行することになりますが、探索的テストではバグの大部分が見つかります。次に、遡及的に、探索的テストで見つかったバグの自動テストを作成して、回帰バグをキャッチします。
何を自動化するかを選択し、リスクに基づいて決定を判断する必要があります。何がうまくいかない可能性があり、それがうまくいかない可能性はどのくらいですか?それがうまくいかなかった場合、ユーザーまたはビジネスにどのような影響がありますか?
「テスト自動化」のビジネスをしている場合は、APIまたはUIコンポーネントの機能をテストするためにSeleniumを使用しないでください。代わりに、Seleniumを使用して、いくつかの有用でビジネスクリティカルなシナリオのみを自動化し、各リリースの前にビジネス継続性に自信を持たせます。
そして最後に、「テスト」の自動化に費やすたびに、テストしないことで無駄になっている時間を考えてください。
参考文献: