皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内ニュース1記事、海外ニュース2記事をご紹介回したいと思います。
■記事内目次
「国内ニュース」
・AIテスト自動化「mabl」を販売
「海外ニュース」
・TestProjectがSelenium/Appiumテスト自動化の次世代リリース発表
・継続的テスト：すべてのDevOpsチームが知っておくべきこと
■国内ニュース
□AIを活用したテスト自動化ソリューション「mabl」を販売
https://cloud.watch.impress.co.jp/docs/news/1312113.html
こちらの記事は、ベリサーブ社が米mabl社と販売パートナーシップ契約を締結し、「mabl」販売・導入・運用支援の提供を行うとのニュースとなります。
「mabl」は、AIを活用したテスト自動ソリューションとのことで、「Autify」似た位置づけのサービスと思われます。
「mabl」ではローコードで自動テストを作成することができ、PCのWebテスト、モバイルのWebテストに対応しており、今後はモバイルアプリについても対応予定とのことです。
mablのサイトを覗いてみました。
https://www.mabl.com/
Mablの特設ページが設けられており、Webテストの他、APIテストや、jira,Github,SlackなどのDevOpsツールとの連携、データ駆動型のテストなども紹介されていました。
mablの料金などは、明記されておらず、「無料トライアル」から申込みとのことです。
気になる方は、「mabl」のサイトにアクセスしてみてはいかがでしょうか。
■海外ニュース
□TestProjectがSeleniumおよびAppiumテスト自動化の次世代リリースを発表
こちらのニュース記事は、「financialbuzz.com」のサイトに掲載されていた内容です。
Tricentis社の「TestProject」と呼ばれるSelenium、AppiumをオープンSDKを利用して、Web、モバイルのテスト自動化を行えるツールのver2.0がリリースされました。
TestProjectは、なんと無料アカウントを作成することで、利用することができます。
特徴としては、AIツールを使用、かつオフライン環境でもテスト作成が行えるとのことです。
テスト作成においては、操作を行ってレコード、及びC#、Java、Python言語でコードを記述することもできるとのことです。
結構興味深かったので、実際に使ってみました。
導入～テスト作成までは以下のような流れでした。
①まず、無料アカウントを作成しログイン
②その後、「TestProject_Agent_2.0.2」と呼ばれるエージェントファイルをインストール
③言語を設定、設定した言語に対応したSDKをインストール。
（私の場合、Pythonを使用していたので、VSCで「pip3 install testproject-python-sdk」でインストールしました。）
④TestProjectがWebベースで起動し、テストプロジェクトを作成
⑤テストケースを作成し、レコードか、コード作成を選択
試しに、当ブログのテストページに遷移するケースを作ってみましたが、慣れれば素早くテストケースが作れそうです。
・TestProject ホーム画面
・テストケース作成時
こちらは、かなり興味深いので、別途個人的にも調べてみようかと思います。
AIでの自動修復もどのようになるかの興味もあります。
気になった方は、TestProjectのページにアクセスしてみては、いかがでしょうか。
https://testproject.io/
□継続的テスト：すべてのDevOpsチームが知っておくべきこと
https://techbeacon.com/app-dev-testing/continuous-testing-what-every-devops-teams-needs-know
こちらのニュース記事は、「techbeacon.com」というサイトで掲載されていた内容となります。
アジャイル開発が主流になる中で、かつサービスコンテンツのリリース更新頻度が2週間前後となると、継続的に行うテスト、品質を維持するには困難になってきます。
そのようなプロセスの場合に、重要となるのが「継続的テスト」です。
こちらの記事では、この「継続的テスト」にフォーカスをあてて述べられていましたので、ご紹介したいと思います。
◇継続的テスト：基本
継続的テストは、共同開発手法の集大成です。
これは、開発チームに次の内容が含まれている場合、最終的に得られるものです。
・テスト駆動開発（TDD）
・エクストリームプログラミングの原則
・テスターや開発者との共同タスクグルーミング
・プロダクトマネージャー主導の検収試験
ただし、継続的テストを行うには、チームは以下の内容についても考慮が必要です。
・コードチェック
・ビルド
・テスト実行
・失敗時に報告
・定期的に繰り返す
プロダクトマネージャーは複数パターンのユーザーストーリーを作成し、それを開発者に渡します。
開発者はいくつかのコードを書き、おそらくいくつかの単体テスト実施し、それをテスターに渡します。
テスターは調査し、修正が必要な情報を開発者に返します。
「かんばんボード」等に表示されるスイムレーン図は、開始・停止などのフローを明記します。
◇役割の境界を破る
チームが継続的テストに近づくほど、役割間の境界線が曖昧になり始めます。
開発者は、ストーリーについてプロダクトマネージャーと協力し、アイデアを洗練し、開発する必要があるものをよりよく理解します。
彼らがコードを書くとき、彼らは時々別の開発者やテスターとペアで対応します。
機能が「完了」するのは、継続的インテグレーションでテストが実施済み、あるいは探索的テストが実施済み、理想的としては製品マネージャーがテスト結果内容を受け入れた場合です。
◇早期に頻繁にリリースする
継続的テストの重要な要素は、頻繁に部分的なコードチェックイン（1日に数回）であり、自動化によって可能になります。
これは、自動化されたテストフィードバックサイクルが、このリズムに追いつき、チェックインから約1時間以内にエラーをキャッチするのに十分な速さである必要があることを意味します。
一部の「テスト自動化」スイートは重大な欠陥を見つけることができないため、この部分は多くのチームにとって達成するのが最も困難です。
この理由は、スイートではなく、コードリリースとチェックインを単純な部分に分割せずにコードリリースを高速化しようとするチームにある場合があります。
◇主な目的
継続的テストの目的は、開発チームがいつでも製品の品質を認識できるようにすることです。
特定の役割の人々が飛び込んで調査し、報告するのを待つ代わりに、継続的テストは、新しいコードが書かれるたびに品質に関する情報を提供します。
これは、標準の2週間のスクラムサイクルよりも早くソフトウェアをリリースしたい企業にとって非常に重要です。
継続的テスト組織では、チームが「かんばんボード」等を使用する場合、CIの自動化されたプロセスのおかげで回帰テストが常に行われるためです。
◇継続的テスト：会話を開始します
平均的なソフトウェアプロジェクトでは、プログラマーが自分のコードを書いて机に座っています。
彼はプロダクトマネージャーと協力して質問したり、テスターが見つけたばかりのバグを示したりする場合がありますが、ほとんどの場合、各自が自分のことを行います。
テストには通常、少数の単体テストが含まれますが、実際のテスト作業は、専用のテストの役割を持つ人にプッシュされます。
多くの場合、継続的テストとは、フルタイムのソフトウェアテスターの役割を担う人が少ないか、まったくいないことを意味します。これは、ソフトウェアチームがテストを必要としないためではありません。
これは、テストがすべてのステップで体系的に行われているためです。
伝統的に他の人に押し付けられ、「私がしないこと」と見なされる作業は、責任を持って処理されます。
継続的テストでは、製品チームと技術チームの全員がソフトウェアをテストします。
彼らは、より伝統的なテストの役割を担うように、ソフトウェアテストの分野の専門家ではありませんが、彼らはそれぞれの分野の専門家であり、通常はそれで十分です。
継続的テストと最新のソフトウェア開発アプローチの関係がわかり始めている場合は、すでに時代の先を進んでいます。
◇継続的テストがDevOpsプラクティスにどのように連動するか
DevOpsには、一連のプロセス、システム、およびアーキテクチャの要件が付属しています。
ほとんどの場合、開発者はコードを書くときに一緒に作業し、ペアプログラミングを行うこともあります。
彼らが取り組んでいるストーリーは、数日または数時間の作業で測定されます。
開発が完了すると、それはコードが他の人の介入ではなく、本番の準備ができていることを意味します。
テクノロジーの面では、DevOpsは、以前にサイロ化されていた部門間のコードの受け渡しを理解して自動化することを目的としています。
継続的テストは、テストとQAサイロがどのように崩壊し、広がり、ソフトウェア配信ライフサイクル全体に参加するかに焦点を当てています。
テストは、最初の設計仕様から継続的な生産監視の最終段階まで関与する必要があります。
DevOpsは、組織がそれを実現することにコミットしている場合、継続的テストが成功する可能性がある環境です。
ただし、重要なのは、継続的デリバリー環境で最も人気のあるツールを選択するだけでなく、それらのツールをどのように結び付けるかを決定することです。
これらのツール間のシームレスな情報交換を保証する機能は、手動による介入の必要性を排除することにより、自動化の継続的な側面を実現する方法です。
◇継続的テストはどのように見えるか
5年前あたりから、人々が2週間ごとにソフトウェアを提供することがより一般的になりました。
サービスとしてのソフトウェアの台頭により、変更のサイズと数は、配信メカニズムのオーバーヘッドとともに縮小していました。
継続的テストを実行する開発グループは、1日に複数回ソフトウェアをリリースできます。
現在、問題が発生したときに迅速に発見するための最後の手段として、継続的テスト、高度な分岐戦略、および環境監視ツールを使用して、新しいソフトウェアを毎日何百回も本番環境に提供している企業は少数です。
2週間のリリーススケジュールは6か月ごとよりもはるかに優れていますが、それでも厳しい流れに陥っています。
この2週間以内に、計画フェーズ、開発フェーズ、テストフェーズ、およびソフトウェアの本番環境への提供から時間がとられる問題も多くあります。
◇あなたの旅を始めましょう
継続的テストを行うということは、構築しているソフトウェアの各レベルおよび開発プロセスで実際のテストを体系的に行うことを意味します。
流行語のように感じるかもしれませんが、よく見ると説得力のあるストーリーが見つかります。
「継続的テスト」について、深掘りされ、興味深い内容でしたので、ご紹介させていただきました。
■最後に
今回は、国内ニュース1記事、海外ニュース2記事を取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
サイトトップへ
https://susakiworks.com/
The DevOps ハンドブック 理論・原則・実践のすべて
