Как поэтапное тестирование сайта уменьшает число ошибок, сокращая время запуска и отладки интернет-магазина

В большинстве компаний тестирование сайта производится однократно — после создания интернет-магазина. Обычно тестировщик фиксирует 200-300 ошибок, на исправление которых уходит масса времени и сил разработчиков.

Все это сказывается на сроках запуска проекта, а время, которое требуется на обнаружение ошибок и их устранение оттягивает запуск интернет-магазина, и тем самым увеличивает срок окупаемости затрат на разработку интернет-магазина.

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

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

В KISLOROD практикуют следующие этапы тестирования:

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

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

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

А теперь подробнее о каждом этапе тестирования интернет-магазина.

На этом этапе тестировщик знакомится с проектом, прототипом, ТЗ. Проверяет прототип на корректность, соответствие внутреннему чек-листу и требованиям проекта. Составляет баг-репорты, включающие задачи по устранению ошибок. Генерирует идеи.

После устранения ошибок, прототип отправляется на отрисовку дизайна.

Тестировщик вычитывает в ТЗ всё, что касается верстки, отмечает нестандартные моменты, на которые обращает особое внимание.

Проверяет верстку по чек-листу на корректность, валидность, адаптивность, кроссбраузерность.

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

Чтобы выявить максимум багов (ошибок) верстки за минимальное количество времени, тестировщик использует общую таблицу комбинаций устройств, браузеров и разрешений экранов.

Согласно нашим регламентам, программист демонстрирует результаты в одной из комбинаций "устройство\браузер\разрешение", а тестирование осуществляется во всех комбинациях.

После исправления ошибок, проект передается на сборку разработчику.

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

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

Выявленные ошибки фиксируются в баг-листе в виде баг-репортов, и затем исправляются.

У нас есть собственная разработка для работы с ошибками, которую мы постоянно совершенствуем — Bitrix24 Buglist. Это табличные баг-листы для пользователей нашего внутреннего корпоративного портала Битрикс24.

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

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

Тестировщик составляет баг-репорты, по которым исправляются ошибки.

Также можно отдельно провести нагрузочное тестирование в Яндекс Танк. На этапе технической поддержки актуальная автоматизация тестирования.