本記事では、Autify ConnectとURL置換という2つの機能を使って、Autify NoCode Webでシフトレフトテストを推進するテクニックについてご紹介します。

• QAエンジニアとして、シフトレフトテストを推進し、早い段階から開発にかかわっていきたい
• 開発者として、Autify NoCode Webによるテストをローカル環境での開発時にも活用したい

このような方に役立つ内容になっています。

本記事で利用する機能

本記事で利用するAutify NoCode Webの機能の詳細は、以下のガイドをご確認ください。

• Autify Connect概要ガイド | Autify Guide
• Autify URL置換ガイド | Autify Guide

なお、Autify CLIを利用することで、シナリオ単体でのAutify Connectの利用など、さまざまな便利な機能にアクセスできます。Autify Connectの利用には、Autify CLIを活用することをお勧めいたします。

シフトレフトテスト

シフトレフトテストという言葉は、文脈によってさまざまな意味を持つ言葉ですが、ここでは、開発プロセスの早い段階で、コンピューターによる自動化されたテストを行うこととします。開発の時間の流れを左から右に流れで捉えたときに、なるべく左(早期)にシフトするのでシフトレフト、というわけです。

よくあるウェブシステムの実行環境のモデルとして、ローカル環境、ステージング環境、プロダクション環境の3つを持つというモデルがあります。

• ローカル環境は、開発者のローカル開発マシンで動く環境
• ステージング環境は、チームが共通して使うシステムの検証のためのもので、プロダクション環境とほぼ同等の環境
• プロダクション環境は、ユーザーが実際に使う環境

Autify NoCodeの開発もこのような構成で行っています。

このモデルの元で、コードベースがデプロイされていくパイプラインを図にすると次のようになります。

最も典型的なAutify NoCode Webの利用方法のひとつは、プロダクション環境へのデプロイ前に行われる、ステージング環境での回帰テストです。ここでテストを行うことで、デグレードがないことを確認した上で安全にリリースが行えます。

ステージング環境用に作成したテストシナリオですが、実は、Autify NoCode WebのURL置換を使うことによって、そのままプロダクション環境など別の環境で実行することができます。

先程のデプロイパイプラインに即してこのテストを図示すると次のようになります。ステージング環境でのテストは、意味合いとしてはリリース前の不具合をキャッチするための回帰テストでした。一方で、プロダクション環境のテストは、システムのモニタリングという意味合いが強くなります。プロダクション環境でのさまざまな側面に焦点を当てたテストアプローチは、シフトライトテストとも呼ばれます。この意味で、URL置換を利用したプロダクション環境でのテスト実行は、シフトライト的なAutifyの活用法であると言えます。

筆者自身の毎日の仕事も、まずは朝出社して、プロダクション環境でのテスト結果を見ることからはじまるのですが、これがすべて緑(成功)になっていると、とてもすがすがしい気持で一日をはじめられます。また、プロダクション環境でのテストを通じてシステムの異常を早期に検知できたことも何度もあります。

さて、今度は反対側のローカル環境を見ていきます。ローカルネットワーク内の開発環境は、インターネットからアクセスすることはできないため、通常、Autify NoCode Webを使ったテストを実行することができません。しかし、Autify Connectを使えば、それが可能になります。

Autify Connectは、テスト実行環境で実行するソフトウェアです。Autify Connectを使うと、任意のネットワーク環境とAutify実行環境のネットワークが、セキュアなコネクションで直接繋がります。

このテクニックを使えば、まだどの環境にもデプロイしていない段階で、テストシナリオを作成および実行することができます。これは、開発中の機能をコードレビューに出す前のセルフチェックなどに有効です。

また、先程のプロダクション環境の場合と同様に、ローカル環境で作成したテストシナリオをURL置換を使って、ステージング環境とプロダクション環境の両方で再利用することも可能です。

以上で、シフトレフト的に早期に作成したテストシナリオを、まず開発者のセルフチェックに役立て、次にプロダクション環境へリリースする前のリリース判断に利用し、最後にプロダクションリリース後のモニタリングにまで活用するというパイプラインを構築することができました。

ポータブルなテストシナリオ

前節で説明したのが理想的な状況でのAutify NoCode Webの運用ですが、これを可能とするための前提条件や注意点がありますので、この節で解説します。

テストの実行には、ほとんど必ずリソース(データ)が関わります。たとえば、ユーザーというリソースについてのテストを考えてみます。「ユーザーの名前を更新する」というテストシナリオでは、

1. ハロルド・ハイブクラフトという名前のユーザーを環境に作成する
2. ユーザーの名前がハロルド・ハイブクラフトであることを確認する
3. ユーザーの名前をオリバー・ゴールデンハニカムに更新する
4. ユーザーの名前がオリバー・ゴールデンハニカムであることを確認する
5. (次のテストに備えて)当該ユーザーを削除する

という4つのステップからなります。テストリソースのライフサイクルは、作成、利用、削除という一連の流れで整理することができるでしょう。このように、必要なリソースの作成から削除までの一連の流れを、それ自身に含むテストシナリオを、本記事では「ポータブルなテストシナリオ」と呼ぶことにします。

しかし、ユーザーの作成操作が、なんらかの事情によりE2Eテストで自動化できない場合、どうなるでしょうか。たとえば、ユーザーの作成には物理デバイスを絡めた認証登録が必須で、自動化が難しいような場合です。その場合でも、あらかじめテスト用のリソースをデータベースに手動で追加する、あるいはプログラム的に作成しておくなどの方法で、「ユーザーの名前を更新する」というテスト自体は実現できます。その場合、テストシナリオ自体にはリソースの作成が含まれません。「ユーザーの名前を更新する」テストシナリオは、次のようになるでしょう。

1. ユーザーの名前がハロルド・ハイブクラフトであることを確認する
2. ユーザーの名前をオリバー・ゴールデンハニカムに更新する
3. ユーザーの名前がオリバー・ゴールデンハニカムであることを確認する
4. (次のテストに供えて)ユーザーの名前をハロルド・ハイブクラフトに戻す

こうなると、環境ごとにテストリソースの準備が必要になってしまい、データ管理のために余計な手間がかかってしまいます。これを、前節で説明したURL置換により共通化されたテストシナリオを前提として整理すると、次の表のようになります。

‍

‍

シナリオを複数環境で走らせるという本記事の観点からは、テストシナリオはなるべくポータブルになるように作成するのが理想的です。では、ポータブルなシナリオを実現するための前提条件とは何でしょうか? これは、テスト対象のリソースが、CRUD(Create, Read, Update, Delete)のうちすくなくともCとRとDを供えていることです。たとえユーザー向けの機能としては全部が揃っていなかったとしても、E2Eテスト用のデータ追加・削除用APIなどがあると、簡潔で管理のしやすいシナリオを実現でき、より効果的なテストを実現できる見込みが高まります。

まとめ

Autify NoCode Webでは、URL置換機能を使うことで、一つのシナリオを複数の環境に対して実行できます。また、Autify Connectを使うことで、テストの作成・実行を開発者のローカル環境にまで拡張でき、テストシナリオという資産を、開発者のセルフチェックのためにより早い段階から活用できます(シフトレフト)。また、テスト対象のリソースに対するCRUD操作を可能にすることで、ポータブルなテストシナリオを実現でき、複数環境にまたがったE2Eテストの効果を最大化できます。

‍