皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は海外ニュース4記事をご紹介回したいと思います。
■記事内リンク
「海外ニュース」
・CI / CDパイプラインでテスト自動化を活用する6つの方法
・自律的なAIベースのソフトウェアテストがコストを節約する理由
・テスターがテストの自動化を学ぶのが難しい理由
・BDD（ビヘイビア駆動開発）とは何ですか？
■海外ニュース
□CI / CDパイプラインでテスト自動化を活用する6つの方法
https://searchsoftwarequality.techtarget.com/tip/6-ways-to-harness-test-automation-in-a-CI-CD-pipeline
こちらの記事は、「searchsoftwarequality.techtarget.com」に掲載されていた内容です。
CI/CD（継続的インテグレーション／継続的デリバリー）に関する内容が掲載されていましたので、ピックアップしてご紹介したいと思います。
◇パイプラインでのテストのメリット、コスト、リスク
・メリットについて
CI / CDの自動チェックの主な利点は、迅速なフィードバックとの分離です。
変更によってチェックが強制的に中断されると、ツールはそれがどの変更であったかを正確に認識し、エラーを発生させた人に電子メールを送信して修正できるようにします。
CIプロセスでは、変更が明示的であるため、その修正は比較的に安易です。
・コストについて
パイプラインの一部としての単体テストは、開発環境で単体テストスイートを手動で実行して待機するよりも確かに安価です。
クラウドにパイプラインがある大規模なチームは、仮想マシンの構築にお金を払ったり、オンプレミスでそれを行うための小さなデータセンターを持ったりする場合があります。
これは、各ビルドが実際にWebサーバーやデータベースなどの仮想化されたテスト環境を作成する場合に特に当てはまります。
その環境が大きいほど、コードバージョン管理にプッシュされる頻度が高くなります。
テストはより広範囲になり、全体として、クラウドベースのCI / CDパイプラインをレンタルするためのコストが上昇します。
・リスクについて
他の方法と同様に、粗雑で単純な実装、特に例外やルール違反を許可する実装は、悪い結果につながります。
チームは、単体テストの失敗を無視するか、一部のテストを不安定で価値を下げるか却下することができます。
ルール違反が問題ない環境では、開発者はテスト結果を信頼せず、CIが失敗しても心配しないことを学びます。
◇CI / CDパイプラインでのテストの実用的なヒント
組織をサポートするために構築されたさまざまなテクノロジー（Web、モバイル、デスクトップ、純粋なAPI、小さなメインフレームなど）により、パイプライン内でテストするための単純な脚立を作成することは不可能です。
ただし、Webアプリケーションのコンテキストを想定すると、いくつかの手順を一般化できます。
・効果的なCIから開始
コードをチェックアウトしてビルドを実行する継続的インテグレーションのセットアップを実装する必要があります。
これには、コードを分岐してマージする戦略、およびCIが失敗した場合のフィードバックループも含まれます。
・コードユニットを分離
変更せずにレガシーアプリに単体テストを追加すると、かなりの苦痛が伴う可能性があります。
さまざまなコンポーネントは相互に依存し、セットアップ、関数呼び出し、およびアサーションの「単体テスト」を行います。
代わりに、変更が導入されたときと場所で、テスト可能な優れたコードユニットの作成を開始します。
・他のテストを検討
次に追加する要素は、おそらく単体テストです。
これは、CI / CDパイプラインでのテストへの簡単な入り口です。
ユニットテストは重要なバグをすばやく見つけます。
また、それらのいくつかを維持することは比較的簡単であり、それらは通常CIに統合するのが簡単です。
単体テストツールは通常、テキスト出力を使用してコマンドラインから実行されます。
・仮想環境を構築
APIまたはGUIテストを実行する前に、テストするWebサーバーが新しいビルドに存在する必要があります。
テスト環境のビルドとセットアップを自動化することで、セットアップが簡単になり、苦痛が軽減されるため、テストの頻度が高くなります。
また、手動での時間を大幅に節約できます。
ビルドとセットアップのテスト自動化を行っている一部のチームは、数日または数週間で回収期間を報告します。
・慢性的な障害の場合、APIおよびGUIテストを実行
環境が整ったら、バグの発生場所を検討します。
ログイン機能が頻繁に機能しない場合は、パイプラインにAPIテストを追加してください。
問題がサーバー、Webページ、およびAPI間の複雑な統合である場合は、完全で軽量なエンドツーエンドのテストをいくつか追加することを検討してください。
ここでの考え方は、慢性的なブロッキング状態に関するフィードバックをすばやく取得して、無駄な時間を止めることです。
・カバレッジを測定
大まかに言えば、「自動チェックがいくつかある」の方が「ない」よりも優れています。
次のステップは、カバーされているもの、カバーされていないもの、およびそのテストが行われている深さを把握することです。
CI/CDに関するテスト自動化についてまとめられていましたので、ご紹介いたしました。
私自身、この領域の知識は浅いので、適時理解を深めていきたいと思います。
□自律的なAIベースのソフトウェアテストがコストを節約する理由
https://www.eweek.com/news/why-autonomous-ai-based-software-tests-save-costs/
こちらは、「eweek.com」というサイトに掲載されていた内容です。
AIによるソフトウェアテストにより、コスト節約に関する内容がまとめられていましたので、ご紹介したいと思います。
テストを最適化することで、大幅なコスト削減を実現する大きなチャンスがあります。
ビジネスリーダーがテスト手法をアップグレードすることで大幅なコスト削減を実現できる6つの方法を概説しています。
◇データポイント1：自動化の民主化
自動化は、継続的な手動の開発と保守によってビジネスを前進させるか、後退させるかの違いを生む可能性があります。
機能要件を検証するテスターの多くは、自動化スクリプトを作成するために必要な技術スキルを持っていない可能性があるため、テストの80％以上は依然として手動です。
これはビジネスのボトルネックを生み出し、最新の配信プロセスに必要な速度、精度、スケーラビリティを実現せずにリソースを消費します。
テストの自動化には、必ずしも深い技術的なプログラミングスキルは必要ありません。
主にビジネスプロセス、システム統合、またはユーザーの受け入れに焦点を当てたノーコード、モデルベース、またはスクリプトレスの自動化により、誰もがはるかに高いレベルの生産性と少ない手作業を実現できます。
そのため、ユーザー受け入れテストを自動化するのが早ければ早いほど、リスクとビジネス価値の観点から優れたものになります。
◇データポイント2：ビジネスリスクカバレッジを優先する
障害がビジネスに影響を与える可能性のある重大度と頻度でテストケースを比較検討すると、テスト対象に優先順位を付けることができます。
はるかに少ない作業で、はるかに優れたビジネスリスクカバレッジを得ることができます。
さらに重要なことに、テストの合格/不合格率により、ビジネスの中断に関して潜在的なアプリケーションの障害が引き起こす可能性のあるリスクをはるかに正確に示すことができます。
テストの自動化は、ビジネスリスクをカバーするように最適化されている場合にもはるかに効果的であり、アプリケーションリリースをより頻繁にデプロイできるようになります。
◇データポイント3：DevOpsの能力を使用する
継続的テスト、継続的インテグレーション、継続的デプロイというDevOpsのが、高性能チームでの大規模なソフトウェア配信を推進するために不可欠であることは誰もが知っています。
それはすべて、効率、品質、およびソフトウェアのバリューストリームの最適化に関するものです。
開発、テスト、プロジェクト管理全体で作業を同期するプラットフォームですべてのQAアクティビティを調整することにより、やり直し、誤解、間違いを防ぐことができます。
最短時間で最大のROIを実現するには、チームのコミュニケーション、コラボレーション、透明性を促進して、共通の目標と成功指標を調整し、テストをビジネスのリスクに合わせるツールに投資することが重要です。
◇データポイント4：アプリケーションとサービスをシミュレートする
テスターは、アプリケーションがまだ進行中のときに操作する必要があることが多く、その結果、通常、テスターがアプリケーション配信のボトルネックになります。
依存関係をシミュレートすることで、テストを実行するたびに、適切な依存関係の動作とデータに遭遇するようにすることができます。
また、アプリケーションに高価なハードウェアまたはクラウドインフラストラクチャが必要な場合は、テストコストを削減し、テスト環境が利用できない場合や不安定な場合でもテストを続行できるようにします。
◇データポイントNo.5：左シフトテスト
テストチームはプロセスの後半で重要なフィードバックを提供し、アプリケーション配信のボトルネックを作成します。
今日でも、テストの大部分はUIレベルで実行されますが、UIは通常、各開発サイクルの最後まで完了しません。
AIを組み込んだ新しいテスト技術により、チームはプロセスのかなり早い段階で自動化テストケースの構築を開始できます。
これは、モックアップまたは忠実度の低いプロトタイプだけでUIが存在する前から始まります。
テスト用のこれらのタイプのAIベースのソリューションは、製品が実際に行動する準備ができているときに、それを本当に気にかけている人々に即座に実用的なフィードバックを提供することにより、テストの遅延を排除するため、製品がはるかに早く市場に到達することを可能にします。
もう1つの利点は、APIレイヤーでテストし、AIベースのテクノロジーを使用してUIが完了する前にUIテストを作成できることです。
その結果、アプリケーションの構築中、およびアイデアからコンセプト、プロトタイプ、そして最終的には本番環境に移行する際に、機能テストの動作と開発チームの間に瞬時のフィードバックループが発生します。
デジタルトランスフォーメーションに関して言えば、それは単にツールの数やツールの違いだけの問題ではありません。
それには、テクノロジーだけでなく、人やプロセス全体にわたるより深い変化が必要です。
AIのソフトウェアテストに関するコスト削減について、興味深い内容でしたので、ご紹介させていただきました。
□テスターがテストの自動化を学ぶのが難しい理由
https://techbeacon.com/app-dev-testing/why-its-still-so-difficult-testers-learn-test-automation
こちらは「techbeacon.com」というサイトに掲載されていた内容となります。
テスターが自動化に取り組む際の難しさについて、またそれを克服するヒントについてまとめられていましたので、ご紹介したいと思います。
◇テスト自動化には、ソフトウェア開発スキルが絶対に必要
テスト自動化はソフトウェア開発です。
信頼性が高く、保守が容易で、その規模のテスト自動化ソリューションを作成するには、優れたソフトウェア開発スキルが必要です。
つまり、テスト自動化エンジニアは、ソフトウェアの作成に必要なものを適切に把握する必要があります。
これは、Java、C＃、Pythonなどの言語でコードを記述できる必要があるだけでなく、ソフトウェア開発パターン（カプセル化、継承、ポリモーフィズム、および抽象化）を理解し、オブジェクト指向の4つの柱を適用できることを意味します。
問題は、これらの原則を理解し、それら適用の、適用しないかを知るのに時間がかかることです。
また、ソフトウェアを使用するために開発者である必要はないというローコードツールベンダーの主張にだまされないでください。
テスト自動化をより良くしたい場合は、（オブジェクト指向の）ソフトウェア開発の基礎を研究して、より優れたテスト自動化ソリューションを作成するのに役立ててください。
◇1つのツール、ライブラリ、または言語の経験だけでは不十分
ツールや言語を上手に使う方法を知ったら、やるべきことはまだたくさんあります。
単一のツール、ライブラリ、またはプログラミング言語の使用方法しか知らない場合、多目的なテスト自動化エンジニアになることはできません。
特定の問題を解決するために、これらのツールのどれ（またはそれらの組み合わせ）が最良の選択であるかを知るには、これらのさまざまなツールの知識が必要です。
この知識は、テスト自動化ツールの領域を超えています。
テストを実行して頻繁かつ効果的に使用するには、テストをそのように実行できるようにするツールについて複数の観点で知っておく必要があります。
これらには、バージョン管理システム、継続的インテグレーションオーケストレーター、およびモックツールが含まれます。
（例）
・ユニットテストフレームワーク
（Javaの場合はJUnitまたはTestNG、C＃の場合はNUnitまたはMSTest、Pythonの場合はpytestまたはunittestなど）
・APIテストライブラリ
（Javaの場合はREST Assured、C＃の場合はRestSharp、Pythonのリクエストなど）
・UIテストライブラリ
（Selenium、Cypress、Playwright、WebDriverIOなど）
・単体テスト用のモックライブラリ
（Java用のMockito、C＃用のMoq、Python用のモックなど）
・統合テスト用のモックライブラリ
（WireMock、Hoverflyなど）
・バージョン管理システム
（Gitが最善の策です）
・CIオーケストレーター
（Jenkins、GitLab、Azure、DevOpsなど）
一晩でテスト自動化を成功させる道はありません。
ツール自体についてだけでなく、ツールの背後にある原則（ツールは何をするのか、どのように機能するのか、より広いテスト自動化スペクトルにおけるその位置は何か）についても学ぶことです。
新しいツール（または新しいプログラミング言語の同様のツール）をはるかに簡単に作成できます。
◇学習教材は基本のみをカバーしている
テスト自動化の学習を始めるとき、または新しいツールや言語を手に入れたいときはいつでも、役立つコンテンツがたくさんあります。
好みの学習方法がビデオを見ることであるかどうかは関係ありません。
チュートリアル、ブログ投稿、または本を読む。
またはライブトレーニングコースに参加します。
あなたの最初の一歩を踏み出す際にあなたを導く何かがあるはずです。
ただし、ほとんどの資料は基本を超えておらず、実際の生活は、記事やトレーニングコースで遭遇する状況のようには見えないことがよくあります。
日常的に使用する必要のあるプロジェクトまたはテスト自動化スイートは、学習の過程で使用してきたものよりもはるかに大きくなる可能性があります。
問題が大きい場合は、課題を小さなステップに分解し、これらを1つずつ完了してください。
次のステップに進む前に、ステップが正常に完了したことを確認してください。
経験豊富な同僚に助けやレビューを求めることを恐れないでください。
ステップを完了したときに何かがどのように行われるかだけでなく、そのステップがソリューション全体にどのように貢献するかを理解するようにしてください。
あなたが最初から専門家になることを誰も期待していません。
経験豊富な同僚の時間と注意を引くのが難しい状況に遭遇するかもしれません。
上級自動化エンジニアは不足しており、開発者と同様に、通常は多くの作業を行っています。
経験豊富な同僚、スタッフと一緒に働くことは、物事を成し遂げ、知識と経験を共有するためのはるかに効果的な方法です。
◇移行をスムーズにするための2つのステップ
経験豊富なテスト自動化エンジニアになることは、多くのテスターにとって険しい道になる可能性があります。
ただし、ツールやトリックよりも「パターン」と「原則」に焦点を当て、大きな問題をより小さく管理しやすい問題に分解するという上記のアドバイスに従うことで、テスト自動化のベテランになることができます。
私自身、テスト自動化に取り組むことで、様々なツールや言語について知る必要がある、またその難しさを再認識しています。
共感できる内容がいくつもあり、興味深い記事でしたので、ご紹介させていただきました。
□BDD（ビヘイビア駆動開発）とは何ですか？
https://www.softwaretestingnews.co.uk/what-is-bdd-behaviour-driven-development/
こちらの記事は、「softwaretestingnews.co.uk」に掲載されていた内容となります。
BDD（ビヘイビヤ駆動開発）について、私自身理解が浅く、学習すべき内容が掲載されていましたので、ご紹介したいと思います。
◇ビヘイビア駆動開発（BDD）
ビヘイビア駆動開発（BDD）は、開発者、テスター、製品所有者など、ソフトウェアの開発に関与するすべての人の間のコラボレーションを確立するアジャイルソフトウェア開発プラクティスです。
BDDでは、テストケースは、アプリケーションがどのように動作するかについて共有された共通の言語で記述されているため、誰もが簡単に理解できるため、技術チームと非技術チームの間の直接的なコミュニケーションが向上します。
アプリケーションが非常に単純なユーザー/ビジネスに焦点を当てた言語でどのように動作するかを説明するために行われます。
アプリケーションの動作に関するBDDのビジネスに焦点を当てた視点により、チームは、保守が容易で、テスター、開発者、製品所有者を含むすべてのチームメンバーが使用できる生きたドキュメントを作成できます。
BDDアプローチはTDD（Test Driven Development）から進化したものであり、主な違いはその範囲です。
TDDは純粋な開発アプローチを採用していますが、BDDはチーム全体の方法論です。
TDDは機能の実装に重点を置いていますが、BDDはシステムの動作とこれらの受け入れテストとしての自動化検証に重点を置いています。
◇「Cucumber」と「Gherkin」
Cucumberは、BDDをサポートするオープンソースのソフトウェアテストツールです。
Cucumberでは、BDD要件はGherkin言語で定義された簡単な英語で書かれています。
Gherkinは、使用されたアプリケーションの動作を示し、そこからCucumberが受け入れテストケースを生成できます。
・公式サイト
https://cucumber.io/
Gherkin はシンプルで軽量、構造化された言語であり、英語、フランス語など約70以上の言語を使用して要件とシナリオを記述します。
Gherkin構文は、開発者、テスター、製品所有者、および関係者がプレーンテキストファイルでプロジェクトの要件を理解できるようにするため、BDDを促進します。
Gherkinは、テスト自動化用のスクリプトも提供しています。
・cucumber reference
https://cucumber.io/docs/gherkin/reference/
◇ガーキンテストの書き方
ガーキンテストを作成するには、最初に使用されるキーワードと、実際のそれらの性質を理解する必要があります。
・機能：
この機能は、ソフトウェアが実行することになっていることの説明です。
・シナリオ：
シナリオは、機能をテストする特定のシナリオの基本的な説明を表します。
・背景：
背景を使用すると、シナリオにコンテキストを追加できます。
これは、前提条件として各シナリオの前に実行されます。
・Give：
Givenのリファレンスは、ユーザーの操作が全体像に現れる前に、システムを既知の状態にすることです。
・When：
ユーザーによって実行されるアクションを定義することです。
・Then：
whenステップのアクション後の結果を確認することです。
And＆But：
複数のGiven、When、Thenがある可能性があります。
そのような場合、And＆Butを使用して、シナリオをより単純で詳細にします。
◇BDDを使用する利点
BDDは、その包括的で用途の広い性質により、幅広い利点があります。
BDDを実践しているチームが経験する主な利点のいくつかを次に示します。
・共通理解による明確性：
BDDによって技術的な障壁が軽減されるため、共通言語で書かれたテストはチームのすべてのメンバーにとってメリットになります。
・有効性：
BDDは開発プロセスを加速します。
シナリオは、要件、受け入れ基準、テストケース、およびテストスクリプトがすべて1つになっているため、他のアーティファクトを作成する必要はありません。
Gherkin構文のモジュール性により、テスト自動化の開発が促進されます。
・自動化：
BDDフレームワークにより、シナリオを自動化されたテストに簡単に変換できます。
ステップはシナリオによってすでに与えられており、自動化テスターは各ステップの操作を実行するためのメソッド/関数を作成する必要があります。
テスト自動化の対象範囲が広がり、より関連性の高いテスト自動化シナリオが実現し、回帰エラーと手動チェックの労力が軽減されます。
・左シフトテスト：
早い段階でテストすると、後でバグが少なくなります。
BDDでは、テストケースの定義は本質的に要件フェーズ（ウォーターフォールの場合）またはグルーミング（アジャイルの場合）の一部になります。
BDDシナリオが作成されるとすぐに、テストと自動化を理論的に開始できます。
・再利用可能で柔軟性：
Gherkinステップ（Given、When、Then）はシナリオ間で再利用できます。
より多くのステップ定義が追加されると、シナリオの作成と自動化がより簡単かつ迅速になります。
場合によっては、新しいシナリオでは、異なるステップパラメータまたは1つの新しい行だけが必要になります。
モジュラー設計により、自動化コードへの変更がより安全になります。
・失敗したシナリオと欠陥のデバッグ：
主な利点の1つは、失敗したシナリオのトラブルシューティングとバグの修正を行うBDDの機能です。
BDDでのテストスクリプトの記述方法の性質上、失敗の根本原因を見つけるための調査ははるかに迅速かつ簡単です。
どのガーキンステップでテストが失敗したかを正確に知ることができます。
◇結論
BDDは、要件、受け入れ基準、テストケース、およびテストスクリプトを単一のアーティファクトとして簡単に理解できるようにします。
BDDは、その保守性と堅牢な性質により、単純なプロジェクトと複雑なプロジェクトの両方に役立ちます。
これは、今日のSDLC（ソフトウェア開発ライフサイクル）における包括的なアプローチを提供します。
適切に作成されたテストは、すべての人（技術者および技術者なし）がテストを明確に理解していることを確認するだけでなく、すべての人が共通の理解を持っているため、提供された要件が目的の製品に変換されることを確認します。
BDDは、最近では最もアジャイルなアプローチの1つであることが証明されています。
「Cucumber」については、名称は知っていましたが、実際には使ったことが無く、自動化を進めて効率化を図る場合、このツールについても習得しなければならないと考えています。
BDDに関して、わかりやすくまとめられていた記事でしたので、ご紹介させていただきました。
■最後に
今回は、海外ニュース4記事を取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
サイトトップへ
https://susakiworks.com/
ソフトウェアテスト自動化の教科書 〜現場の失敗から学ぶ設計プロセス
