Блог / Коллекция полезного

Как это работает: тестирование сайта

26 февраля 2020

В разработке сайтов есть немало подводных камней. И заказчик, получая готовый продукт, может даже не догадываться о том, какие усилия предпринимал разработчик, чтобы сайт клиента функционировал и выглядел так, как это задумывалось изначально. Рассказываем о самом закрытом от глаз заказчика этапе разразработки — тестировании.

Александра Вайгель тестировщик

Впечатление пользователя о сайте складывается из деталей. На это впечатление влияют не только визуальный облик и удобство навигации, но и множество технических моментов. На каждом проекте есть немало неочевидных сценариев поведения пользователя, которые могут привести его к ошибкам на сайте.

Задача тестировщика — предусмотреть все эти сценарии, пройти путь пользователя, зафиксировать баги, сформировать задание на исправление и убедиться, что найденные ошибки устранены. Тестирование сайта проводится для снижения рисков бизнеса. Баги — это нечто, что снижает ценность продукта. Если пользователь не сможет выполнить нужное ему действие, он не будет разбираться, а просто уйдет к конкурентам.

Что проверяется в ходе тестирования

В первую очередь тестировщик проверяет, что те функции и требования, которые были заложены на этапе планирования проекта, работают. Наиболее частые пункты тестирования:

проверка работы функционала,
кросс-браузерность,
адаптив,
соответствие макету.

Верстка должна быть гибкой, поэтому мы выявляем ситуации, где верстка может сломаться, и предотвращаем их.

Также в задачи тестировщика входит оценка юзабилити сайта — проверка удобства навигации и прохождение различных пользовательских сценариев.

Когда в работу с сайтом включается тестировщик

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

Этап 1

Планерки на этапах прототипов и дизайна

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

Этап 2

Первичное знакомство с сайтом

Этот этап также называют оценкой learnability. Есть лишь единственный шанс впервые взглянуть на получившийся продукт свежим взглядом и дать оценку с точки зрения удобства пользования. Learnability является частью usability сайта и отражает способность интерфейсов быть понятными пользователям с первого знакомства, давать возможность эффективно использовать все функции и возможности готового продукта. Этот этап важен, так как затем представление уже будет искажено знаниями. Мы уже будем знать, как двигаться по сайту, как это было задумано разработчиками. Здесь тестировщик равен в знаниях о продукте с обычным пользователем — он не пользуется техническими заданиями и макетами.

На этом этапе выявляются очевидные баги, такие как:

«ничего не работает» — что-то мешает пользоваться основными функциями сайта,
проблемы с удобством навигации и совершением целевых действий,
попутно замеченные баги, которые сразу фиксируются,
неполная спецификация (неполное техническое задание или алгоритм работы узкого специалиста).

Этап 3

Аналитическая часть работы и работа по плану

На этом этапе проводится необходимая аналитика и составляется план действий, а также приоритеты на тестирование. Далее тестировщик работает по плану в соответствии с наработанными чек-листами, тест-кейсами, инструментами и техниками. Составленный список правок отдается специалистам, и дальше тестировщик работает параллельно с ними.

Нужно время для того, чтобы сформировать пул правок: это достаточно нелинейный процесс. Одна замеченная ошибка может влиять на другую, описание может быть дополнено этими зависимостями. Уточняется локализация, случаи воспроизведения бага, ищутся или создаются тестовые примеры.

С каждым проектом нарабатывается тестовый контент (тексты, изображения, видео, файлы), тест-кейсы (последовательности шагов, которые описывают определенные сценарии) и чек-листы — они экономят немало времени работы на следующих проектах.

Этап 4

Исправление правок первой итерации, проверка правок, доработки

Здесь все просто — узкие специалисты исправляют найденные баги, а тестировщик проверяет внедрение доработок. Но часто на этом все не заканчивается, ведь внедренные доработки могут создавать новые процессы, а значит — вызывать новые баги. Для этого есть этап регрессионного тестирования.

Этап 5

Регрессионное тестирование, вторая итерация (перепрогон и перепроверка всех возможных состояний)

Вторая итерация бывает не всегда. Ее наличие зависит от проекта, его объема, времени между этапами разработки и т. д. Решение о целесообразности проведения регрессионного тестирования принимается менеджером проекта совместно с тестировщиком.

Этап 6

Ретроспектива и внутренняя аналитика

После полного завершения проекта в Alente происходит ретроспектива. Тестировщик анализирует прошедшие итерации, чтобы повысить эффективность дальнейшей работы над новыми проектами.

Ретроспектива помогает:

оптимизировать затраты времени на рутинную работу,
вскрыть проблемы в коммуникации команды,
проанализировать задачи — зафиксировать, на каких этапах были вопросы, проблемы,
собрать статистику, чтобы в будущем давать более точные оценки трудозатрат,
провести анализ плюсов (как масштабировать удачные моменты) и минусов (как их избежать),
провести анализ эффективности тестирования.

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

Интересуетесь созданием сайта?

Подробнее об услуге

Как происходит тестирование и какие инструменты используются

Все, что происходит на сайте, подчиняется определенным требованиям. «Протестировать все» или протестировать что-то, не зная требований, невозможно. Требованиями могут быть стандарты («мы знаем, как оно должно работать»), техническое задание или дизайн-макет, в котором проработана логика проекта.

У каждой студии свои требования к тестированию — это плод многочасовой работы, опыт. Все, что мы делаем сегодня, — это не случайность, а то, что по крупицам собиралось нами годами.

Есть стандартные задачи (например, проверка кросс-браузерности верстки), для которых используются такие инструменты, как фермы браузеров, устройств, инструменты разработчика (такие как консоль браузера), средства автоматизации действий в браузере, чек-листы и тест-кейсы. Для отдельных задач могут использоваться более узкие инструменты, такие как:

сервисы с временным номером телефона для проверки рассылок, одноразовые почты,
наработанный тестовый контент (различные форматы изображений, видео, текста),
полезные расширения для браузеров (для куки, кэша, автоматизированные шаблоны для полей ввода),
прокси-серверы для проверок геолокаций и т. д.

Для абсолютно нестандартных задач пишутся индивидуальные сценарии и тесты, ищутся подходящие задаче инструменты и способы проверки.

Любой разработчик стремится к оптимизации. Для этого в компании создаются собственные внутренние инструменты — чек-листы самопроверки, регламенты и стандарты по взаимодействию специалистов и использованию инструментов.

Источник фото: https://www.freepik.com/ freepik