皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内ニュース2記事、海外ニュース2記事をご紹介回したいと思います。
■記事内リンク
「国内ニュース」
・テスト管理ツール「TestRail」のクラウド版を提供開始
・デジタルハーツ子会社、ベトナムに「ジャパンチーム」結成
「海外ニュース」
・ローコード自動ソフトウェアテストがDevOpsを推進
・リリース管理：なぜ多くのチームがそれを間違えるのか
■国内ニュース
□テスト管理ツール「TestRail」のクラウド版を提供開始
https://www.techmatrix.co.jp/product/testrail/
こちらは、以前3月にご紹介ニュース「TestRail」のクラウド版となります。
https://susakiworks.com/news/
TestRailは、テストケース作成、テスト結果、テストの進捗状況確認、不具合の検出状況など、テスト工程に関するものを効率的で管理できます。
TestRailはWebベースのテスト管理ツールで、RedmineやJIRAといった管理ツールや、RanorexなどのUIテスト自動化ツールとも連携でるとのことです。
また、クラウド版ということで、環境構築、サーバー管理なども不要となり、導入時のコストも削減できるようです。
TestRailの主な特徴は以下となっています。
◇テストにさまざまな情報を関連づけて管理
・テストケースやテストデータ等、視覚的に紐づけして管理が行えます。
◇テスト実施の準備と結果の共有が容易
・テスト項目の優先付け、テスト結果をグラフ表示、ログ、証跡データの登録なども行えます。
◇進捗や比較などのレポートを提供
テストレポートのサマリが複数用意されており、テスト結果の共有、報告時に役立ちます。
◇要件・課題管理ツールと連携
JIRA、Redmineの他、マンティス、バックログ、Githubなど主流の管理ツールとの連携も可能です。
◇テスト自動化ツールと連携
「Ranorex」と呼ばれるUIテスト自動化と連携が可能です。
TestRailクラウドサービス版の年間ライセンスは、5ユーザーで25万8000円とのこと。
トライアル版mの用意されています。
ご興味のある方は、「TestRail」のページにアクセスしてみては、いかがでしょうか。
□デジタルハーツ子会社、ベトナムに「ジャパンチーム」結成
https://www.logigear.jp/
こちらのニュース記事は、第三者検証会社のデジタルハーツホールディングス社の子会社「LogiGear」社がベトナムに日本企業専属のソフトウェア開発支援チームを結成し、ソフトウェアテスト及びテスト自動化サービスの日本展開を開始した内容となります。
LogiGear社は、米国、日本で展開されているソフトウェアテスト会社で、ベトナムのホーチミン・ダナンに会社を設立したことで、
ベトナム最大のソフトウェアテスト専門会社になったとのことです。
LogiGear社では、ソフトウェアテストの他、テスト自動化のサービスが複数用意されていました。
◇テスト自動化開発
・自動化ツールTestArchitect、SAPテスト、seleniumm、Appium、Ranorexなど用意されています。
「TestArchitect」は、Selenium、Appium等をベースにした統合的なテスト自動化ツールのようです。
◇テストサービス
・APIテスト、探索的テスト、オフショアテスト、SAPテスト、ゲームテスト、車載テスト
SAPテストは初めて見たのですが、こちらは「SAPGui」（SAPERPのデータベース、アプロケーションサーバー、クライアント3層からなるグラフィカルインターフェースクライアント）用の自動化サービスも行っているとのことです。
オフショアテストは、今回の目玉であるベトナムでのソフトウェアテスト・テスト自動化サービスにあたります。
LogiGear社のサイトは他にも様々な情報が掲載されていましたので、ご興味のある方は覗いてみてはいかがでしょうか。
■海外ニュース
□ローコード自動ソフトウェアテストがDevOpsを推進
https://devops.com/low-code-automated-software-testing-drives-devops/
こちらの記事は、海外の「DedOps.com」に掲載されていました記事となります。
こちらの記事に紹介されていた内容ををご紹介したいと思います。
DevOpsでは、本質的な課題の解決に焦点を合わせています。
それは、ソフトウェアチームが、品質に対する顧客の高い期待に応えながら、迅速に革新していくことです。
言い換えれば、より少ないミスでより速く有用なものを構築することです。
2020年には、クラウド、SaaS、DevOpsによってもたらされる継続的な混乱に、リモートワークと加速するデジタルトランスフォーメーションの課題が追加されました。
2021年には、テストの自動化を品質エンジニアリングで次のレベルに引き上げるためのロードマップが必要です。
これは、ベストプラクティスとデータ駆動型テストをエンドツーエンドのカスタマーエクスペリエンスに組み込み、組織の成長を促進する分野です。
◇DevOps時代の品質プロセスを再考する
品質工学（QE）の多くのQEチームは、複雑で脆弱な自動化フレームワークと遅い手動テストに苦労しており、DevOpsの採用に深刻なボトルネックを生み出しています。
開発が加速する一方で、QEには異なるまたは時代遅れのワークフローとツールセットが残されています。
DevOpsとデジタルトランスフォーメーションによって提示される課題と機会に立ち向かうには、品質へのアプローチの革新が必要になります。
これまで以上に、ソフトウェア開発ライフサイクル（SDLC）の後半で実行するタスクとしての品質保証から、ライフサイクル全体にわたる品質エンジニアリングの実践に焦点を移す必要があります。
それは、開発者がローカルブランチで作業しているときから始まり、アプリケーションの全表面領域（Web、API、モバイル、電子メール、PDF）で高品質のカスタマーエクスペリエンスが本番環境で確認されるまで、幅広く効果的なテストカバレッジから始まります。
品質のすべての側面を評価し、機能の正確性、アクセシビリティ、パフォーマンス、ユーザーエクスペリエンスなどに関連する要件を満たしていることを確認します。
◇ローコードテスト自動化は、新たな品質の文化を築く
ローコードで、真に効果的なテストは、手動テスターから開発者、自動化エンジニア、製品所有者、カスタマーサポートまで、あらゆるロールにいたります。
ローコードツールは、テストの作成、テストの更新、およびテスト結果からの洞察の取得に全員が参加できるようにすることで、品質エンジニアリングを全体に認知するのに役立ちます。
ローコードテストは、特に手動テストから自動テストへの移行において、品質エンジニアリングにいくつかの利点をもたらします。
ローコードは、このシフトを管理し、労働者をスキルアップし、全体の品質を確保するための”鍵”です。
◇最新の自動化ソリューションは休息な変化を受け入れる
従来のテスト自動化ツールの主な課題は、頻繁に変更されないアプリケーション向けに設計されており、コードの検証のみを目的としていたことです。
これらは、ページ要素を識別するために静的セレクターに依存していました。
セレクター（IDなど）が変更された場合、またはオブジェクト（XPath）がWebページ上で移動した場合、テストは失敗しました。
DevOps、アジャイル、CI / CDを介して開発を加速する企業が増えるにつれ、テストメンテナンスの負担により、手動テストと同じボトルネックが発生しました。
2020年は、ローコードテスト自動化のブレイクアウトの年でした。
新しい使いやすいソリューションは、このセクターを支配してきたレガシーフレームワークの機能を上回りました。
これらのソリューションには、機械学習、データ分析、その他の高度なテクノロジーが組み込まれており、テストメンテナンスの負担を大幅に軽減し、レガシーフレームワークのテスト剛性の課題を克服します。
AIと機械学習により、テスト自動化ソリューションは、テスターが製品をナビゲートするだけでトレーニングされます。
これは、要素が移動したりプロパティが変更されたりした場合に、その要素を含むテストが人間の介入なしに更新されるようにします。
これにより、テストを最新の状態に保つために必要なメンテナンスの量が大幅に削減されます。
テストを更新する必要がある場合、ローコードモデルを使用すると、誰でも簡単にアクセスして更新を行うことができます。
今後、自動修復とローコード編集は、高速チームで高品質のエンジニアリングをサポートするために不可欠です。
◇カスタマーエクスペリエンス全体のテスト
次世代のテスト自動化プラットフォームは、コードの検証からユーザーエクスペリエンス全体の検証に焦点を広げます。
これは、アプリケーションのパフォーマンス、アクセシビリティ、ユーザーエクスペリエンスなど、機能以外の要件をカバーするためにテストを拡大することから始まります。
たとえば、主要なページの読み込み時間の傾向を特定し、視覚的な変化を監視することは自律的に行われ、顧客体験を管理するために不可欠です。
そこから、最も頻繁に使用される、または最もリスクが高いアプリケーションのコンポーネントに向けて、品質への取り組みに優先順位を付けることができます。
ただし、アプリまたはWebサイトのUIのみに焦点を当てた完全なデータ駆動型のテスト戦略でさえ、エンドツーエンドのユーザージャーニー全体をカバーする可能性は低く、テストカバレッジのギャップと顧客の潜在的な問題点が発生します。
たとえば、一般的なユーザージャーニーには、電子メールを開く、リンクをクリックする、Webサイトを確認する、PDFをダウンロードするなどがあります。
従来のツールの制限により、テストはその工程をWeb部分に委ねられますが、最新のソリューションでは、ユーザーまたはカスタマーエクスペリエンス（CX）全体を検証できます。
つまり、電子メールの受信とオープン、リンクのクリック、Webサイトへのログイン、ダウンロードです。
コードを1行も記述せずに、APIを介してバックエンドの値を確認することも可能です。
◇ユーザー中心の品質工学
品質はもはや後付けではなく、展開前にチェックするための単なるボックスではありません。こ
れはユーザーエクスペリエンスの重要な部分であり、したがって、ソフトウェアを使用して顧客にサービスを提供するすべての業界で競争上の優位性を維持するための重要な部分です。
テストの自動化は、リモートで作業しながら、より迅速にイノベーションを起こし、DevOpsに移行し、高品質の製品を構築するために競争する高速チームにとって重要です。
ありがたいことに、DevOpsの実装に伴い、ますます多くの品質保証チームがテーブルに着席し、戦略としての品質のプロファイルを高め、DevOpsの需要に対応できるテスト自動化ソリューションの需要が高まっています。
この要求に応えて、新世代のインテリジェントなテスト自動化ソリューションにより、チームはローコードと機械学習を採用して品質を維持することで、課題に立ち向かうことができます。
この環境で高品質のエンジニアリングの文化を構築するには、チームは、ユーザー中心のテスト自動化ソリューション、つまりユーザージャーニー全体をカバーするソリューションを必要としています。
機能の正確さを検証するだけでなく、品質のすべての側面に対する豊富な洞察を提供し、継続的な改善を可能にするソリューションです。
最も重要なことは、チームの全員が品質に参加できるようにするソリューションが必要です。
これにより、DevOpsの速度で品質の基準を設定し続けるユーザーフレンドリーな製品の構築に積極的に参加することが保証されます。
ローコード及びDXにも関する内容でしたので、ご紹介させていただきました。
□リリース管理：なぜ多くのチームがそれを間違えるのか
https://techbeacon.com/devops/release-management-why-so-many-teams-get-it-wrong
こちらは「techbeacon.com」に掲載されていた記事となります。
リリース管理に関する興味深い内容でしたので、ご紹介したいと思います。
◇あなたが話していること明確にする
まず、用語についてリリースとは、通常、アプリケーションであれ機能であれ、要求した人が何かを利用できるようにすることを意味します。
DevOps設定を使用していない場合、開発組織は作成したものを運用チームに「リリース」しています。
DevOps設定を使用している場合、またはデジタルソリューションのエンドコンシューマーの観点からリリースを検討している場合、リリースとは、運用チームがアプリ、サービス、または機能を利用できるようにするときです。
DevOpsチームは通常、開発サイクルから運用サイクルに移行するプロセスとしての「デプロイメント」について話します。
DevOpsの担当者は、これをリリースとは呼びません。
その人にとって、リリースは展開後に行われます。
それは、ユーザーが展開された新機能にアクセスするときです。
私が目にする多くの対立は、上記の2つの見解が理解および評価されていないことが原因です。
下の図はその違いを示しています。
従来のリリース管理では、devとopsの間で厳密な制御があります。
運用で本番環境に展開されたものはすべて、サービスの利用者が暗黙的に利用でき、問題はすべてサポートを通じて処理されます。
対照的に、DevOpsでは、同じチームが開発と運用の両方を処理するため、デプロイはチームの多くのアクティビティの1つにすぎず、デプロイは継続的に行われます。
ただし、DevOpsチームは、新機能を利用できるようにする方法を慎重に計画し、問題がある場合は、すべての問題が処理されるまでユーザー数を制限します。
◇リリース制御の利点
リリース制御機能の主な目的は、新機能、単純なパッチ、完全に新しいシステムなど、本番環境にプッシュされるすべてのものの「目的に適合」することを保証することです。
通常、運用チームは次の質問に関心があります。
・すでに実行されている機能を制御しているか？
・リリースは安全か？
・運用はリリースを管理する準備ができているか？
・リリースのパフォーマンスおよび、その他機能の準備ができているか？
・トレーニングなどの関連するすべてのアーティファクトが文書化されており、既知のエラーが理解されているか？
◇最善のアプローチ：アジャイルを実践し、自動化する
適切に実装されたDevOpsチームは、開発が運用から分離されている従来のITセットアップよりも、生産性が大幅に向上し、高品質の製品を提供できます。
ただし、多くのレガシーアプリケーションはこの新しいパラダイムへの変換は難しいです。
しかし、opsは、消費者へのリリースを制御するための新機能を公開する方法としてサービスカタログを使用する方法など、いくつかのトリックも教えることができます。
運用チームは、サービスカタログ、サービスサブスクリプション、および契約に基づくサポートを扱った経験が豊富です。
これは実際に、リリースフラグなどに基づいてロールアウトがバックグラウンドで制御される現在のDevOpsプラクティスを改善するために使用できます。
私たちは、両方の長所を次のIT4IT標準に組み合わせるこの方法を構築しており、展開とリリースを別々に管理する新しいバリューストリームを備えています。
これは、以下の青い値ストリームの矢印に簡単に示されています。
よりアジャイルなアプローチに移行するときに、リリース制御の既存のプロパティのいくつかを維持することが重要であるもう1つの理由があります。
それは、暗黙知を自動化して文書化することです。
何かを再構築し、特定のリリースのコンテンツが何であるかを知ることができることが重要です。
そうすれば、監査を実行してセキュリティ制御を確認することもできるからです。
これが、DevOpsチームだけでなく、IT組織全体によってリリースを一元化および管理する必要がある理由です。
彼らは何が生産に入るのかを理解する必要があります。
ITがそうでない場合、ビジネスはセキュリティリスクの影響を受けやすい可能性があります。
最後に、リリースが十分に文書化および標準化されていない場合、長期間メンテナンスが少ない製品またはサービスで新しいアップグレードが必要になったときに、数年後にDevOpsチームを簡単に復活させることはできません。
◇優れたリリース管理のベストプラクティス
では、どちらのアプローチが正しいのでしょうか？
システムが安定した状態にある場合もありますが、微調整が必要な場合があります。
ただし、問題が発生した場合、誰かがそれについて何かをする必要があります。
これが、前のチームが何を生産に投入し、集中管理を行っているかを知ることが重要である理由です。
すべてのDevOpsチームが運用を管理するための独自のパイプラインとメソッドを持っている場合、新しいチームがエラーを発生させずに何かを管理することはほとんど不可能になります。
次の方法で、devからopsへの移行を管理する必要があります。
・本番環境にデプロイされたもの（および、セットアップに関連する場合は、本番環境前およびシステムテストも）が明確に定義され、長期にわたって再現可能であることを確認します。
・バイナリ、リリースノート、構成スクリプト、既知のエラーのコンパイルなどのリリース/展開アーティファクトに関する適切なレコード管理を提供します。
多くの場合、資産のセット全体を複製することは暗黙知に依存しています。
・サプライチェーンを確認
つまり、予想されるサプライヤによって配信されたことが保証されます。
これは通常、コード署名と適切なプロセスによって実現されます。
・悪意のあるまたは不注意なリリースミスから保護します。
内部の脅威から保護するために、新しい展開には常に複数の人が関与していることを確認してください。
・リリース前に、できれば「左シフト」方式でコードがスキャンされていることを確認してください。
これにより、ぎりぎりのブロックプロセスにならないようになります。
・自動リスクスコアリングを使用して、自動化された機能テストと非機能テストを実行します。
このようにして、リリース候補を効率的かつ継続的に評価することができます。
・DevOpsチームは、可能な限り自動化を試みる
リリース管理についてまとめられており、リリース内容のドキュメント化、及びチーム内にリリース内容を的確に認知させることの重要性など、当たり前の内容ですが、改めて考えさせられる興味深い記事でしたので、ご紹介させていただきました。
■最後に
今回は、国内ニュース2記事、海外ニュース2記事を取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
サイトトップへ
https://susakiworks.com/
The DevOps ハンドブック 理論・原則・実践のすべて
