Jenkinsの開発者でCloudBees元CTOのKohsuke Kawaguchi氏は先日のブログ記事で、自身のCTO退任と、マシンラーニングによるテストと継続的デリバリの最適化にフォーカスしたスタートアップであるLaunchableの共同創立を発表した。マシンラーニングを導入した理由として、Kawaguchi氏は、開発者がリスクベースのテストを適切に実施し、出荷するソフトウェアの品質と影響を明確に把握する手段となるような、定量的な指標の提供を支援することを挙げている。"Why Test Automation Is Not Continuous Testing"と題した記事を先頃発表した、TricentisのRobotic Process Automation担当マネージャであるWayne Ariola氏は、継続的デリバリによってテスタに課せられる、リスクベースの稼働開始判断をより早く行うことへのプレッシャについて記している。
多くの分野が従来の"感と度胸に頼った決断"から"定量化可能なメトリクスとモデルに移行することにより、まったく新しい角度からのプロセス/効率改善を実現している"、とKawaguchi氏は説明する。これとは対照的に、ソフトウェア開発のプラクティスは、依然としてテストやリリースの決断を"個人の経験や信念、直感"といったものに頼っているとした上で、氏は、Lauchableの主要テーマを次のように説明する。
コード変更に対して、どのようなテストを行えばレグレッションをより正確にキャッチできるのか、私たちは、十分な精度を持って予測することができます。それはとりもなおさず、開発者へのより迅速なフィードバックへとつながるのです。
DevOpsのプラクティスによって、"それまでの2週間毎から、1日に数千回"のデリバリというケイデンス(cadence)が可能になった、とAriola氏は言う。"ソフトウェアテスタの扱うアプリケーションがますます複雑化する一方で、現代のビジネスの持つ新たなスピードで、信頼できるgo/no-go判定を行うことが求められているのです。" このニーズを満足するために、"ソフトウエアリリースに関わるビジネスリスクを可能な限り早くフィードバックする"ことを目標としたCIパイプラインで、"継続的テスト"を使用するのだ、と氏は説明している。
Lauchableでは、公開ベータテストへの参加者を募集中である。LaunchableのWebサイトによると、同社のソリューションでは、ソフトウェアに実施された変更によるリスクに基いて、十分な信頼を提供するためのテストサーフェースの特定が可能になるという。これを実現するのは、以下のものだ。
(a) ソースコードが変更された場合の、個々のテストケースが失敗する可能性を予測するマシンラーニングエンジン。これにより、必要性のあるテストのみを実行することが可能になり、結果的にフィードバックの遅れを最小化することができます。
ブログの中でKawaguchi氏は、仮想のシナリオを使ってこの件をさらに詳しく説明した上で、読者に対して、長時間実行するテストシナリオの提供を求めている。マシンラーニングを使って"80パーセントの信頼性を提供する10パーセントのテストを適切に選択する"ことができれば、フィードバック時間を大幅に削減することができるはずだ、というのが氏の提案である。
継続的テストを成功させるには検証だけでなく、"ビジネスリスク"に目標を置いたアクティビティが必要だ、と説明するAriola氏は、その例として、ビジネスアジリティの向上とオートメーションによって、企業の製品に一定の"競争的差別化"を生み出すことができることを挙げる一方で、これが同時に"潜在的故障的(failure point)"の数や種類、複雑性を増やすことにもなる"とも警告し、
ビジネスリスクとテストの価値を理解することが、それらの相関関係を理解することにつながる、と説明している。その方法のひとつが"アプリケーションコンポーネントや要件とリスクをマップ"し、さらに"テストにマップすること"であり、さらにリスク説明とテストケースのメンテナンスとのバランスを確保することも重要だ、次のように記している。
最小量のテストで最大のリスクカバレッジを達成するには、テストスイートを使用する必要があります。
Ariola氏は、継続的なテストアプローチの一部としての視点を欠いたテスト自動化の重視を批判して、多くのチームが"十分な速度ないし頻度で、現実的なテスト"を作成できていないと書いている。そのようなテストでは、"リリース候補のリスクが高過ぎるので、デリバリパイプラインを通じて進行する"ことはできない。さらに、コードベースの定常的な変更に追随する必要もある。氏によれば、
アプリケーションの定常的な変更は、圧倒的な量の誤検知を生み出す結果となり、果てしないとも思われるようなテスト修正が必要になるのです。
LauchableのWebサイトには、同社のMLが"CIシステムのgitリポジトリやテスト結果"からの"洗練された"情報によってトレーニングされている、という説明がある。Lauchableでは、CIビルドに求められる信頼度レベルが得られると同時に、これらの予測がプルリクエストの生成に使用されることで、より速いレビューが可能になり、デプロイメントパイプラインが起動される、としている。
これを前提として、Ariola氏は、リスクのある領域を対象とした十分な範囲のテストを行う必要性について、次のように記している。
問題含みのソフトウェアをエンドユーザに届けるリスクを最小化したいのであれば、必要なレベルのリスクカバレッジとテスト範囲を — 迅速に — 達成するための方法が必要になります。
さらにAriola氏は、"自動テストの範疇を越えたユーザビリティとユーザエクスペリエンスに関する問題"を見つける手段として、手作業による探索的テストも必要だとして、"ユニットテストの失敗やUIテストの成功"といった結果からは、ユーザビリティへの影響から発生する可能性のある評価リスクを知ることはできない、と警告している。
エンドユーザエクスペリエンスを保護するために、アプリケーションの変更がユーザが頼りとしている機能に対して与える意図しない影響を検出する、十分な範囲のテストを実行してください。
より早いフィードバックを得る目的でテストを選択的に実施するプロジェクトについて、Kawaguchi氏は、"スモークテスト"のような"テストの恣意的なサブセット化に頼る場合が多い"が、"そうしたテストはまったくの勘で選ばれているに過ぎない"、としている。これに対して、LanchableのMLによるソリューションでは、"フィードバック遅延を最小化するという目標に対して合理的なテストのサブセット"を提供することが可能である、というのが氏の主張だ。
Launchableのサイトでは現在、間もなく開始されるベータローンチへの参加希望者を募集中である。