皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回ご紹介する内容は以下となります。
■記事内リンク
2.レガシー アプリケーションのテストにおける課題とベスト プラクティス
□1.AGEST社「AGEST式探索的テスト」の提供開始
https://agest.co.jp/news/20220907/
こちらは、AGEST社がソフトウェアサービス「AGEST式探索的テスト」の提供を開始した内容となります。
「AGEST式探索的テスト」は、以下の内容がベースに構築されています。
・探索的テストの第一人者であるCem Kaner氏の「進化型アプローチ」
事前にテストケースを作成するのではなく、ソフトウェアを動かしながらテストエンジニアが柔軟にテストしながら進めていくソフトウェアテスト方式が採用されています。
・AGEST社取締役CTSOの高橋寿一氏の著書「ソフトウェア品質を高める開発者テスト～アジャイル時代の実践的・効率的なテストのやり方」の考え方
探索的テストサービスは、他企業でもサービス化されていますが、AGEST社は独自の方針に基づいてサービス運用されているようです。
探索的テストサービスの概要が公式サイトに掲載されていましたので、ご紹介したいと思います。
◇AGEST式探索的テストサービス概要
・AGEST式探索的テストの流れ
01：機能抽出、02：観点カスタマイズ、03：ウェイト設定、04：テスト実施
・AGEST式探索的テスト実施イメージ
①ソフトウェア理解、②テストケース設計、③テストケース実行
上記を並行して実施
・AGEST汎用的テストチャータ
テストエンジニアのスキルに依存しない「AGEST汎用性テストチャータ」を用いて、属人的な探索的テストを安定した品質で提供
・サービス料金について
お問い合わせ
https://agest.co.jp/news/20220907/
個人的に興味を持ったのが、探索的テストサービスとありますが「テスト設計」を行ってから実施する点が挙げられます。
基本的に探索的テストでは、テスト担当者の経験やスキルをベースに実施され、テスト設計は行われないのが一般的です。
AGEST社特有なのでしょう。
ご興味のある方は、AGEST社公式サイトにアクセスしてみてはいかがでしょうか。
https://agest.co.jp/
□2.レガシー アプリケーションのテストにおける課題とベスト プラクティス
https://bfsi.eletsonline.com/challenges-and-best-practices-in-legacy-application-testing/
◇初めに
昨今では、多くの企業がデジタル化を採用して関連性を維持し、テクノロジー主導の経済で成長しているにもかかわらず、レガシー アプリケーションのモダナイゼーションが重要になっています。
時代遅れと見なされているにもかかわらず、レガシー システムには、顧客記録、財務台帳、およびその他の機密性の高い企業データの巨大なデータベースが保存されています。
したがって、モダナイゼーションを採用する場合は、専門家に連絡し、データの損失だけでなく、組織のビジネス価値の追加に役立つシステムの費用対効果の高い効率的な統合を確実にするために、効果的なソフトウェア テストが実施されていることを確認することが重要です。
詳しく説明すると、レガシー アプリケーションのテストの必要性は、製品の市場投入までの時間を短縮する必要性、レガシー アプリケーションで使用されるテクノロジに関連するメンテナンスと使用コスト、およびメインフレームなどのテクノロジーや自動化に使用できるツールに課せられた制限により、定型的な手動タスクを自動化する能力が低下しています。
ただし、テスト プロセスは困難な場合があり、さまざまなハードルに悩まされる可能性があります。
特定のプロセスに関する知識、専門知識、および経験、ソフトウェア技術、およびスキルセット、および関連ツールの選択などです。
◇ソフトウェア テスト チームが対処する必要がある重要な側面について
・潜在的な情報源の特定
テスト対象のシステムに関する知識のソースを見つけることは非常に重要です。
ドキュメントは見つけにくいか、古くなっている可能性があるためです。
1 人の個人がすべてのソリューションを持っている可能性は低いため、企業は知識の探求に積極的に取り組み、適切な知識の伝達が確実に行われるように、潜在的なリソースをすべて提供してソフトウェア テスト チームを支援する必要があります。
・効果的な統合のためのシステムの理解する。
レガシー技術と現代技術の統合の複雑なダイナミクスを考えると、ソフトウェア テストの専門家が古いシステムと新しいシステムの両方の性質をよく知っていることが不可欠です。
場合によってはドキュメントが不足していることを考慮すると、技術的な観点からシステムを解読して理解し、テストの自動化に役立つ質問に答えることができるチームを持つことが重要です。
・自動化する必要があるものとそうでないものを決定する。
テストの自動化は、特に膨大なレガシー アプリケーションのテストを扱う場合に、あらゆるプロジェクトの作業を容易にするのに役立ちます。
一方で、自動化はすべての問題を魔法のように解決する特効薬ではありません。
実際には、1 つの間違った手でさえ、物事をより困難にする可能性があります。
すべてを自動化しようとする、テスト対象のシステムを適切に分析せずに自動化する、UI 自動化に投資しすぎる、複雑なシステム統合を考慮しない、信頼性の低いテスト データを使用する、不安定なテスト環境で作業するなどはすべて、テスト自動化に対する望ましくないアプローチの例です。
◇レガシ アプリケーション テストのベスト プラクティス
・100% のテスト カバレッジを望むことは、開発者が放棄すべき慣行である
企業は通常のコードをテストしていないため、開発者は 100% のカバレッジを達成することに集中できません。
従来のコードベースは巨大で複雑です。
すべてのクラスのすべてのメソッドのすべてのループをテストするのではなく、統合や機能テストなどの「大規模な」テストに焦点を当てます。
コンテキストを頻繁に変更し、通常のようにモデル コードを変更せずにすべてのテストに合格することを確認します。
◇アプリケーションの使いやすさと効率性は、モダナイゼーションの中核にある必要がある。
・レガシー アプリケーションのテストに着手するときは、アプリケーションの使いやすさや効率を損なったり、低下させたりしないように、明確に理解する必要があります。
多くの場合、テスターはプロセスに夢中になり、モダナイゼーションは自動的に効率の向上につながると思い込み、その推測が大きな後退につながる可能性があります。
◇CI/CD プロセスにテストを含める。
CI/CD パイプラインは、コード リポジトリへのチェックインごとに自動テストの実行をトリガーし、新しい変更によって現在の機能が損なわれないようにします。
継続的インテグレーション (CI) により、企業は新機能をより迅速にリリースできます。
企業のような言語やツールを使用して、レガシー アプリケーションのクラスごとに一連のテスト (テスト スイート) を作成します。
◇技術文書への投資
技術文書は、ソフトウェア開発全体のベスト プラクティスですが、ほとんどの企業は次の理由でそれを提供しています。
ドキュメントが対処する最大の問題は、維持と新機能の作成に必要な作業がどれだけ少ないかということです。
この一般的なアプローチは、レガシー プロジェクトのテスト カバレッジと理解度を大幅に向上させるのに役立ちます。
ベースラインができたら、他のソフトウェア開発手法を使用しても何も壊れていないことを確認して、アプリケーションを再構築できます。
目的は、アプリケーションを標準化し、業界標準と特性評価テストにさらに依存できるようにすることです。
その時点に到達したら、ハーネスは目的を果たしたので、ハーネスを取り外し始めることができます.
□最後に
今回は、以上のニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
