良い実践
名前、シナリオ、メモ、説明、専用のテスト環境: テストを長持ちさせるもの。
テストは書かれるよりも読まれる回数のほうが多い
記録すれば、数分で動くテストが手に入ります。GUI Test Studio でさらに数分かければ、チーム全員が読めるテストになります: タイムラインでも、信頼度レポートでも、そこから生まれるバグレポートでも。
以下のすべてがレポートに表示されます。「チェックアウトで『保存ボタンのアサーション』が不合格」と書かれたレポートは、開発者が何も開く前に、何が壊れたかを伝えます。
大事なものに名前を付ける
どのステップにも「クリック」や「ビジュアルアサーション」のような名前が自動で付きます。大事なステップには自分で名前を付けてください: ブロックを選択して F2 キーを押します。
| この名前の代わりに | こう名付ける |
|---|---|
| ビジュアルアサーション | 「新しいチケット」ボタンのアサーション |
| テキストアサーション | 注文確定メッセージのアサーション |
| テキスト入力 | 顧客名を入力 |
| クリック | 「確定」をクリック |
ステップをシナリオにグループ化する
ジャーニーの一部分にあたるステップを選択して Ctrl+G キーを押します: 「サインイン」「カートに追加」「支払い」のように。長いテストが色分けされたいくつかの章になり、レポートはどの章で実行が止まったかを伝え、「サインイン」のようなシナリオはほかのテストでも再利用できます。
詳しくはシナリオ: ステップのグループを再利用するをご覧ください。
メモを残す
マーカーはタイムライン上のメモです (M キー)。次に読む人が推測できないことに使ってください: なぜアサーションを緩めてあるのか、そのステップにどんなデータが必要か、失敗したときにどうすればよいか。
テストを説明する
設定、プロジェクト設定を開いて説明を書いてください: テストが何をカバーするか、どんな状態から始まるか、どんなデータが必要か。
「保存済みカードでのチェックアウト。開始: サインアウト状態、ホームページ、テストユーザー qa-01、カートは空。テスト用の決済ゲートウェイが必要」
専用のテスト環境を使う
テストの安定性は、実行対象の安定性で決まります。普段作業しているコンピューターではなく、テスト用に用意したマシンとデータに対して実行してください。
専用の環境
- 画面サイズと拡大縮小が固定されたテストマシンまたは仮想マシン
- 実行のたびにデータがリセットされる、アプリのテスト用コピー
- ほかの誰も使わないテストアカウント
- 実行中に通知、更新、ポップアップが出ない
共有または個人の環境
- ウィンドウや設定が毎日変わる、自分のデスクトップ
- ほかの人が編集する本番データ
- カートや履歴が変わり続ける共有アカウント
- 実行の途中でスリープ、ロック、更新のインストールが起こるマシン
テストを小さく、独立させておく
1 件のテストには 1 本のジャーニー。短いテストが 10 件あれば何が壊れたかが正確に分かりますが、長いテストが 1 件では何かが壊れたことしか分からず、最初の失敗より後のすべてが未検証のままになります。
各テストは、先頭の「アプリを実行」や「Python スクリプトを実行」のステップで自分の開始状態を自分で整えるべきで、ほかのテストが先に実行されていることに決して頼ってはいけません。
テストを共有する前のチェックリスト
- テストに説明がある: 何をカバーし、どこから始まるか
- ステップが名前付きのシナリオにグループ化されている
- すべてのアサーションに、開発者が理解できる名前が付いている
- 変化する値 (日付、合計金額、注文番号) は、値ではなく種類で検証されている
- 決まった状態から、自力で始まる
- テストマシンで 2 回続けて合格した
まだ解決しませんか?何をしようとしていたかをお知らせください。1 営業日以内に回答します。Ask our team