人工知能による革新的なAPIテスト

Parasoft のコアミッションは常に1つ――すなわち、テストの自動化をシンプルにすることです。これは静的解析からサービス仮想化による環境シミュレーションまでの Parasoft ツールスイート全体にはっきりと表れています。しかし、このシンプルという概念を SOAtest の最新のリリースほどよく表すものは、これまでにありませんでした。今回のリリースでは、組織が単にAPIテストを始めるのではなく、スケーラビリティと保守性の高いAPIテスト戦略の基礎を築くのを支援することで、APIテストから複雑さを取り除きました。

シンプルな声明：make it easy

当社のCEOであるElizabeth Kolawaは、この革新的なテスト自動化のアイデアを生み出す際の議論において、シンプルなガイドラインを示しました。それは「make it easy」でした。 このシンプルな声明が、現在のテストにまつわる課題を深く分析することにつながり、重要な認識をもたらしました。つまり、ソフトウェアテスト業界のツールは、これまでアジャイルの世界のシンプルさにフォーカスしてこなかった、という事実です。

アジャイルは、何よりもまず開発にフォーカスした活動です。最も基本的な定義では、アジャイルとは、従来はプロジェクト期間全体に広がっていた典型的なSDLC活動を、スプリントと呼ばれるより小さな断片に分割するというソフトウェア開発方法論です。通常、スプリントは2〜3週間で、スプリントの開発アクティビティは新機能および拡張機能にフォーカスされます。

1つのスプリントは次のようになります。

スプリントは設計および作成フェーズから始まります。ここでは、新しい機能がユーザーストーリーに分割され、スコープが定義され、すぐに構築が始まります。スプリントの終わりには、リリースアクティビティが発生する場合も発生しない場合もありますが、どちらの場合もフィードバックが得られた後に別のスプリントが始まり、このプロセスが何度も繰り返されます。

アジャイルでは、各スプリントで収集されたフィードバックを次のスプリントに適用し、プロジェクトを導き、計画し、フォーカスを決定するのに役立てることができるため、組織は小回りが利くようになります。これは開発にとっては非常に好都合ですが、スプリントのテスト部分に着目すると、状況はそう単純ではありません。

テストチームは、スプリントが始まってからしばらく経たないと、新機能や拡張機能をテストできませんが、それにはもっともな理由があります。テストチームは、開発チームが機能を完全に構築し終えるまで待つ必要があるため、最初からテストは開発に少し遅れています。

テストが開発に追いつけない

この問題は、スプリントが進むにつれてますます大きくなります。なぜなら、アプリケーションの検証に使用される最も一般的なテスト手法は、ユーザーインターフェイスを手動で操作することだからです。これはUIテストと呼ばれ、実施しやすいために、最も一般的なテスト方法です。UIのアクションをユーザーストーリーに関連付けるのは簡単ですし、大量のテスターを使って容易にスケーリングできます。また、記録および再生機能を利用して最初にひととおり自動化を行うのは簡単です。

しかし、UIテストには多くの問題があります。

• UIテストの非効率性に起因する隠れたコストがある。 UIテストの最も根本的な課題は、問題を再現する手段としてUIテストが渡されたときに、開発チームが欠陥を修正するのに時間がかかることです。テスターが欠陥発見プロセスを開始するとき、探索的テスト（予期しない動作がないかアプリケーションを系統的に探索するテスト）から始めることがよくあります。欠陥が見つかると、テスターは開発者向けに欠陥を再現する必要があります。これには「再現手順」を書くことが含まれます。開発者がこの指示を受け取ると、テストで使用しているバージョンのアプリケーションを見つけて立ち上げ、UI操作手順を実行します。問題が再現された場合、欠陥の根本的な原因がコードのどこにあるかを特定する必要があります。開発チームがアプリケーションをあれこれ調べて欠陥を修正し、アプリケーションを再ビルドすると、QAがテストを再開します。これにより、ソフトウェアデリバリープロセスがさらに遅れ、パイプライン全体が遅くなります。
• UIテストはアプリケーションを包括的にテストするものではない。 UIレイヤーでのテストは、アプリケーションのプロセスフローをエンドツーエンドで検証しますが、必ずしもシステムの内部全体をテストするとは限りません。多くの場合、アプリケーションに新しい機能が導入されると、既存のインターフェイスを変更または更新する必要があります。変更された既存のコンポーネントのなかには、新しい機能を使用するときにアクセスされないものもありますが、これら変更されたコンポーネントがテストされないままであると、重大なリスクをもたらします。
• テストチームにはコードへのアクセス権がないため、自分たちがUIで実行しているアクションをソース コードと関連付けるのが難しい。 結果として、作成されたテストでは完全なAPIカバレッジを達成できません。頻繁に問題が見過ごされることになります。完全な回帰サイクルを実行するときになって初めて、重大な欠陥が発見される可能性があります。多くの場合、このようにサイクルの遅い段階で欠陥が検出されることにより、リリースが大幅に遅れ、テストの総コストが上昇します。
• UIの自動化のメンテナンスが困難。 テストが開発に追いつくのに苦労する一番大きな理由は、壊れたUIテストへの対処に時間がかかり過ぎるためです。現実として、テスト時間の最大で80％までが、UIテストを手動で実行するか、アプリケーションの変更によって壊れた自動UIテストを修正するのに費やされます。

上記の要因は、どれか1つを取っても、スプリントの大幅な遅延につながる可能性があります。また、従来のプロジェクトサイクルを考えると、一連のスプリントの後に品質強化または回帰テストのサイクルが続くことになるでしょう。サイクルの各段階で、テストは必死で開発に追いつこうとしますが、従来型のテスト技法を使用しているために、必要な総合テストを完全に完了することはできません。

新機能を検証することはできても、完全なテストカバレッジには達しないのが通常です。

これは多くのテスターに​​とってはしゃくに障ることですが、彼らの落ち度ではありません。市場に存在するツールの能力を考えれば、あたりまえの対応にすぎません。危険なのは、これらの品質プラクティスがなければ、欠陥が本番環境にまで持ち越され、アジャイルによって得られた利益を食いつぶしてしまうことです。

APIテストはアジャイルを救うか？

アナリストも業界全般も、APIテストがUIテストよりも欠陥の根本原因を正確に特定できるという見解で一致しています。なぜなら、APIテストはよりコードに近く、自動化が容易で、アプリケーションの変更に強いからです。また、APIテストは開発チームとテストチームの間で欠陥の再現と伝達をより適切に行う手段を提供します。APIテストの成果物は、開発とテストという2つの領域を集約します。

最近のブログで私は、APIテストについて、その概要と、包括的なAPIテスト戦略を構築する方法について説明しました 。この記事をお読みいただくと、APIテストという非常に効果的なテストプラクティスに関する詳細がわかります。

APIレイヤーでのテストは、過密なタイムラインでもテスターが機能を検証できるようにします。また、APIテストは再利用可能なため、アジャイルにとってはとくに有益なプラクティスです。さらに、APIテストには次の利点があります：

UIテストと比較した欠陥修正までの時間短縮

APIテストが失敗したとき、だいたいコードのどこを調べればよいかは、ほぼ確実にわかるでしょう。APIテストであれば、環境全体を準備しなくてもアプリケーションに対して直接テストを実行できるため、開発者はテストチームからAPIテストを渡されるのは大歓迎でしょう。そして、欠陥の修正に手を付けた後も、開発者は継続的にAPIテストを実行することができます。

欠陥修正の時間が短縮されるとは、一般に、UIテストではなくAPIテストが提供された場合、開発チームはバグをより早く修正できることを意味します。アジャイルのタイムフレームを考慮すると、これこそ必要なものです。欠陥が発見されると、APIテストが開発チームに提供され、開発者はそれを利用して欠陥の発見、修正、検証を行うことができます。この間、アプリケーション全体を再ビルドする必要はまったくなく、膨大な時間を節約できます。これはまさにアジャイルに求められる種類のスピードです。

APIテストは「即オートメーション可能」

APIは、アプリケーションの各場面の裏側で行われる目に見えない通信を表します。通信が目に見えないという特徴は、自動化プロセスには有利です。アプリケーションをUIレベルで操作できるように全体を立ち上げるより、APIレベルで通信を開始できるようにするほうが、はるかに簡単です。

つまり、APIテストはSDLCの初期段階で簡単にオートメーションの一部として実行できます。私の顧客のほとんどは、コードチェックイン時に単体テストを実行すると同時にAPIテストを実行しています。APIテストの実行は、バグ追跡システムと簡単に関連付けることができ、欠陥が解決されたとき、関連するAPIテストを開発チームとテストチームの間で簡単にやりとりできます。テストチームは、欠陥のチケットを発行し、再現手順を提供し、開発から新たなビルドが提供されるのを待つ代わりに、バグ追跡システムから欠陥が解決されたという通知を受け取り、自動化されたテストケースによって修正が検証されるのを確認すればよいので、連携プロセスが大幅に簡略化されます。これらのAPIテストは、簡単に回帰テストスイートに組み込み、何度も再利用することができます。

APIテストは、UIテストよりも変更に強い

Parasoft による調査では、開発時間の80％が、変更の結果として壊れたUIテストの管理と更新に費やされていることがわかりました。ことアジャイルに関して言えば、変更は時間を食う大きな要因ですが、コードチェックインが増え、アジャイルに伴ってタイムフレームが短縮されるため、変更は常に発生します。

組織がUIテストだけに依存している場合、アプリケーションの変更によって、重要な機能を検証するために構築されたテストケースの多くが機能しなくなる可能性があります。アジャイルの大原則の1つは、すみやかに方向転換できる能力です。これは、UIと機能が常に変化しており、テストをサポートし維持する負担がテストチームを制圧してしまうことを意味します。一方、APIテストではUIは表示されることもありません。 APIにはもともとバージョン管理機能も備わっているため、アプリケーションが変化していても、テスターは安定性を維持できます。さらに、APIはサービス契約で定義されているので、アプリケーションが変更されたとき、サービス契約を利用してテストケースを更新することができます。

APIテストはアジャイルを救います。APIテストは開発の初期段階でアプリケーションを簡単にテストできるだけでなく、開発とテストの間で効果的なコミュニケーション手段を提供するため、変化に非常に強いのです。APIテストをテスト戦略の基本的要素として採用している組織は、アジリティを活用して、テストの課題を楽にクリアできます。

それなのに、なぜAPIテストは行われないのか？

このようなAPIテストのメリットにもかかわらず、業界ではまだUIテストばかりが行​​われています。これは、テスターがAPIのテスト方法を知らない、またはアプリケーションでAPIがどのように使われているかを知らないためです。アプリケーションのAPIテストを開始するにあたって、どこから手を付ければいいのかは、すぐにはわかりません。また、すべての「パズルのピース」を意味のある方法で組み立てる方法を理解するには、アプリケーションのドメイン知識が必要です。組織は依然として集中的なテストに頼りがちな傾向があるため、テスターはすべてのアプリケーションインターフェイスの詳細な知識を必要とし、それらを適切につなぎ合わせる方法を知らなければなりません。それは簡単な仕事ではありません。

APIテストは未開拓の土地とみなされています。私たちは最近の調査で、組織のAPIテストを担当する開発者とテスト担当者に質問をしました。

• テスターの70％は、 開発チームがAPIテストを担当していると述べています。
  • 理由「APIを作成したのは開発チームなので。また、APIを開発するときに、記述どおりにAPIが動作するかを検証するためにAPIテストを作成したはずなので」
• 開発者の80％は、テストチームがAPIテストを担当していると答えています。
  • 理由「私たちはAPIを外部に向けて作成し、サービス契約を文書化しました。今度はテストチームが、記述どおりAPIが動作するかを検証するべきです」

ご覧のとおり、最終的に誰がAPIテストを担当するのかについては混乱があります。私たちはこの問題を解決したいと考えています。APIテストは開発者とテスト担当者の両方が関与し、それぞれ違った方法で力を合わせるべきだというのが私たちの考えですが、現実にはこのような分断があることが、APIテストのカバレッジが低い理由です。

APIレベルのテストで包括的なテストカバレッジを達成するには、特別なスキルとツールが必要です。それは直感的には理解しにくいものです。組織がAPIテスト戦略を構築するのを手助けすることを意図したツールは、現に市場にも存在しますが、その多くは包括的なAPIテストを構築するために高度な技術専門知識を必要とします。さらに、テスターは、APIの仕組みを理解する必要があります。それにはドメイン知識も必要です。結果として、組織はAPIテストに関しては最小限の労力で済ます傾向があります。これは、アジャイルに必要なテストとはまるで逆です。

SOAtest/Virtualize 製品ページへ >

人工知能によるテスト自動化

なぜAI、それもなぜ今なのでしょうか？上で述べたような業界全体に関わる問題を解決する唯一の方法は、APIテストから複雑さを取り除くツールを作ることです。私たちは30年にわたりソフトウェアテスト自動化の分野に取り組んでおり、その間、包括的なAPIテストを構築するために何が必要かを理解するのに役立つ多くのデータを蓄積してきました。今日、人工知能は、蓄積された知識を活用して、業界全体のテスターが直面するAPIテストの課題を単純化するのを支援しています。

Smart API Test Generator

Parasoft が新たに開発した Parasoft SOAtest Smart API Test Generator は、当初からAPIテストの複雑さを軽減するために構築されました。Smart API Test Generator は、人工知能を使用して手動UIテストを自動化されたAPIテストに変換するChrome用プラグインです。このプラグインは、APIテストの導入に必要な技術スキルを引き下げ、企業が拡張性のある包括的なAPIテスト戦略を構築できるように支援します。

では、その仕組みを紹介しましょう。

UIアクティビティを自動APIテストに変換

Smart Generator は、手動テストの実行中にバックグラウンドトラフィックを監視し、そのトラフィックを分析し、人工知能を使用して有意義なAPIテストシナリオを自動的に構築します。APIテストを構築する際、Smart Generator はまずAPIコールを識別し、パターンを検出してパターン間の関係を分析するので、単なるAPIテストではなく完全なAPIテストシナリオを生成できます。

APIテストの習得時間を短縮

テスターは Smart Generator を使ってAPIテストの構築を簡単に開始でき、手動でAPIテストを構築する場合のように難しい作業を行う必要がありません。つまり、正しいサービス定義を探したり、データペイロードを理解したり、またはテストを何度も実行してリクエストとレスポンスの関係を理解したうえでアサーションを作成したりする必要はありません。

Smart Generator は、テスターがUIを操作している間に観察されたアクティビティに基づいて、面倒な作業をすべて自動的に行います。これによって、経験の少ないユーザーも、自然にAPIテスト全般に関する理解を深めることができます。UIで実行したアクティビティと作成されたAPIテストを比較して、UIとその背後にあるAPI呼び出しとの関係をより深く理解することができるため、その後のAPIテスト作業に役立ちます。

包括的なAPIテスト戦略の構築を支援

APIテストは非常に効果的なテストプラクティスの1つですが、特別なスキルとツールを必要とするため、多くの組織はこのプラクティスをうまく導入できていません。Parasoft SOAtest は、包括的なAPIテストプラクティスの導入を支援するため、敷居の低いビジュアルツールを提供し、APIテストの初心者でも、他のツールを使用する場合に比べて短時間で強力なAPIシナリオを作成できるようにします。Smart Generator はギャップの橋渡しをし、初心者のユーザーをAPIテストの世界に導きます。

結論

アジャイル開発は、組織が高品質なソフトウェアをより早く市場に投入するのに役立ちますが、組織がアプリケーションを迅速に完全にテストできるようにする技術がなければ、短期化したデリバリーに伴うリスクがアジャイルの潜在的な利益を損なうことになります。今こそ、スマートにAPIテストを行うべき時です。

確かなAPIテスト戦略があれば、企業はアジャイルへの転換によって最大の価値を引き出すことができます。これを実現するには有効なテストツールが必要で、Parasoft SOAtest の最新版は、まさにこの目的に適うツールです。SOAtest の新しい Smart API Test Generator は、APIテストに伴う複雑さを軽減し、APIテストを採用する障壁を低くし、組織が管理かつメンテナンスが容易でスケーラブルなテスト戦略を実現するのに役立ちます。

（この記事は、開発元Parasoft社 Blog 「Revolutionizing API testing with artificial intelligence」2018年5月1日の翻訳記事です。）