「風説」の検証　Part2：テスト編　～　Panayaの真実をお伝えします

さて、まず始めにPanayaのテストツールの歴史についてお話しておきたいと思います。

Panayaは2006年にイスラエルでスタートし、SAP ERPのアップグレードにおける影響をわずか48時間で自動解析する革新的なソリューションで市場に大きなインパクトを与えました。しかし、テスト工程には依然大きな課題が存在していました。そこでPanayaはSAPプロジェクトにおけるテストの課題を徹底的に調査し、2013年にテストソリューションをリリースすることとなりました。

当時SAPの世界でテストツールと言えば、SAP社がOEMとして販売していた自動テストツールを多くのお客様が保有していたのですが、テスト工程の課題が解決されることはありませんでした。

それはなぜだったのでしょうか？

まずSAPというビジネスアプリケーションの特性により、頻繁にカスタマイズ変更が入ることでユーザーインタフェースも変更されるため、それに応じて常に自動テストスクリプトをメンテナンスする必要がありました。この作業には膨大な維持コストがかかります。

さらに、SAPの多くのテストケースでは人間の判断が必ず必要であり、どのようなテストツールであっても自動化がそもそも困難であるケースも頻発しました。

当時も多くのお客様がチャレンジされたようですが、これらの要因によってテスト自動化はすぐに破綻してしまい、結局テスト工程では人海戦術や多くのマニュアル作業が長く放置されることになってしまったのです。

そこで、Panayaは全く新しいテストツールのコンセプトを打ち出しました。

①「テスト実行の作業」よりも 「テストの付帯作業」にフォーカス

②「テスト自動化」は「あえて半自動」にすることで変更に柔軟に対応

③「テストエンジニア」のためのツールではなく「ビジネスユーザー」でも扱えるツール

「テストの付帯作業」とは、テスト証跡の文書化、進捗管理、障害管理、などにまつわる作業の事です。例えば、テスト証跡の文書化は、テスト作業時に毎画面エクセルなどにコピー・ペースト・入力値・操作内容などを記載するような作業になりますが、調査の結果、なんとテスト実行の約２倍以上も時間を要していました。また、テスターがタイムリーに情報を連携できずに、次のテスト作業に入れないような「アイドルタイム」が積み重なることで重大な遅延を引き起こすことも大きな課題になっていました。

Panayaではテストを「自動的」にキャプチャーして文書化する仕組みや、テストプロセスを「自動的」に監視して担当者が適切に通知を受け即応できる仕組みなどを備えています。このように「自動化」の領域やコンセプトが異なるため、 “Test Automation”ではなく、”Test Acceleration”と名付けていました。

しかし、製品リリース当時はテストツール＝”Test Automation”というイメージがどうしても強く、この違いを理解いただくことはとても困難でした。ようやく10年が経ちグローバルでもP＆G、ABB、資生堂、東京エレクトロンといったユーザー様に長年ご利用いただいており、私たちが訴えるコンセプトがだいぶ認知されてきたと最近感じています。

すっかり前置きが長くなってしまいましたが、他社さんのPanayaに対する主張を検証して参りたいと思います。

（改めて製品リリース時からの歴史を振り返りますと、今では様々なテスト専門会社さんからもPanayaをコンペティターとして引き合いに出して頂けるようにもなり、感慨深い限りです。）

主張１：Panayaはマーケットで認知されていない・・・

Gartnerなどに名前があがっていないことを仰っているのかと思われます。Gartner のMagic Quadrant（Gartner社がまとめた市場ポジションの比較表）に“Software Test Automation”というカテゴリがありますが、確かにここにはPanayaの名前はありません。しかし、申し上げた通り私たちのツールは”Test Automation”ではありませんので、このカテゴリに属していないのは当然のことと思います。なお、ここではテスト対象のアプリケーションはSAPやその他のビジネスアプリケーションに限らず、かなり広範囲なものを対象にしていますので、SAPユーザーがこの情報を元に判断するのはかなり危険な事かと思います。

個人的には「アナリスト」の評価よりも「エンドユーザー」の評価を優先して聞くべきであると思います。G2におけるPanayaのレビューをご覧ください。（G2はアナリストレビューではなく、実際に使用しているIT担当者などの個人レビューにフォーカスしています。）

他社ツールとの比較検討が必要な場合は、”Test Automation”ではなく”Test Management”というカテゴリにおいて比較頂くのが適切かと思います。G2のEnterprise Test Management Softwareカテゴリにおいて、PanayaはLeaderと認定されています。（https://www.g2.com/categories/test-management）

またG2による他社ツールとの比較もございますので、ご参考までに。

（https://www.g2.com/compare/panaya-change-intelligence-vs-tricentis-tosca）

主張２：Panayaのテスト自動化機能は貧弱である・・・

テスト自動化機能の優劣のみで比較すれば、はいそうですね。半自動ですから、、、と言わざるを得ませんが、その前にテスト自動化によって本当にお客様の課題解決になるのか？を十分に議論して頂きたいと思います。

私たちの調査ではSAP ERPにおいて自動化が可能な領域は多くて2－3割程度であり、その自動化が仮に上手くいったとしても「手動テストは大部分残る」ことになります。特にS/4 Green Fieldなどの新規導入のプロジェクトでは、自動化対象になるような全く同じデータ、シナリオかつ同じ結果になるテストを何度も繰り返すようなケースはまず皆無でしょう。

従いまして、SAPプロジェクトにおいてはテスト自動化機能の優劣の比較ではなく、その「大部分の手動テストの課題」などの「本来の課題」の解決に対して有効なのかどうか？を軸に据えて考えることが大変重要です。

誤解なきようお伝えしますと、Panayaはテスト自動化そのものを否定しているわけでは全くありません。自動車の自動運転技術などもどんどん進化して無人運転もいずれは現実のものとなりつつありますから、テストの世界でも将来的にはそのような方向に進むであろうと考えています。

Panayaは常にテスト自動化のあるべき姿を追求し続けており、今後のロードマップではPanayaも全く新しいテスト自動化エンジンをリリースする予定となっています。AIなどの技術の進化により、いよいよ機が熟したと判断しており、今後は「自動テスト、手動テストのバランス」をより最適化し、更なる効率化を目指せると考えています。

※もう間もなく具体的なお知らせができると思います。（2023年9月末現在）

主張3：Panayaは他のツールとインテグレーションができない・・・

最近聞いた話では、他社さんではテストツールと影響分析ツールや他のマネジメントツールとの連携機能を強みとしている、一方PanayaはWorksoft（テスト自動化ツール）としか連携できないので優位性が極めて低い、、、とのことでした。

まず「連携」を議論する場合、何のデータを？どのレベルまで？どのタイミングで？そもそも何のために？といった点を明確にせずに、単に連携できるソリューションの数を競っても全く意味はないでしょう。ただ単に別々のシステムにデータが連携されているのと、同じアプリケーションの1画面に必要な情報が全て連携されているとは大きな違いです。

そもそも他社さんの場合はテストツール、影響分析ツール、マネジメントツールがそれぞれ全く別々のツールとして存在しているがために連携が必要となってしまうのです。Panayaの場合は一つの製品としてテスト、影響分析、マネジメントなどの機能がワンストップで完全に統合されているので、通常のご利用では別の何かと連携をさせる必要性自体が発生しません。

例えばPanayaでは、影響分析結果による修正箇所、それによって必要なテスト対象の情報、そのテストが関連するテストシナリオ、そのテストの進捗ステータス、実際のテスト証跡、障害履歴、、、などなどがデジタル情報として全てリアルタイムに連携されていますので、多くの関係者でタイムリーに共通認識を共有し、プロジェクトマネージャは適切に状況を把握し判断することが可能です。（そこは何となくERPと似てますね。）

なお、Solution Managerとの連携などは、主に海外のエンドユーザーのニーズに応じて機能を追加していますが、現状日本のお客様ではこういった他ツールとの連携に関しての強いご要望などはあまり聞こえてきません。

私たちは正しいデジタルツールの活用によって、お客様のSAPプロジェクトのDXが実現されることを強く願っています。このブログが少しでもお客様の意思決定の一助になれば幸いです。

最後までお読みいただきありがとうございました。