ATS|テスト自動化

2022.1.7

【第3回】:ローコードを自動テストに適用する場合の課題

「ローコード」で変わるテスト自動化プラットフォーム

昨今のトレンドである「ローコード開発」は、専用のツールを用いて少ないソースコード記述でサービスを開発する手法です。工数・コストの削減や、柔軟な開発体制の構築を可能にする有力な手法であり、設計・コーディング (実装) 工程においてはローコード開発の技術やツールが普及期に入っています。しかしながら、テスト工程への適用はまだ緒に就いたばかりです。

ローコード開発のメリットを最大限に享受するためには、開発工程で生じる工数の中でも大きな割合を占めるテスト工程における「テスト自動化」にも適用すべきです。連載第2回では、テスト工程にローコード開発を適用するメリットについて解説しました。詳しくは、次の記事をご一読ください。

「ローコード」で変わるテスト自動化プラットフォーム【第2回】:ローコード開発を適用するメリット

これまでの連載でお伝えした通り、テスト工程へのローコード適用においては専用のテスト自動化ツールを用いることが通例です。しかし、こうしたツールにも様々な制約があり、テスト自動化の実現にあたって障壁となります。テスト工程にローコード開発を適用し費用対効果を高める上で、こうした課題を把握することが重要です。

そこで連載第3回となる本記事では、ローコード対応のテスト自動化を実現する上での課題をご紹介します。

ローコード対応のテスト自動化を実現する上での4つの課題

ローコード開発は使用するツールに依存するため、機能や自由度の乏しいツールでは高い効率化の要求を満たせないばかりか、当然ながらツールに実装されていない機能には対応できません。ここではローコード対応のテスト自動化を実現する上において、4つの課題それぞれについて詳しく解説します。

課題1:テスト実行のみしか自動化できない

一般に提供されるテスト自動化ツールの多くは、テスト実行しか自動化できません。すなわち、テスト計画や設計、環境構築、結果の分析やレポーティングといったプロセスは手動で行う必要があるのです。こうしたプロセスは工数が増大しやすく、テスト実行だけを自動化しても費用対効果がそれほど上がらないこともあります。

特にテスト設計においては、複雑・高機能なサービスを網羅的に確認するために、膨大なテストケースが必要です。しかしローコード対応のテスト自動化ツールでも、テストケースの作成自体はエンジニアに委ねられるケースが多く、工数の増大は避けられません。自動化できないプロセスでは工数の増大ばかりか人的ミスも生じやすく、テスト品質の低下にもつながります。

短いサイクルで開発を繰り返すアジャイル開発では、テスト工程に十分な工数を確保できないケースも少なくありません。テスト実行以外のプロセスに大きな工数を費やすことは、重大なリスクとなります。

課題2:テスト・サービスの種類によっては自動化が困難

多くのテスト自動化ツールでは、テスト・サービスの種類によっては自動化が困難です。たとえば、操作内容を記録・再現することで自動化するツールでは、エンジニアが操作できないテストケースは自動化できません。そのため、繊細なタイミングが要求されるテストケースなどはツールでカバーできず、バグ流出につながる恐れもあります。

特に、ユーザビリティテストや負荷テストといった、非機能要件のテストを自動化できないツールがほとんどです。こうしたテストを手動で行うためには、高度なスキルや多くの工数を要します。熟練したテスターの工数を確保できなければ、高いテスト成果を上げることはできません。

また、サービス自体についてもWebアプリ・デスクトップアプリ・モバイルアプリなど、様々な種類が考えられます。しかし、特定種類のサービスしか自動化できないツールも少なくありません。ツールにこうした制約があると、将来的に開発の幅を広げる際にネックとなることもあります。

課題3:難しいプログラミング言語のスキルが必要

ローコード対応のテスト自動化ツールとはいえ、ある程度のソースコード記述やトラブル時にソースコードを見ての原因究明などは必要となります。しかし「Java」や「C#」など、難易度の高いプログラミング言語を採用しているツールも多いのです。こうした言語では記述ミスがあるとエラーが発生し、テストケースの問題を解決するために多くの工数が必要となります。

Webアプリ向けのツールでは、比較的習得しやすい「JavaScript」や「Python」などを使えることもあります。それでも、一朝一夕で習得できるほど容易なプログラミング言語ではありません。結局のところ、熟練したエンジニアでなければツールを使いこなすことが困難なため、特定の要員しかツールを十分に扱えない「属人化」も生じやすく、開発体制の変更や拡大においてのネックとなります。また、テスト自動化エンジニアの人材育成には多くの人的コストが必要です。

課題4:既存開発プロジェクトへのリスクが大きい

ローコード対応のテスト自動化ツールを開発・QA現場に適用する上で、要員の確保からツールの選定、導入、効果検証にいたるまで多くの作業工程・期間を要します。また、従来のテストプロセスから大きく変化が生じることで、特に初期導入期間はかえってテスト工数が増大することも考えられます。

そのため、進行中の開発プロジェクトへテスト自動化を適用するにあたり、大きなリスクを負うことになるのです。昨今主流となっているアジャイル開発では、短期間でテストを実施しなければならず、こうしたリスクはより増大します。導入期間を最小限に抑えるためには、熟練したエンジニアが必要不可欠です。

ローコード対応のテスト自動化を実現するための解決策とは?

今回は、ローコード対応のテスト自動化を実現する上での課題についてお伝えしました。ローコード対応のテスト自動化によって飛躍的なQCDの向上が期待できるものの、その実現には多くの課題が存在します。そのため実際には、手動によるテストに甘んじる開発・QA現場が大半です。

これらの課題を解決する有力な手段は、「ADOC Testing Service (ATS) for Eggplant」の適用です。テスト自動化プラットフォームを構築するワンストップサービスで、米キーサイト・テクノロジーズが開発した『Eggplant』をローコード対応のコア・ツールに採用しています。

次回は、解決策として有力なATS for Eggplantの特徴やメリットについてご紹介しますので、ぜひご一読ください。

■ ADOC Testing Service for Eggplantの概要へ
■ ADOC Testing Service for Eggplantの資料請求へ

「ローコード」で変わるテスト自動化プラットフォーム の記事一覧

「ローコード」で変わるテスト自動化プラットフォーム

  • 2022.1.14
  • 【第4回】:ローコード開発適用のための最適解とは

BLOG シリーズ 一覧