テストファイル作成の手順

手順1. [個人] 「達成方法」の「事例」をベースに、テストファイルが作成可能か確認する

実施事項

1. 達成方法の事例が UA のテスト となっているかの確認
2. 達成方法の事例に掲載コードの妥当性確認
3. 達成方法の事例に掲載されているコードの整形

流れ

1. 「事例」が UA のテスト となっているかの確認
   • 「事例」記載内容で想定されるケース
     • UA のテストとなっている
       • 例 : xxxxx
     • コンテンツのテストとなっている
       • 例 : xxxxx
   • 対応方法
     • UAのテストとなっている場合
       • テストを詰める
     • コンテンツのテストとなっている場合
       • 1次案作成のタイミング（後述）にて、UA のテストとなるように修正する。
2. 事例に掲載コードの妥当性確認
   • 事例に掲載されているコードに、廃止要素や廃止属性、推奨されない属性が利用されていないかどうかを確認する。
   • 例 : table 要素にて summary 属性を利用している。
3. 事例に掲載されているコードの整形
   • 事例に掲載されているコードが、WAIC のコードフォーマットに則っているかどうかを確認する。
     • 「WAIC の」 としたが、明確にはコードフォーマットは存在しない（はず）
   • 例 : 空要素は、< /> ではなく < > として記述する。
     • 基本は html 構文として記載する。
     • なんらか xml 構文である必要がある場合は、対象の構文を保持する。

手順2. [個人] テストケースとテストコードを作成する

実施事項

1. テストケース/コードのファイル名称を決定。
2. git issue を立てる。

流れ

1. テストケース/コードのファイル名称を決定
   • WAIC-TEST-XXXX-YY という形式
     • 新規でテストケースを作成する場合は、直前のテストからの連番で良い。
   • 既存のテストファイルは、廃番が発生したために必ずしも連番にはなっていない。
2. git issue を立てる
   • テストケースのファイル名称 + テストタイトル
   • テストタイトルは、内容を端的に示したものとする。
     • 検討が重い場合は、安直なタイトルでも良い。（タイトルは後でも修正可能。必要であれば、レビュー時にタイトルを修正する。）
     • テストタイトルは一意なものとする（テストタイトルの重複を避ける）

手順3. [個人] テストファイル1次案の作成

実施事項

1. テストの目的
2. テストの対象となる達成基準 (複数)
3. 関連する達成方法 (複数)
4. テストコード
5. 関連する要素や属性
6. どんなテストをすればよいか（テストコード、テスト手順、期待される結果などのもとになるもの）
7. PR を作成する

流れ

1. テストの目的
   • Techniques の「解説」を確認し、何のテストを行うかを記す。
2. テストの対象となる達成基準 (複数)
   • Techniques の「適用（対象）」を確認し、その内容を列記する。
3. 関連する達成方法 (複数)
   • 参照している Techniques の達成方法番号を記載する
4. テストコード
   • Techniques の事例のコードより転載。
   • 画像などのリソースが確認できない場合は、適当な代用リソースを準備。
   • 利用できないと判断される場合
     • UA のテストとなっている
     • コンテンツのテストとなっている
5. 関連する要素や属性
   • テストコードを確認し、利用している要素を抽出。
   • cssのプロパティなどは記載しない。HTMLの要素と属性のみに言及する。
6. どんなテストをすればよいか（テストコード、テスト手順、期待される結果などのもとになるもの）
   • 議論で一番神経を使うところ。
     • 一人でここを決めるのは非常に難しい箇所となるため、まずは議論のきっかけとなるようにライトに記載。
     • 記載が難しい場合、「何を記載すればよいか？」を議論するために、他の項目を埋めるようにする。
7. PR を作成する
   • テストファイル、テストコードを準備し、PR を作成する。
     • PR では、該当の issue と紐づけを行う。

手順4. [チーム] チームレビュー

• 「作る」チームの中でレビューを行う
  • チームレビューでは、作成したテストファイルの記載漏れ、テストコードの不備などがないかを確認。
    • 特に、テストの目的がしっかりと記載されているかを確認する。
  • どんなテストをすれば良いかの議論までできれば理想だが、難しければ全体レビューへと回す。
• 全体レビューへの申し送り事項がある場合、明確にしておく。（issue に記載する）

手順5. [個人] 2次案作成

• チームレビューを踏まえて、修正を行う。
• 不要な場合は次のステップに進む。

手順5. [チーム] 全体レビュー

• WG2 全体でレビューを行う。
• テストの目的、どんなテスト

手順6. [チーム] 完成

• issue を閉じる

その他

テストファイル作成対象とする達成方法

• G の項目については、テストをしない

（以下、古いバージョン）

---

テストファイル作成フローの概要

• WAICのサイトにあるテストファイルを確認し、以下の2点を確認する

1. UAの挙動のテストになっているか
2. 判断基準は良いか ※手順と判断基準が混同されていることが多いため注意する

• 使えそうならそのまま使ってテストファイルを作成

1. 必要に応じて書き起こす
2. テストの目的はほぼ書き起こす必要がある

手順1. テストファイルの命名とissueの作成

テストファイルの名前は WAIC-TEST-0020-01 のような連番とする。番号の重複を避けるため、追加時には以下の手順をとるものとする。

1. GitHubのissueを参照して、最新のファイル番号を確認する。
2. ファイル番号をインクリメントして issue のタイトルに設定し、新規にissueを立てる。issueのタイトルは、テストID + テストタイトルとする (例: WAIC-TEST-0001-03 装飾だけを目的にした画像の代替テキスト (alt="") への対応)
3. 進捗管理用ページ にissueの番号とテストID、担当者を記載する

手順2. テストファイル1次案の作成

テストファイルの内容のうち、以下の6点について1次案を作成する。

• テストの目的
• テストの対象となる達成基準 (複数)
• 関連する達成方法 (複数)
• テストコード
• どんなテストをすればよいか（テストコード、テスト手順、期待される結果などのもとになるもの）
• 関連する要素や属性

1. テストの目的

多くのテストにおいて書き起こす必要がある。 どのような状況において、何をテストするのかを明確にする。 （例：このテストは、fieldset 要素及び legend 要素を用いてラジオボタンをグループ化している場合に、ユーザエージェントがそれを適切に伝えているかどうかについて確認するためのものである）

2. テストの対象となる達成基準 (複数)

テストの対象となる達成基準を列挙する。 既存のテストを修正する場合は、WAICサイトの該当する内容を参考にするとよい。

3. 関連する達成方法 (複数)

テストに関連する達成方法を列挙する。 既存のテストを修正する場合は、WAICサイトの該当する内容を参考にするとよい。

4. テストコード

既存のテストコードを修正するか、あるいは書き起こす形で作成する。

5. どんなテストをすればよいか（テストコード、テスト手順、期待される結果などのもとになるもの）

視覚閲覧環境（ビジュアルブラウザなど）と音声閲覧環境（スクリーンリーダーなど）のそれぞれについて、以下の3点を作成する。

(1) テスト手順

どのような操作をして、何を確認するのかを明確にする

(2) 期待される結果

テスト手順を実行した結果として期待されるもの。

(3) テスト実施時の注意点

結果の判断の際に参考になる情報などを記載する。

視覚閲覧環境について

視覚閲覧環境におけるテストを作成するかどうかについては、以下の点を考慮する。

• 視覚によって閲覧することを想定している達成基準についてはテストを作成する
• テスト手順や期待される結果が明らかなものについてはテストを作成する
• テストファイル作成時にこの2点を検討し、視覚閲覧環境のテストの扱いを判断する

6. 関連する要素や属性

テストやAS情報を利用する人が要素や属性をキーにして参照・検索できるようにするために、テストと関連する要素・属性を列挙する。 （例：a要素、type="text"を持つinput要素など）

1次案が完成したら GitHub の dev ブランチへ commit / push する。その際 GitHub に commit message を残すこと。
push したらプルリクエストを送信し、チームレビューを依頼する。

手順3. チームレビュー

ユーザーチーム及びATベンダーチームとともに、1次案のレビューを行う。

レビューの結果、テストそのものを行わないことが決定した場合、以下の作業を行う。

• GitHub から当該テストファイル及びテストコードを削除。その際削除した理由をcommit message に残す。
• 当該 issue にテストを行わない旨を記載して close
• 進捗管理用ページ の該当する行を削除

削除されたテストのテスト番号は欠番とする。

手順4. 2次案作成

チームレビューの結果を踏まえて、テストファイル及びテストコードを修正する。以後チームレビュー・修正を適宜繰り返す。チーム内で概ね合意が得られたら全体へレビューを依頼する。

手順4. 全体レビュー

WG2全体でレビューを行う。レビュー期間を1週間とし、担当者以外のWG2委員最低2名以上がレビューするものとする。意見が出た場合は2次案作成にもどって修正・チームレビューを再度行う。

手順5. 完成

issue を close する。