【翻訳】ローコード自動テストのためのmabl社版ピアレビュー・ガイドライン

11月〜12月にわたり、自社プロダクトに対してmablでE2Eテスト自動化を試みるトライアルを実施しました。
mablのおかげでテストの実装自体は非常に簡単になったため、
テストの全体戦略や、テストをどう維持していくかというメンテナビリティを担保するしくみを検討するのに時間を割けるようになったと実感したというのは拙訳「【翻訳】あなたのE2Eテストの威力を最大化させる6つの戦略」でも述べたとおりです。

さて、今回はメンテナビリティの維持のしくみとして、mablブログよりピアレビューに着目した記事「Peer Review Guidelines for Low-code Automated Tests」を翻訳しました。

まずはこのチェックリストを適用可能にするために命名規則やレビューのフロー等を整備し、
慣れてきたら各自のプロジェクトでテーラリングしてチェック項目を追加・削減するのがよいでしょう。
mablのシステム構成に依存する項目が含まれているので、Autifyなど他のAI自動テストツールで使う際はツールの構成にあうようチェックリストを修正してみてください。

※注
ISTQB GLOSSARY Ver3.2(及びその出典であるISO20246)ではピアレビューは下記のように定義されています。

peer review
Ref: After ISO 20246
A type of review of work products performed by others qualified to do the same work.
ピアレビュー（peer review）
同じ作業を実施できるスキルを持つ他の人が成果物をレビューするレビュー方法。

またICSQB(SQuBOK)でもピアレビューに関する記載がありました。
SQuBOKにはレビュー技法の対比がJSTQB参考書に比べ詳細に書かれていた記憶がありますので、
レビューにご興味のある方はまずSQuBOKを参照されるとよいかもしれません。

翻訳

はじめに

ピアレビューは、ソフトウェアの品質を向上させる上で重要な役割を果たします。現代のソフトウェア開発において、ピアフィードバックと承認は、コードベースの品質を管理する上で最も強力なツールとなるのです。mabl社では成果物（コード、ビジネス要件、ユーザーストーリー、アーキテクチャ、設計、テストケース、自動テストなど）のすべてにおいて、ピア・フィードバックを頼りに、社内の考え方を成長させ、進化させています。

近年、Seleniumのような従来のスクリプトベースのフレームワークに代わるものとして、mablのようなローコードテスト自動化ソリューションが登場しています。これらのソリューションは、「キャプチャ&リプレイ」のテストオーサリングを使用して、自動テストの作成と保守を行うことができる人を増やしています。

mablのような先進的なローコードソリューションは、自動テストの作成と保守にかかる時間を劇的に改善するために斬新なアプローチを採用しています。しかし、ローコードテスト自動化のメリットを十分に享受するためには、専門的な知識と先進的なプラクティスの認識が必要です。ピアレビューは、チーム全体の関連知識を向上させながら、テストの品質を向上させるのに役立つ素晴らしいプラクティスになります。

私たちのチームは3年以上にわたり、自社の製品やウェブサイトのテストにmablを使用しており、お客様のローコードテストの改善を支援するために多くの時間を費やしています。私たちのレビューガイドラインを共有することで、お客様のテストレビューの改善にお役に立てればと考えています。

mabl社のピアレビュー・ガイドライン

テストのタイトル、説明、メタデータをレビューする

• テストのタイトルはちゃんと内容を説明するものになっているか? テストの対象となる機能やユーザージャーニーは明確か?
• テストは命名規則に従っているか? テストスイートが非常に大きくなったとしても、チームメンバは検索からすぐにそのテストを見つけることができるか？
• テストの目的を理解するのに十分な記述か? ユーザーストーリー、テストケース、BTSチケットなどとの連携について、社内ガイドラインに従っているか？
• テストは main/master以外のブランチに対して保存されているか? また保存すべきか?
• テストはラベリングのルールに従っているか? 例えば、そのラベルはテストの種類(スモーク、バリデーション、APIなど)、アプリケーションの領域、または機能を示しているか?
  • ラベルを使用して、特定のタイプや機能のすべてのテストをトリガーしたり、機能ごとにテストカバレッジを分析したりしたい場合があることを覚えておいてください。

各テストステップの説明をレビューする

• テストステップの説明はすぐ分かるか? ステップの目的が明確に伝わるか?
  • もしそうでない場合は、ステップの目的を明確にするために注釈を追加または修正する。
• テストはよくまとまっているか?
  • 論理的に分離した方が良い部分があれば、Echo Stepを使用するのもよい。
• 本来変数であるべきハードコーディングされた値はあるか? また、それらの変数は環境変数とする必要があるか?
• 変数の命名規則に一貫性があるか?
• データ駆動のテストになっているか? またデータ駆動にすべきか?

テストを実行してレビューする

• 全てのステップがパスするか?
• 固定長待ち時間、Xpathクエリ、CSSクエリなどのアンチパターンが使用されていないか? もし使用されていれば、使用する理由を説明する注釈はあるか?
• 各ステップはそのステップの目的を達成しているか? False-PositiveとFalse-Negativeの両方を防げるか?
• 実行時間が長すぎるように見えるステップ(群)はあるか? "Wait Until"ステップやその他の変更を入れることで、信頼性を損なわずにこれらを高速化できないか?
• 論理的にアサーションが欠落している箇所はないか? アサーションは不要なのか?

Plan/Environment/Applicationの設定をレビューする

• テストはPlanに設定されているか? 設定すべきか?
• テストは有効になっているか? 有効にすべきか?
• このテストは順次実行するのか、並列実行するのか? テスト間での衝突は発生しないか? どのような場合に、他のテストがこのテストを失敗させたり、逆に失敗させたりする可能性があるか?
• このテストは複数ブラウザで実行されるか? 複数ブラウザでの同時実行は、認証、アプリケーションデータ、その他の問題を引き起こす可能性があるか?
• データ駆動型テストの場合、シナリオの数は十分か? それぞれのシナリオは、テストカバレッジ上意味がある程度に独立したものになっているか?

テストステップを再確認する

• テスト間の冗長性を最小限にするために、ステップを再利用/他のテストと共有できないか? 再利用可能なステップのセット(Flow)を作成すべきか? JavaScriptのスニペットを共有すべきか?
• テストするアプリケーションを準備するための"Setup"ステップがテスト中にあるか? それらはフローに分割すべきか、あるいはそのテストに先立って実行される別のテストに分割すべきか?
• テストは既存のデータを考慮していますか？
• "Teardown/Clean Up"ステップがテスト中にあるか？ 例えば、テストによって作成されたオブジェクトはそのテストによって削除されるか? アプリケーションの設定はデフォルトの状態に戻るのか? テストが失敗した場合でもCleanUpされるように、Teardownステップを別のテストに分割して、今のテストの後に実行すべきではないか?
• どの変数もランダム化するべきか?
• 変数の中には、テスト実行IDやタイムスタンプのような識別情報の恩恵を受けるものがあるか？
• フロー変数、データテーブルの変数、テスト駆動変数が混同されていないか？

全体の構造と実施方法を考える

• このテストは、ターゲットとする機能やユーザーフローに対する効果的なテストになっているか？
• これは本当に1つのテストにすべきなのか? 別々のテストに簡単に分解できないか?
• 他にもテストすべきシナリオがないか？
• main/master 以外のブランチで作業している場合、テストをmain/masterブランチにマージする方法を考えたか? 依存するコードの変更がまだ含まれていない環境においては、テストが失敗するリスクはあるか?
• テストが失敗したらどうなるか? 後続のテストや、他のテストが失敗する可能性がある状態になったままにならないか?
• このテストは、オフにしたりプランから外したりできる既存のテストよりも優先されるか?

おわりに：品質向上のための共有と学習

これらのガイドラインが、ローコードテストの品質向上の一助となり、さらに重要なことに、チーム全体での共有と学習を支援する触媒としての役割を果たすことを願っています。レビューを最大限に活用するためには、チームとして定期的に報告会を行い、一連のレビュー自体をレビューし、そのプロセスを改善する方法を見つけることも検討してください。
mabl社では、ガイドラインへのフィードバックやトレーニングの要望があればいつでも大歓迎でお待ちしています。

謝辞

藤原大氏、Troy Carter氏, Thomas Noë氏, Jonathan Kuehling氏など、ガイドラインのレビューとフィードバックの追加に時間を割いてくださった皆様に、多大な感謝を示して終わりとします。