Научились делать отличный результат в любых условиях и выпустили заметные релизы

Привет! Это Коля, CEO студии GRCH. Мы разрабатываем, поддерживаем и масштабируем цифровые продукты. В статье поделюсь нашим опытом за 9 лет и расскажу, как научились делать отличный результат в любых условиях.

С написанием статьи нам помогала Алина, наша тестировщица. Дальше она поделится своим опытом и мыслями на тему тестирования проектов.

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

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

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

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

Мы делали сайт для продажи таунхаусов Удачное. Этот сервис принадлежит крупнейшему застройщику Крыма — группе компаний «Монолит». В общем, элитное жильё, для которого нужно сделать соответствующий сайт — красивый и удобный.

Процесс работы

Визуальную часть тестировали на этапе подготовки макетов, дальше проводили UX/UI-тестирование, искали недостатки и серые зоны в техническом задании.

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

👉 Тестируем на 4 реальных устройствах в разных браузерах с основными ОС: iOS, Android, MacOS и Windows.

👉 Тестируем в BrowserStack и LambdaTest: используем статистику по устройствам, разрешениям, версиям и делаем выборку под проект.

Тестирование на реальных устройствах важно при тестах анимаций, скроллов и подобных вещей на проекте. В нашем кейсе, например, была интересная фича с панорамой 360° — чтобы у пользователя была возможность получить детальную информацию по каждому дому и рассмотреть его со всех сторон, а ещё анимация главного экрана и интересные слайдеры. Cкорость загрузки анимаций и производительность сайта оценивали в сервисах Pagespeed и Lighthouse.

После проверили функционал и разработали тест-кейсы на:

— калькулятор расчёта стоимости,

— бронирование,

— разные типы подачи заявок.

И, наконец, проверили бэкенд: отработали форму бронирования, синхронизированную с админкой и CRM-системой заказчика.

Сложности

Пришлось дополнительно поработать над анимациями, «провалами» в панораму на iOS и macOS и даже обращать внимание на такие нетривиальные задачки вроде превращения текста «домашний уклад» силами переводчика в «опасный уклад» :)

Что получилось в итоге

Все найденные репорты были проработаны, и…

Случилась победа. Мы добились классного результата: сервис занял целых два первых места — на крупнейшей диджитал-премии в Европе Tagline Awards в номинации «Лучший сайт о недвижимости» и ежегодной премии Рейтинг Рунета в номинации «Одностраничный сайт/лендинг».

К сложным можем отнести кейс для многофункционального портала Строимпросто. В нём есть множество полезных сервисов для застройщиков. Сейчас сайт находится у нас на техподдержке: добавляются новые фичи и проводится реинжиниринг.

На таких глобальных проектах мы проводим интеграционное и модульное тестирование — каждый новый блок проверяется отдельно и в общей картине. Поэтому пишем документацию для API, пользуемся Postman, Swagger и Charles, когда исследуем запросы. Не забываем про безопасность передачи информации в системе.

Функционал должен работать, как хорошие швейцарские часы :)

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

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

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

Смотрите, как это выглядит

У каждого репорта есть заполняемые самостоятельно столбцы:

— ожидаемый/фактический результат,

— скриншоты,

— окружение,

— шаги,

— столбцы с комментариями для QA, разработчиков и менеджеров (по желанию),

— дата (проставляется автоматически),

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

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

Тестировщик

Сначала тестировщик находит баг, заполняет нужные данные и определяет статус — «Новый QA», дальше оценивает критичность бага для системы, определяет, кто именно должен исправлять выявленный недостаток (столбец Исполнитель) и указывает, является ли репорт сообщением именно об ошибке или предложением по улучшению продукта (Суть: BUG или REV).

Менеджер

Когда задача QA закончена, менеджер открывает репорт и определяет свои статусы:

Помимо этого, менеджер определяет приоритет, то есть, срочность исправления:

Разработчики, Дизайнеры, Контенты, Девопсы, Клиент

Как только проставлены статусы «Открыт PM» и поставлена задача на правки, в дело вступают другие члены команды.

👉 Дизайнер дорисовывает нужные макеты, добавляет необходимое юзабилити и определяет репорту статус — Исправлено DZN, что фактически означает передачу репорта фронт-разработчику.

Исполнителями также могут быть указаны: FRONT, BACK, CONTENT (если нужно добавить или продумать тексты), OTHER (вопрос перенаправляется DevOps или клиенту).

👉 Разработчик может проставить статусы: Не баг DEV, Не исправить DEV, Уточнение у QA, Исправлен LOCAL, Исправлен DEV.

После правок — опять тестировщик

После правок QA получает задачу и далее определяет новый статус исправленных багов, например: Переоткрыт QA (если баг не был исправлен в полной мере).

О других статусах. Поскольку проверки мы начинаем уже на ранних этапах, для удобства работы и подстраховки есть три последовательных этапа тестирования: на фронте сайт тестируется, если вёрстка оказалось готова раньше, чем бэкенд — после её тестов выставляется статус «Проверен front QA».

Если проверка прошла успешно на деве — «Проверен dev QA».

Далее может быть оценен препрод — «Проверен pp QA» и закончится всё тестированием прода, где репорт будет «Закрыт QA».

Если кратко, то мы:

В итоге, выпускаем классные проекты в релиз, радуем клиентов, пользователей и команду.

Спасибо всем, что дочитали статью и Алине, что поделилась всеми знаниями)

Приходите к нам за разработкой и тестированием. Мы подумаем о реализации, подскажем технические моменты и займемся разработкой. Пишите нам на почту hello@grechka.digital или сразу оставьте заявку на сайте.