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

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

実施事項

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

流れ

1. 「事例」が UA のテスト となっているかの確認

• 「事例」記載内容で想定されるケース
  • UA のテストとなっている
    • 例 : xxxxx
  • コンテンツのテストとなっている
    • 例 : xxxxx
• 対応方法
  • UAのテストとなっている場合
    • テストを詰める
  • コンテンツのテストとなっている場合
    • 1次案作成のタイミング（後述）にて、UA のテストとなるように修正する。

2. 事例に掲載コードの妥当性確認

• 事例に掲載されているコードに、廃止要素や廃止属性、推奨されない属性が利用されていないかどうかを確認する。
• 例 : table 要素にて summary 属性を利用している。

3. 事例に掲載されているコードの整形

• 事例に掲載されているコードが、WAIC のコードフォーマットに則っているかどうかを確認する。
  • 「WAIC の」 としたが、明確にはコードフォーマットは存在しない（はず）
• 例 : 空要素は、< /> ではなく < > として記述する。

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

実施事項

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

流れ

1. テストケース/コードのファイル名称を決定

• WAIC-TEST-XXXX-YY という形式
  • 新規でテストケースを作成する場合は、直前のテストからの連番で良い。
  • 既存のテストファイルは、廃番が発生したために必ずしも連番にはなっていない。

2. git issue を立てる

• テストケースのファイル名称 + テストタイトル
• テストタイトルは、内容を端的に示したものとする。
  • 検討が重い場合は、安直なタイトルでも良い。
    • 端的なテストタイトルが思い浮かばないことで issue が立てづらくなることを回避。
    • タイトルは後でも修正可能。必要であれば、レビュー時にタイトルを修正する。

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

実施事項

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

流れ

1. テストの目的

• ちゃんと考える必要がある。
• （後で考える）

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

• Techniques などの参考文献を参照すれば機械的に抽出。

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

• Techniques などの参考文献を参照すれば機械的に抽出。

4. テストコード

• Techniques の事例のコードなので自明。
• 利用できる場合はコピペ
• 利用できないと判断される場合
  • UA のテストとなっている
  • コンテンツのテストとなっている

5. 関連する要素や属性

• テストコードが流用可能であれば、機械的に抽出可能。

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

• 議論で一番神経を使うところ。
  • 一人でここを決めるのは非常に難しい箇所
  • ここに議論が集中できるように、他の項目を埋めていくことが重要
• 場合によっては、「テストの目的」「テストコード」を見直す必要がある。
  • 「テストの目的」「テストコード」を見直す場合、xxxx も見直す必要がある。

手順4. チームレビュー

• 「作る」チームの中でレビューを行う

手順5. 2次案作成

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

手順5. 全体レビュー

• WG2 全体でレビューを行う。

手順6. 完成

• WG2 全体でレビューを行う。

その他

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

• 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 する。