how implement efficient test automation agile world
アジャイルの自動化は非常に重要です。
すべてのスプリントで追加および提供される多くの機能について考えてみてください。新しく追加された機能が既存の機能に影響を与えないようにする方法が必要です。
スプリント期間が短いため、スプリント終了時に製品がインクリメントされるたびにスーツ全体を実行することは事実上不可能です。自動化されたテストスーツを持つことは、ここで間違いなく大きな役割を果たします。
ただし、自動化の導入と成熟には確かに時間がかかります。自動化アクティビティの計画と設計に初期投資を行うことは、長期的には間違いなく報われるでしょう。
アジャイルテストの高度なシリーズのこの第3部では、プロジェクトに自動化をもたらす際に、私の経験に基づいて考慮すべきいくつかの指針を引用しようとしています。
また、読んでください パート1 そして パート2 最初にトピックをよりよく理解する。
学習内容：
アジャイルで何を自動化するのですか？
プロジェクトに自動化を導入することを計画しているときはいつでも、私たちのほとんどはすぐに「スモークテストスーツ」または「回帰テストスーツ」のどちらかが最高であると投票します 自動化の候補 。もちろんそうですが、自動化テストピラミッドについて考えると、それは私たちが話しているピラミッドの最上層にすぎないと結論付けることができます。
上記のレイヤーとは別に、まだ サービスレイヤー そしてその ユニットレイヤー それはもっと重要です。
Adobe FlashPlayerでSWFを開く方法
では、スモークテストと回帰テスト以外のどのテストが自動化の良い候補になるのでしょうか。
＃1）ビルドとデプロイ
従来の環境では、毎週、隔週、場合によっては毎月のビルドが事前定義されています。その理由の1つは、これらの展開に時間がかかることです。このアプローチの問題は、バグを修正したり、新機能を実装したりするために、事前定義された日付を待たなければならないため、遅延が発生することです。
2番目の理由は、テスターがテストを終了してバグや欠陥を思い付くまでに、プログラマーはさまざまな実装に移行し、古いアプリケーションのバグを解決することにあまり関心がなくなったためです。このアプローチはまた、機能を本番環境で利用できるようにするための時間を遅らせます。
構築と展開は、反復的で、時には退屈なエンティティです。ビルドのデプロイにも数時間かかる場合があり、テストと最終的にはフィードバックが遅れます。反復的なタスクであるため、展開は自動化の有力な候補になります。
また読む=> リリースと展開の管理プロセス
自動ビルド展開を使用する利点のいくつかは次のとおりです。
- 展開を間違える可能性はありません（誤ったファイルのコピーやファイルの誤った場所へのコピーなどの人為的エラーを回避できます）
- バグ/機能は、修正されるとすぐにテストできるようになります
- テスターはテストする時間を増やす
- この機能は、短時間で本番環境に移行する準備ができています
- クイックフィードバック
＃2）ユニットテスト/コンポーネントテスト
を使用してユニットレイヤーを自動化することの重要性については、すでに説明しました。 前回のチュートリアルでのTDDアプローチ 。
これはピラミッドの最下層を形成するため、基礎と基礎は堅固である必要があります。開発チームは、ほとんどのテストをこのレイヤーに対応させるために、協力して協力する必要があります。
＃3）API / Webサービスのテスト
Webサービスは、基盤となるアーキテクチャやテクノロジに煩わされることなく、2つのアプリケーションが要求と応答の観点からデータまたは情報を交換する媒体です。より簡単に言えば、要求を出し、応答を検証することは、Webサービスのテストで通常行うことです。
Webサービスのテスト これらのWebサービスメソッドを呼び出すプログラムを作成し、返される値を検証する必要があります。さまざまな順列や組み合わせについてサービスをテストすることもできます。すべてのテストデータをExcelシートに入れておくと、プログラムはデータを読み取り、テストデータをパラメーターとして渡してテスト可能なサービスを呼び出し、結果を検証できます。
この特定のテストは、ピラミッドの中間層の一部です。ほとんどの機能テストは、このレイヤーにプッシュできます。このレイヤーで発生する欠陥の解決は簡単に修正でき、UIが利用可能になるまで延期されません。
＃4）GUIの背後でのテスト
GUIの背後にあるテストの自動化は、実際のGUIを自動化するよりも比較的簡単です。もう1つの利点は、UIの変更に関係なく、機能が損なわれないことです。 UI要素の一部が変更されても、機能の機能は変更されません。この手法は、主にビジネスロジックとルールに焦点を当てています。
テストケースは主に表形式またはスプレッドシートで記述され、これらのテーブルからの入力を受け入れて結果を返すフィクスチャ/コードスニペットが記述されます。結果はすぐに生成され、技術者以外の利害関係者がこれらのテストを実行して期待される結果を得るのに最適なプラットフォームを提供します。この手法を実現するために使用されるツールの1つは フィットネス 。
＃5）非機能テスト
この 非機能テスト手法 基本的に、負荷、パフォーマンス、およびストレステストが含まれます。これらのテストを自動化するために利用できる、市場ですぐに利用できるさまざまなツールがあります。
＃6）データの比較
テストの多くでは、テキストファイル、CSV、Excelファイルなどのデータファイルを比較する必要があります
- これらのファイルは、データ検証を行うためのベースラインと比較できます
- 比較は同じデータでもフォーマットが異なる場合があります。これは基本的に、2つの異なるソースから生成された同じファイルが2つある場合に発生します
これらの比較は繰り返し行うことができるため、自動化されます。
＃7）検索
大量のファイルから特定のエンティティを検索するのも面倒な場合があり、それが繰り返しの作業である場合、神は私たちを助けてくださいます。 1つの例は、ログファイルの検索です。これも退屈で反復的な作業である場合は、自動化について考える必要があります。
＃8）反復的なタスク
自動化では、エンドユーザーとの対話から始まり、ストーリーの作成から開発までのタスクが繰り返される場合は、それを検討する必要があります。自動化を行うことは、それに関与する高度なツール/テクノロジーが必要であることを意味しないことを理解する必要があります。単純なVBマクロでも、目的を解決するためのJavascriptを使用したJavaプログラムでもかまいません。
どこから始めれば？
自動化を開始する場所を示す箇条書きやステップバイステップガイドはありません。チームの自動化を開始するには、ブレインストーミングを行い、自動化しようとしている側面について深い考えを適用する必要がありますか、それとも自動化の最終的な目標は何ですか？
あなたは始めることができます：
- 反復的なタスクを特定し、
- アプリケーションの問題領域を特定する
- テストの課題の特定
ツアープロジェクト/チームに自動化がない場合は、ユニットテストを最初に対象にして自動化できる多層アプローチを選択できます。これにより、最高のROIが得られます。
Javaでヒープを作成する方法
同時に、テスターはスモークテストスーツの作業を開始してから回帰に取り組むことができます。チームがスキルを習得し、快適に感じたら、他の反復的なタスクの自動化に徐々に移行します。
ニーズを評価せずに、新しいツールの購入に直接飛び込まないでください。前に言ったように、単純なプログラムまたはマクロは、反復的なタスクのいくつかを自動化するというあなたの目的を解決することができます。したがって、ツールの購入を決定する前に、 POCを実行します そのツールが効果的に使用できるかどうかを評価します。
次の記事で、自動化のための正しいテストケースを選択する方法の詳細と、自動化の取り組みの見積もりに関する洞察を提供したこれらのドキュメントを確認してください。 自動化テストプロセスの課題への手動 そして セレン自動化プロジェクトのテスト見積もり。
自動化とツールの範囲が確定したら、次はフレームワークを設計します。
アジャイルでは、フレームワークが進化していることを忘れないでください。最初にフレームワーク全体を設計してから実装することを目標にしないでください。 MVP（Minimum Viable Product）を設計および実装してから、既存のフレームワークを拡張して、より多くの機能を追加します。また、自動化スイートを堅牢にしたい場合は、適切なコーディングと開発のプラクティスを適用する必要があります。
XboxOne用バーチャルリアリティゴーグル
いくつかのベストプラクティス
- 一度に100％自動化することを目標にしないでください。小さく始めます。それは進化するプロセスであることを忘れないでください
- ソフトウェア開発で従うのと同じアジャイルプラクティスに従ってください。自動化には、適切な計画と設計も必要です。自動化するときに技術的負債を増やしたくないでしょう
- テスト自動化バックログを作成します。このバックログは、新しい機能の実装から既存の機能の拡張まで多岐にわたります。識別したアイテムにストーリーポイントを与え、それに応じて割り当てます。これらのバックログアイテムをスプリントに持っていき、かんばんボードを使用して追跡します
- 自動化ストーリーの受け入れ基準を記述します。これらの受け入れ基準には、次のものが含まれます。
- テストスイートとCIの統合
- 一元化された場所へのスーツの移植
- 結果をメールで送信する
- テストが失敗したときにエラーログファイルを送信するためのプロビジョニング
- その他の基準…。
- 新しいツールの評価に時間をかけすぎないでください。新しいツールに必要なものすべての優先チェックリストを作成し、それを評価するためのタイムラインを決定できます。規定の時間内に結果が表示されない場合は、次の結果に進んでください
- 何を自動化するかについて賢明な決定を下します。すべての自動化が効果的であり、プラスのROIが得られるわけではありません。自動化のためだけに自動化しないでください
- 適切な開発環境を利用してください。コードをローカルに保管しないでください。コードを保持し、一日の終わりにコードをチェックする習慣をつけるためのリポジトリを用意します
- 同様の方法で、一元化された場所から自動テストを実行してみてください。それを人から独立させなさい。チームの誰もが自分のマシンからスクリプトをトリガーでき、結果は電子メールで取得できるはずです。
自動化に適用できるアジャイルの原則は何ですか？
いくつかの非常に簡単なヒント：
- 物事をシンプルにしてください。 必要なことをしなさい。自動化を不必要に複雑にする砂糖でコーティングされた実装を提供する多くの例を見てきました。不要なものは避けましょう
- 簡単なことをすることは、最も簡単なことをすることを意味しません。 これは、自動化の目標を達成するために赤ちゃんの一歩を踏み出すことを意味します。自動化するために単純な機能を使用する場合もありますが、自動化の実装が複雑なものになる場合があります。
- チーム全体のアプローチを適用する 。誰もがアジャイルチームのテスターだと思います。自動化ジョブをテスターだけ、または開発者だけに制限しないでください。プロジェクトの自動化を実現するには、各分野がお互いの立場に立つ必要があります。このアプローチは、実装に伴う技術的な問題を解決するのにも効果的です。
- フレームワークはアジャイルで進化しています 。自動化の一部を不必要に複雑にする可能性のある多くの機能を提供しようとしないでください
- それを正しく行うために時間をかけてください。 技術的負債を回避するために、適切に設計するために少し時間がかかります
- 頻繁にフィードバックを得る
- 適切なコーディング標準と実践を適用します。 設計は単純で、OOPSの概念を適用し、テストを互いに独立させておく必要があります。テストスーツの「保守性」などの要素を考慮してください
アジャイルで自動化する際に何か問題がありますか？
アジャイルの世界での自動化には 独自の課題 ：
- 私たちは本当によく計画する必要があります。適切なテストスイート、ツール、フレームワーク、およびアプローチを決定するには、すべて適切な戦略が必要です。ただし、計画を立てすぎないように注意する必要があります。 MVP（Minimal Viable Product）を念頭に置いてください
- 迅速に提供したいためにコードの品質を妥協する：自動化においても技術的負債が十分に保持されることを覚えておく必要があります
- チームはほとんどの場合、「チーム全体のアプローチ」に従わず、テスターの自動化されたスイートのコーディングと保守の全責任を負います。これにより、テスターの責任が増します。
- 機能テストの自動化は、UIの自動化よりも困難です
これらすべての課題の中で、最も重要な課題は、テスターのスキルを向上させることです。
チームの自動化を実行および維持することは、プログラマー（開発者）が行うプログラミング（開発）アクティビティのようなものです。実装だけでなく、自動化されたスーツをCIに統合することも重要であり、テスターは新しいスキルを学び、採用し、新しいツールとテクノロジーを学ぶ必要があります。
アジャイルに適合するいくつかのオープンソースツール
- Selenium WebDriver -UIの場合
- セレングリッド –並列実行の場合
- キュウリ–BDD用
- JMeter –パフォーマンステスト用
- 石鹸 –Webサービスの場合
- WireMock –Webサービスが利用できない場合のWebサービステスト。
- エポック-モバイル向け
有名なアジャイルテスト象限で締めくくります。
象限1 TDDアプローチで自動化できるユニットとコンポーネントのテストです。
第2象限 BDDアプローチを適用できる機能テストについて説明します。
第3象限 手動テストの範囲を持つ唯一の象限です。
第4象限 基本的に、いくつかのツールで実行できるテストについて説明します。これにより、負荷テスト、ストレステスト、ボリュームテスト、およびセキュリティテストが処理されます。
結論
スモークテストと回帰テスト以外にも、自動化の範囲はたくさんあります。したがって、自動化をこれらのタイプのテストのみに限定するという概念から脱却する必要があります。つまり、アジャイルのテスターのスキルセットには、バグや欠陥を見つけるだけでは不十分です。
テスターは、より協調的になり、プログラミング/自動化のスキルを磨く必要があります。ますます多くのテストが自動化されると、テスターはより洗練されたやりがいのあるタスクに従事するためのより多くの時間を得ることができます。
著者について： この記事はSTHチームメンバーのShilpaによるものです。彼女は過去10年以上、インターネット広告、投資銀行、テレコムなどの分野でソフトウェアテストの分野で働いています。
以下にコメントや考えを共有してください。
推奨読書
- AutoItチュートリアル-AutoItのダウンロード、インストール、基本的なAutoItスクリプト
- テスターは自動化のためにテストを超えてグリップを失っていますか？
- 手動および自動化テストの課題
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- 10ステップの自動化テストプロセス：組織で自動化テストを開始する方法
- あなたは手動または自動化テストの専門家ですか？私たちのためにパートタイムで働いてください！
- Androidアプリケーションをテストするための11の最高の自動化ツール（Androidアプリテストツール）
- トップ10+ベストソフトウェアテストブック（手動および自動化テストブック）