Список Активностей при Тестировании Веб Приложений

Хочу сразу оговориться, это не статья о том как и чем тестировать веб сайты, в том числе UI/UX, перед выпуском в продакшн и после выпуска, релиз-кандидат и релиз соответственно. Также это не чеклист по которому нужно иди во время тестирования. Это, скорее мои мысли, возникшие во время одного из регрессионных тестирований одного из проектов. Как то так.

По ходу работы над разными проектами я обратил внимание на то о чем мы часто забываем по ряду причин. Но все равно бьем себя коленом в грудь, что продукт мы выпустили качественный, а это у заказчика какой-то браузер, которым уже никто не пользуется, и вообще устройства у нас такого нет, и что я буду ради одного проекта подымать MacOS. В итоге заказчик видит не то, сколько крутого кода мы напедалили на бэкенде; и не то, что у нас все тестами покрыто; и не то, что API RESTful, а то что у него на экране страничку порвало, как тузик грелку или менюшка в iPod Touch не открывается. Именно Front End виден сразу и соответственно сразу влияет на User Experience. Ну и дальше этот User Experience трансформируется в поджопники и матюки.

Полагаю мои заметки помогут тестировщикам дополнить или сформировать неплохой тест план. Приоритеты активностей могут сильно отличаться в зависимости от проекта. Может вам ничего и не пригодится, кто знает.

  • Дожидаться полной загрузки каждой страницы при прохождении по сценарию.
  • // тут вроде все ясно, но тестировщик очень часто в силу нехватки времени или терпения не дожидается полной загрузки

  • Консоль Fire Bug должна быть активна с включенными нотификациями о JS ошибках.
  • // Т.к. ошибка JS сценария может не повлиять на внешний вид страницы, но заблокировать какой-то важный функционал.

  • Проверять валидность макета/верстки
  • // W3C много занимает времени. Но таки при получении макета лучше перепроверить валидность кода после FE developera. Он тоже человек, мог спешить или после проверки что-то вспомнил и добавил мелочь, забыв закрыть тег

  • Проверять масштабирование вебстраницы
  • // Может только для основных страниц типа главной, страницы поста, страницы категории.

  • Проверять масштабирование окна браузера
  • // Далеко не у всех пользователей браузер открыт в полноэкранном режиме

  • Проверка укладки верстки в основных разрешениях
  • // Ноутбук 15′, монитор 21′ и т.д. можно покрыть инструментами эмуляции разрешения в браузере

  • Если верстка адаптивная или риспонсив проверять поведение touch устройств (iPhone, iPad) на элементах меню, кнопках, формах и т.д.
  • Требовать список совместимых с проектом устройств и их характеристиками
  • // Тут нужно вцепиться зубами в PMа и требовать, требовать, требовать. Потому что вы, тестировщики, потом можете остаться крайними

  • Проверять использование безопасной палитры цветов
  • // Как минимум обращать внимание не меняется ли оттенок в разных браузерах)

  • Тестирование производительности
  • // Хотя бы основных нагруженных контентом страниц, делать записи тестов после каждого релиза, но подождать пока приложение «прогреется». Можно использовать отличный ресурс www.webpagetest.org

  • Использование стандартных шрифтов вместо кастомных
  • // Это как одно из следствий предыдущего пункта, также сюда может входить рекомендации использования спрайтов, сбор файлов js и css в один, кеширование, сжатие и т.д. Но это отдельная тема, обычно именно шрифты дольше всего едут на клиент.

  • Проверка битых ссылок
  • // Можно написать своего бота, который пойдет по всем ссылкам и запишет http заголовки, а можно с помощью Xenu. Мне именно Xenu нравится больше всего.

Вот и все, спасибо за внимание и качественных вам продуктов!

Отдельное спасибо моим друзьям тестировщикам, помогавшим брейстормить и формировать список.

Оставить комментарий