SACREDモデルによる信頼性の高い自動テスト構築

自動テストを設計する際には考慮すべき点が数多くあり、それらをすべて頭に入れておくことはしばしば困難です。私はこの課題に直面し、記憶術「SACRED」を作成することで解決しました。

豆知識：この記憶術は当初「SCARED」でしたが、自動化に初めて取り組む人やスキルを拡張したい人にとって魅力に欠けると感じました。スクラブルの単語検索ツールに文字を入力したところ、「SACRED」という単語が返ってきました。すぐにしっくりきました。チームが自動テストを貴重な財産のように扱うというアイデアが気に入っています。

SACREDは、既存のテストを評価したり、新しいテストを計画したりするための自動テストの青写真です。この青写真を使用することは、異なる役割やスキルを持つメンバーを結びつける優れた方法です。例えば、テストの考え方が強い人がテストを設計し、コーディングやツールの使用に長けた人が実装を担当するといった役割分担が可能です。この記憶術は、テストの重要な要素をすべて捉えることができます。また、単独で作業するエンジニアが、自動テストの重要な要素を見逃さないようにするためにも使用できます。

SACRED は完全にユニークというわけではありませんが、自動化について話す際に私が好む表現を使用しており、Arrange Act Assert (AAA) や Given When Then などの他の記憶術では見落とされがちな、自動テストの設計に不可欠な要素も含まれています。

SACREDとは？

SACREDは、自動テストの設計と実装を支援するための記憶術の形式のヒューリスティックです。これは以下の頭文字を表します：

• 状態 (State)
• アクション (Actions)
• チェック (Checks)
• レポート (Reporting)
• 実行 (Execution)
• 決定論的 (Deterministic)

私にとって、これらはデリバリーチームにとって価値のある自動チェックを設計・実装するための基本要素と重要な原則です。これらの要素のいずれかを無視すると、テストの価値が低下します。テストが的を射ない、不安定、または遅すぎてチームに大きな価値を提供できなくなる可能性があります。

SACREDは、そのような状況を予測し、防止するのに役立ちます。

S – 状態

自動テストの多くは、システムにいくつかの条件が整っていることを前提としています。これを「状態」と呼びます。テストを正常に実行するには、システムが特定の状態にある必要があります。状態には、次のようなものが含まれます。

• データ - ユーザー、製品など
• 設定 - 言語、URL、プロパティ
• 機能フラグ
• サイト/API が実行中であること

理想的な状況では、テストは原子性を持つように設計されます。つまり、テストは自身で完結し、既存のデータや前のテストの実行に依存しません。ただし、一部の状況では完全に原子性を保つことができない場合もあります。これは問題ではありません。なぜなら、その点を認識していれば、自動テストの設計に反映させることができるからです。

避けたいのは、テストを特定の順序で実行する必要があり、次のテストが前のテストの結果に依存する状況です。これは実行時の柔軟性を制限し、テストが失敗した際のデバッグを困難にします。

自動テストの状態を設計する際には、以下の質問を検討してください。

• このテストを実行するために必要な既存データは何ですか？
• このテストを実行するために、特定の設定/構成を有効にする必要がありますか？
• エンドポイント/統合に特定の設定が必要ですか？
• このテストを実行するために、どのようなデータを作成する必要がありますか？

A – アクション

アクションは、検証しようとしている動作をトリガーするために必要な手順です。テストケースを書く必要がある場合、ここでのテストステップはコードまたはツールの指示です。ここで重要なのは、テストツールがテストを完了するために必要なすべての指示を提供することです。つまり、システムとのインタラクションを観察し、それをツールに落とし込む必要があります。ステップを省略したり、特定の順序で実行していることに気づかなかった場合、テストも同じミスを犯します。これらのミスが、テストの脆弱性につながる原因となります。

これがUIテストの場合、アクションはクリック、待機、テキストボックスへの入力などになります。APIの世界では、適切なヘッダーとデータでAPIリクエストを構築することになります。ユニットテストの世界では、メソッドの呼び出しやオブジェクトの作成になります。

テストに実行させたいアクションを特定する際の質問例を以下に示します。

• このテストに実行させたいステップは何か、その順序は？
• テストは決定を行う必要がありますか？その決定は何に基づいていますか？
• この動作を完全に理解しており、これらがすべて必要なステップであることを100%確信していますか？

C – コード化されたオラクル

オラクル(判定基準)は、ここに問題があるかどうかを判断する方法であり、人間のオラクルを、固定されたハードコード化されたバージョンに翻訳した（または翻訳しようとした）ものであるため、コード化されています。これらは一般的にアサーションを利用して行います。アサーションを書く際、その日のシステムの動作に対する期待をコード化しています。これがコード化されたオラクルです。テストがこれらの期待から逸脱を検出した場合、テストは失敗します。

私はアサーションではなくコード化されたオラクルについて話すことを好みます。なぜなら、オラクルを満たすために複数のアサーションを作成する必要がある場合があるからです。アサーションはオラクルの実装ですが、真のスキルであり、非常に過小評価されているのは、最初にオラクルを特定することです。以前のパラドックス記事で述べたように、これは手動テストから転用できる多くのスキルの一つです。一部のエンジニアは、複数のアサーションを持つべきではないと信じていますが、私はそうは思いません。オラクルを満たすまでフレームワークを活用すべきであり、場合によっては1つのテストに複数のアサーションが必要になることもあります。

オラクルが曖昧、脆弱、または正しくない場合、問題が発生する可能性があります。悪いオラクルは、偽陽性、偽陰性、または不安定な動作を引き起こす可能性があります。例えば、画面にテキストが表示されていることを確認するアサーションは非常に一般的ですが、このアサーションはテキストのサイズ、色、フォントを確認しません。これらの要素を気にしない場合もあれば、気にするのにオラクルを適切に実装しなかった場合もあります。アプリケーションの技術的な側面を理解している場合は、複数のレイヤーでテストを実装しているでしょう。そうすることで、テストが小さくなるため、オラクルを識別するのが通常はるかに容易になります。

テストで実行する必要のあるアクションを特定する際に、以下の質問を自問してみてください。

• 正確に何をテストしようとしているのですか？
• ページが正常であることをどのように確認しますか？それらをすべてコード化してください。
• 使用しているツールは、オラクルを完全にコード化できますか？

確立されたヒューリスティクスを超えて

前述のように、Arrange Act and Assert（AAA）などの確立された設計パターンは、ここで止まります。これらはテストの作成に焦点を当てていますが、私はSACREDを拡張し、テストの実行と実行、および適切なテストを作成したことを確認するプロセスを含めました。テストから最大の価値を引き出すために、テストをどのように設計すればよいでしょうか？

R – レポート

SACREDでは、レポートには2つの意味があります。1つ目は、実行結果の報告です。2つ目は、特に失敗した場合に、テストが私たちに情報を報告することです。

テスト結果を整理する普遍的な方法は存在しません。一部のチームはテストケース管理ツールに接続し、他のチームは結果をデータベースに保存して時間経過とともに集計し、一部のチームは結果をパイプラインにそのまま残します。これは完全に文脈依存ですが、テストとテストフレームワークに含める必要があります。単純にアノテーションIDを追加するだけでも構いませんが、これを怠るとカバレッジや分析が正確でなくなる可能性があります。

レポートの2つ目の部分を私は「ロボットに声を付ける」と呼んでいます。テストは失敗し、変更を検出します。私たちはそれを望んでいますが、失敗した際にはできるだけ支援してほしいのです。この支援は、スクリーンショット、動画、テストの進捗状況、APIレスポンスのダンプ、コンソールログ、アプリケーションログなど、さまざまな形で提供できます。なぜなら、私たちはテストが失敗した際に何をすべきか知っているからです。ブランチ/最新バージョンをダウンロードし、テストを見つけて実行し、画面を見つめながらテストの実行を確認し、問題を見つけることを願うでしょう。しかし、そのようなことは必要ありません。テストが失敗したことはわかっているのですから、代わりにできるだけ多くの有用な情報を収集し、調査プロセスを迅速化しましょう。これにより、自動テストが提供する貴重なフィードバックをチームが得るまでの時間が大幅に短縮され、パイプラインを早期に健全な状態に戻すことができます。

レポートについて考える際に、以下の質問を自問してみてください。

• テストの名前は明確で、その目的が明確ですか？
• このテストが失敗した場合、デバッグするために必要な情報は何か？
• このテストはテストケースやストーリーにマッピングする必要があるか？
• このテストに、将来のデバッガーの参考になる有用なコメントを含めていますか？

E – 実行

実行は、テストをどのように実行するか、どこで実行するかについて考えるための記憶術です。同じテストを複数の環境で実行する必要がある場合があります。この場合、データ、パフォーマンスの低下、設定の違いなど、環境間の差異に対応するためにテストの変更が必要になることがあります。

次に、テストの実行がどのようにトリガーされるかを考えます。パイプライン上で実行されている場合、テストを実行するためにパイプラインに変更を加える必要があるでしょうか。あるいは、グリーンフィールドプロジェクトでパイプラインが存在しない場合、パイプラインを設定する必要があり、その設定をタスクに含める必要があります。

テストは実行される必要があります。実行されないテストが数十や数百あることは価値がなく、無駄です。

実行について考える際に自問すべき質問：

• このテストはどの環境で実行する必要がありますか？
• このテストを実行するためにパイプラインを変更する必要がありますか？
• 他者がこれらのテストを実行するために、ドキュメントを更新する必要がありますか？

D – 決定論的

これが自動テストの独自性であり、ソフトウェアテストの特定のタスクにおいて人間よりも優れている点です。自動テストは決定論的であるべきです。同じステップを繰り返し、指示から逸脱することなく、常に同じ結果を返す必要があります。

では、自動テストが本当に確定的であることを確認するにはどうすればよいでしょうか？テストを実行します。はい、その通りです。テストをテストする必要があります。

テストをテストする方法は以下の通りです。

• テストを少なくとも3回実行する
• アサーションを逆にして、テストが失敗するかどうかを確認する
• クリーンな環境でテストを実行する

SACREDの実践

実践では、SACREDは頭の中で行うもので、ほとんど書き留めません。これは、他の人に自動テストの設計方法を教えるために作成しました。しかし、最も効果的な方法は、SACREDをテンプレート/キャンバスとして使用し、実装しようとしているテストの青写真を作成することです。これはJIRAチケット、Miroボード、またはペンと紙でも可能です。

SACREDは、ヒューリスティックの一種である記憶術です。ヒューリスティックは不完全です。経験則であり、常に機能するわけでも、すべてを含むわけでもありません。それでも、SACREDは自動化を改善しようとするチームにおいて、非常に効果的であることが確認されています。これらの特徴について考えるためにペースを落とす行為は、自動テストに潜むエラーを減らし、その結果、テストへの信頼性と、それが提供する貴重なフィードバックを強化します。

また、チーム内の役割間のギャップを埋めるための優れたメカニズムとしても証明されています。例えば、あなたはプログラマーではないかもしれませんが、堅牢なテストを設計できます。SACREDを使用して重要な情報をすべて文書化し、他の人にテストの実装を依頼できます。その際、記憶術に従って重要な情報を提供したことが明確になります。

既存のテストを評価するツールとしても使用できます。既存のテストを調査する際は、コードをSACREDにマッピングして、テストが何をしているかを把握するだけでなく、実装のギャップも特定します。

まとめ

テストがチームにとって価値ある資産と見なされていない、または繰り返し不安定で偽陰性や偽陽性を引き起こしている場合、一時停止してSACREDに基づいて分析する時期かもしれません。テストはチームにとって不可欠な存在であり、安心して迅速に動くことを可能にするべきです。テストは侵すべからざる、神聖なものであるべきです。

自動テストシリーズについて

これは、Richard Bradshaw 氏との共同制作による「自動テスト」シリーズの第 5 回です。このシリーズでは、テストの自動化とその実装について、さまざまな側面から探求していきます。

• 第１部では、手動テストと自動テストのパラドックスについて探求しました。こちらをご覧ください。
• 第２部では、UI 自動テストのさまざまなタイプについて探求しました。こちらをご覧ください。
• 第３部では、自動APIテストの必須の種類について説明しました。こちらをご覧ください。
• 第４部では、システムのアーキテクチャ、データフロー、統合を理解することが、真に効果的なテスト自動化を構築する鍵となる理由を解説しました。こちらをご覧ください。