-
Notifications
You must be signed in to change notification settings - Fork 4
テストファイル作成の手順
- WAICのサイトにあるテストファイルを確認し、以下の2点を確認する
- UAの挙動のテストになっているか
- 判断基準は良いか ※手順と判断基準が混同されていることが多いため注意する
- 使えそうならそのまま使ってテストファイルを作成
- 必要に応じて書き起こす
- テストの目的はほぼ書き起こす必要がある
テストファイルの名前は WAIC-TEST-0020-01 のような連番とする。番号の重複を避けるため、追加時には以下の手順をとるものとする。
- GitHubのissueを参照して、最新のファイル番号を確認する。
- ファイル番号をインクリメントして issue のタイトルに設定し、新規にissueを立てる。issueのタイトルは、テストID + テストタイトルとする (例: WAIC-TEST-0001-03 装飾だけを目的にした画像の代替テキスト (alt="") への対応)
- 進捗管理用ページ にissueの番号とテストID、担当者を記載する
テストファイルの内容のうち、以下の6点について1次案を作成する。
- テストの目的
- テストの対象となる達成基準 (複数)
- 関連する達成方法 (複数)
- テストコード
- どんなテストをすればよいか（テストコード、テスト手順、期待される結果などのもとになるもの）
- 関連する要素や属性
多くのテストにおいて書き起こす必要がある。 どのような状況において、何をテストするのかを明確にする。 （例：このテストは、fieldset 要素及び legend 要素を用いてラジオボタンをグループ化している場合に、ユーザエージェントがそれを適切に伝えているかどうかについて確認するためのものである）
テストの対象となる達成基準を列挙する。 既存のテストを修正する場合は、WAICサイトの該当する内容を参考にするとよい。
テストに関連する達成方法を列挙する。 既存のテストを修正する場合は、WAICサイトの該当する内容を参考にするとよい。
既存のテストコードを修正するか、あるいは書き起こす形で作成する。
視覚閲覧環境（ビジュアルブラウザなど）と音声閲覧環境（スクリーンリーダーなど）のそれぞれについて、以下の3点を作成する。
どのような操作をして、何を確認するのかを明確にする
テスト手順を実行した結果として期待されるもの。
結果の判断の際に参考になる情報などを記載する。
視覚閲覧環境におけるテストを作成するかどうかについては、以下の点を考慮する。
- 視覚によって閲覧することを想定している達成基準についてはテストを作成する
- テスト手順や期待される結果が明らかなものについてはテストを作成する
- テストファイル作成時にこの2点を検討し、視覚閲覧環境のテストの扱いを判断する
テストやAS情報を利用する人が要素や属性をキーにして参照・検索できるようにするために、テストと関連する要素・属性を列挙する。 （例：a要素、type="text"を持つinput要素など）
1次案が完成したら GitHub の dev ブランチへ push してプルリクエストを送信し、チームレビューを依頼する。
ユーザーチーム及びATベンダーチームとともに、1次案のレビューを行う。
レビューの結果、テストそのものを行わないことが決定した場合、以下の作業を行う。
- GitHub から当該テストファイル及びテストコードを削除
- 当該 issue にテストを行わない旨を記載して close
- 進捗管理用ページ の該当する行を削除
削除されたテストのテスト番号は欠番とする。
チームレビューの結果を踏まえて、テストファイル及びテストコードを修正する。以後チームレビュー・修正を適宜繰り返す。チーム内で概ね合意が得られたら全体へレビューを依頼する。
WG2全体でレビューを行う。レビュー期間を1週間とし、担当者以外のWG2委員最低2名以上がレビューするものとする。意見が出た場合は2次案作成にもどって修正・チームレビューを再度行う。
issue を close する。