皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内、海外ニュース２記事をご紹介回したいと思います。
■記事内リンク
・T-Dash正式リリース
・避けるべき自動化の落とし穴トップ6
□T-Dash正式リリース
こちらは、バルテス社から２月にリリースされたテスト自動化「T-DASH」についてです。
本ブログでも過去にご紹介させていただきました。
今回、正式リリースされましたので、T-Dashについての概要をもう一度、確認してみたいと思います。
◇T-Dashの特徴1:ローコスト
T-DASHの主な特徴は、他に類を見ない「低コスト」部分であると思います。
公式サイトでも
革命① 革命的なロープライス
革命② 日本語テストケースで革命的に自動化
革命③ テスト自動化まで革命的に簡単
とうたっており、無料プランの他、スタンダードプランが「月々3,960円」となっています。
他のテスト自動化サービスに関しては、月額10,000円以上は超えるのは当たり前で、かつ見積もり問い合わせをしないと正確にはわかりません。
T-Dashは、その点値段が格段に抑えられていて、テスト自動化の導入検討をしている企業、担当者の方にとっては、とても魅力的なサービスであると思います。
私の会社でも、近々導入の打診を試みています。
◇T-Dashの特徴2：第三者検証会社がサービスを行っている
もう一つの特徴としては、バルテス社という第三者検証の大企業がサービスを行っている点です。
テスト自動化サービスを行っている会社は、日本でも色々とありますが、それはテスト自動化をはじめとした「ツール」を売っている企業がほとんどです。
バルテス社は、第三者検証会社として、ソフトウェアをはじめとしたテスト経験に長けた企業です。
そのため、テスト自動化ツールの「T-Dash」は、テスト担当者の目線で設計されていて、ユーザビリティが高いと考えています。
また、正式サービスとして間もないですが、上記のような背景から、追加機能および改善が段階的に入り、よりテスト実施者、テスト担当者の方の「声」が反映されたツールに仕上がっていくと考えます。
その例として、T-Dashは、PCのWebサービスのみサポートとなっていますが、今後のマイルストーンを見ますと、モバイル対応が含まれています。
また、JIRAやCI/CD連携といったことことも予定されており、やはりテスト実施者目線が高いと思っています。
JIRAをはじめ、CI/CDツールでは、AzureDevOps等が有名ですが、こちらのツール群は、「開発」、「運用」の利便さは高いですが、
テストについては、そこまでではありません。
現に、私はAzureDevOpsをしようしていますが、開発側のソース管理や、タスク管理などはとても使いやすと思いますが、テストに関する「TestPlans」と呼ばれている機能は、利用するためのライセンス料が高く、かつテスト設計のしづらさがあります。
AzureDevOpsの使いづらい例として、
・テスト設計をする場合、カテゴリやタイトル、テストステップ、アクションといった項目しかない
・テスト結果ステータスは、Pass、Failesの2択のみ
・再テストを行う際、すでにPass済のケースをもう一度行うことになる。
・エクスポート機能が不十分で、CSV等テスト結果がうまく出せない
・結局はテスト実施は、エクセルとなる
といった具合です。
テスト会社がサービス化していますので、今までのツール以上に、テスト担当者、実施者目線で、よりよいツールになっていくと、私は思っています。
私も実際の業務、案件で導入を行いたいと思っていますので、当ブログでも今後、ご紹介できればと考えています。
テスト自動化の導入を考えている方、T-Dashのサイトページにアクセスしてみては いかがでしょうか。
https://www.t-dash.io/
□避けるべき自動化の落とし穴トップ6
こちらは、「nativenewsonline.net」に掲載されていた内容となります。
テスト自動化を行う際の注意事項がまとめられていましたので、ご紹介したいと思います。
◇自動化するものとしないものを特定する
最初で最も重要なことは、自動化する価値があるものを特定することです。
スクリプトに1時間以上かかる場合は、毎日時間を節約できない限り、おそらくそれだけの価値はありません。
タスクに20分以上かかる場合は、自動化できるかどうかを検討する必要があります。
タスクに多くの時間を費やしていると、おそらくお金を無駄にしているからです。
2番目のステップは、タスクを手動で実行する方法に基づいて自動化を作成することです。
これを行う最良の方法は、最初に手動で試してみることです。
そうすれば、どのステップを自動化する必要があるかを正確に知ることができます。
手動で行うときに手順をスキップする場合は、それらの手順を自動化する必要はありません。
プロセスに冗長なステップや不要なステップがある場合は、それらのステップを自動化されたプロセスから削除することもできます。
人間の相互作用や判断なしには実行できないタスクが常にあります。
このようなタスクは、完全に自動化されるまで、継続的な監視と介入が必要です。
この良い例は、テストの1つにあるバグです。
読み取っているファイルにデータが含まれていないことを示すエラーメッセージがプログラムから返されたため、テストは失敗します。
◇トレーニングの欠如
多くの場合、テスト自動化の実装は、適切な計画とトレーニングなしで急いで実行されます。
テスト自動化の実装は、慎重に計画、実施、および管理する必要があります。
テストケースは、理解を深めるために適切に文書化する必要があります。
自動化スクリプトの適切な文書化も重要です。チーム間での知識の共有も重要です。
テストを自動化する際の混乱を避けるために、チームメンバーにはあらゆる種類のトレーニングを提供する必要があります。
テスト自動化ツールにより、複数のプロジェクトで使用でき、他のチームでも使用できるオープンソースライブラリとしてリリースできる再利用可能なコードをかなり簡単に作成できるため、複数のチームが使用できる共通のコードベースが作成されます。
テスト自動化にオープンソースライブラリを使用する場合は、プロジェクトで使用したり変更を加えたりする前に、必ず最初にコードを読んだことを確認してください。
不注意で何かを壊してしまい、開発者や他の熟練した人の助けなしにそれを修正する方法がわからない場合があります。
◇監督者がいない
テスト自動化の最大の問題は、テスト自動化の実行中にソフトウェアのバグや監視の欠如を探すのを忘れることです。
これらの間違いの背後にはいくつかの理由があります。
知識不足のためにテストしていないバグがあるかもしれません。
そのような場合、その特定の機能/モジュールについてさらに調査および研究する必要があります。
テスターは、テスト対象のアプリケーションに慣れていない場合があります。
このような場合、テストプロセスを自動化できるように、テスト対象のアプリケーションを十分に理解できるように、外部リソースを使用して徹底的な調査を行う必要があります。
2番目の理由は、自動化テストの実行中に監視が不足していることです。
自動化テストチームのリーダーまたはスクラムマスターは、開発段階で自動化テスターの時間を見つけて、テスト対象のアプリケーションを理解するのを支援できるようにすることが非常に重要です。
チームリーダーは、次の段階に進む前に、チームメンバーが検証を実行することも確認する必要があります。
これらすべてを実行することで、後の段階でQAの取り組みに影響を与える可能性のあるバグをコードに作成することを回避できます。
◇ROIについて考えていない
テスト自動化について話すとき、最初に頭に浮かぶのは、さまざまなプロジェクトの時間、お金、およびリソースを節約することです。
しかし、ROIはどうでしょうか？
チームが犯す最大の過ちの1つが、投資収益率（ROI）に注意を払っていないことを知って驚かれるかもしれません。
彼らは、テストを自動化することによってどれだけ節約できるかについて明確な考えを持たずに、自動化されたテストから始めます。
何よりもまず間違いは、期待している投資収益率（ROI）に注意を払っていないことです。
期待するROIで自動化のコストを正当化できるはずです。
それができない場合は、自動化を忘れる必要があります。自動化は、利益をもたらさずにプロジェクト全体のコストを増加させるだけだからです。
◇大規模なタスクの自動化
大規模なタスクの自動化テストは、広範なテストケースの保守と管理を必要とするため、複雑なプロセスです。
自動化テストケースは互いに異なり、それらを維持する方法も異なる必要があります。
自動化は、効率的で信頼性が高く、再現性が高い必要があります。
次の問題は、大規模なタスクの自動化テスト中に障害を引き起こす可能性があります。
a）アプリケーションまたは環境が変更されたときにスクリプトを維持する。
b）適切なテストデータを特定する。
c）期待される結果を生成する。
d）実際の結果と期待される結果の比較。
e）パフォーマンスの問題。
f）複数の環境に関連するメンテナンスの問題。
g）デバッグの問題。
h）構成の問題。
i）プロジェクトの全体的なパフォーマンスに影響を与えるテストケースの実行時間の問題。
まず第一に、テストプロセス全体を自動化しようとしないでください。
反復的であると思われるタスクの特定の部分を自動化し、他の部分で独立して作業する必要があります。
優れた自動化エンジニアと悪い自動化エンジニアを区別するもう1つの点は、データ処理を制御フローロジックとビジネスロジックから分離する能力です。
これは、ほとんどの場合、常に変化するビジネスロジックと比較して、アプリケーションでデータ処理と制御フローロジックが変更されることはめったにないためです。
したがって、このすべてのロジックをまとめると、アプリケーションの小さな変更ごとに多くのコードを記述していることに気付く場合があります。
消費税計算のアプリケーションを自動化するとします。
このような場合、最終的な出力値を取得するために、さまざまな入力パラメーターのセットを使用して多くの複雑な計算が行われると同時に、入力パラメーターにいくつかの変更が加えられるため、コードも変更する必要があります。
したがって、すべてをまとめると、テストが十分に小さくないと、テストを維持することが非常に困難になります。
◇「オープンソース」という理由でツールを選んでしまう
多くの組織が認識していないことの1つは、オープンソースは品質を保証するものではないということです。
多くのオープンソースプロジェクトは、他の何十ものプロジェクトに同時に取り組んでいる1人の人間によって維持されています。
これは、組織にとってビジネス価値のある十分にテストされたソフトウェアを作成するのに役立つ環境ではありません。
多くの場合、人々は、コミュニティが自動化の取り組みに役立つと考えているため、オープンソースツールを選択します。
ただし、新しいオープンソースツールの使用を開始する際に考慮すべき重要な点が2つあります。
1.コミュニティ内の開発者（または寄稿者）の数
プロジェクトに取り組んでいる人の数を知る必要があります。
また、プロジェクトに取り組んでいる人が日常業務でプロジェクトを使用しているかどうかを知る必要があります。
2.製品とコミュニティのドキュメントとサポート
これはおそらく最も重要な要素の1つであり、特に自動化の旅の始めには、使用することを選択したオープンソースツールに関する多くの情報を見つけることができない可能性があるため、すべてのドキュメントを読む必要があります。
決定を下す前に、ベンダーまたはコミュニティ開発者によって提供されます。
選択するツールに関係なく、ツール自体がスケーラブルであるか、大規模なテストのためにクラウドSeleniumグリッドと統合できる可能性がある必要があります。
https://www.lambdatest.com/
LambdaTestは、SeleniumやCypressのようなテスト自動化フレームワークをサポートして、自動化テストの取り組みを実現します。
LambdaTestは、クラウドベースのクロスブラウザテストプラットフォームであり、3000以上の実際のブラウザとオペレーティングシステムを介してWebサイトとWebアプリをテストできます。
■最後に
今回は、以上の国内ニュース、海外ニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
