Чек-лист стоит под учебными страницами с заложенными багами: вы изучаете страницу, находите баги и отмечаете их в списке.
Как выглядит
- Сверху — учебная страница с багами (форма, таблица, карточка, профиль и т. п.).
- Ниже — чек-лист: список возможных багов с галочками.
- Среди пунктов есть ложные («красные селёдки») — то, что выглядит подозрительно, но багом не является.
- Кнопка «Засчитать» отправляет отмеченное на проверку.
Что делать
- Проверьте страницу руками. Пройдите поля клавишей Tab, введите заведомо неверные данные, отправьте пустую форму, вставьте очень длинный текст.
- Откройте DevTools. Что уходит в Network? Есть ли предупреждения и ошибки в Console? Нет ли в Elements скрытых элементов?
- Прочитайте чек-лист. Каждый пункт подсказывает, что искать. Например, «email принимается без
@» — это про валидацию. - Отметьте только подтверждённое. Не угадывайте: не воспроизвели — не отмечайте.
- Отправьте и прочитайте результат.
Как платформа считает
Ваши отметки сравниваются со списком настоящих багов на сервере. Для зачёта нужно найти не меньше заданного числа настоящих багов и не отметить лишнего сверх допуска. Порог написан над чек-листом, например:
- чек-лист Bug Hunt — не меньше 36 настоящих багов и не больше одного ложного пункта;
- плохая страница в практике по доступности — не меньше 8 настоящих находок и не больше одной ошибки.
Попытки не ограничены.
Где встречается
/practice/bug-hunt/report— чек-лист по всем разделам учебного продукта BugFinder./practice/a11y/bad-page— нарушения доступности.
Подсказки
- Не торопитесь. На странице регистрации легко пропустить, что пароль виден в подсказке при наведении.
- Проверьте клавиатуру. Многие баги — про доступность: Tab пропускает поле, Esc не закрывает модальное окно.
- Смотрите в разметку.
<button>, сделанный из<div onclick>, — баг, даже если визуально всё работает. - Проверяйте данные. Иногда баг не в оформлении, а в значениях: отрицательная цена, дата из будущего.