Прежде чем представить ваш новый сайт или приложение пользователю, нужно убедиться, что все работает должным образом. Если пренебречь тестированием или провести его некачественно, могут открыться критические баги, которые перечеркнут месяцы работы разработчиков. Разбираемся, как организовать тестирование оптимально, и какие «подводные камни» могут возникнуть в процессе.
Тестирование веб-сервиса — это больше чем способ устранить все ошибки в работе продукта (баги), прежде чем выкатывать его для конечного пользователя. Грамотно проведенное тестирование является гарантией, что сервис справится с вызовами суровой реальности:
Есть и другая крайность: «Зачем отдельно платить тестировщикам? Пусть сервис проверяют те же, кто его разрабатывал. В конце концов, кто лучше них знает продукт?».
Чем опасен такой подход?
Не получится найти все баги с первого раза. Умение быстро находить и доходчиво описывать баги — это особый скилл, который вырабатывается годами практики. Кроме того, чтобы методично выявить все ошибки, нужно обладать усидчивостью и чрезмерной педантичностью. Конечно, можно поручить поиск багов тем же людям, что писали код, но в этом деле очень важен свежий, профессиональный и «незамыленный» взгляд.
Никто не отвечает за результат. Программисты находят баги... но не все. Сервис уходит в продакшн, но через какое-то время возвращается назад. Этот круговорот может повторяться снова и снова. Заказчик теряет время и деньги, но формально никто не виноват, потому что команда старается и делает все что может. Когда тестирование проводит профильный специалист, именно он несет ответственность, если не все баги найдены. Тестировщик мотивирован сделать работу сразу и качественно.
Пока программисты ищут баги, другие отделы простаивают. Когда разработка продукта организована грамотно, все работает как конвейер. Программисты пишут код, тестировщики ищут баги, менеджеры курируют и корректируют все бизнес-процессы. Если же программисты сами ищут баги и сами же их исправляют, весь процесс затягивается на неопределенный срок. Все это также приводит к потере времени и финансов.
Никто не может корректно описать проблему. Если тестирование проводит специально обученный человек, он может четко донести проблему понятным для разработчиков языком. В процессе разработки часто встречают т. н. «плавающие баги» — ошибки, которые появляются нерегулярно, от случая к случаю. Если заказчик проводит тестирование своими силами, ему тяжело выявить подобные проблемы и еще тяжелее их описать так, чтобы программист понял в чем суть.
Таким образом, понятное желание заказчика сэкономить время и ресурсы на тестировании на практике может легко обернуться срывом сроков проекта, конфликтной ситуацией между заказчиком и разработчиком. Но самое главное — возникает риск, что продукт получится некачественным, и заказчик не сможет достигнуть своих бизнес-целей.
Для начала разберем, как организован весь процесс создания сервиса. Его можно разделить на основные этапы:
Обычно весь флоу разработки выглядит как на рисунке, где:
- dev 1, dev 2 ... dev N — реализация определенной задачи (функционала, фичи);
- test 1, test 2 — площадка тестирования, куда интегрируются наработки по фичам, здесь происходит изолированное тестирование функционала;
- preprod — площадка предрелизной подготовки, здесь происходит весь комплекс тестирования: как функционируют отдельные доработки — как сами по себе, так и в связке с другими фичами, нагрузочные тестирования и т. п.;
- prod — продуктивная площадка, здесь никаких тестирований не ведется. С данной площадкой взаимодействуют клиенты, а также собираются различные метрики.
Подробнее разберем стадию test.
На первом этапе к работе подключаются бизнес-аналитики. Они задают заказчику и разработчикам вопросы, а потом выдвигают гипотезы, как оптимально организовать процесс тестирования.
Далее эстафету принимает тимлид отдела тестирования. Когда тимлиду поступает задача, он декомпозирует ее, разбивает на несколько задач. Затем под каждую задачу подбирает исполнителей. Важно оптимизировать количество участников в команде. Больше людей не означает, что дело пойдет быстрее.
Обычно в команду входят несколько мануальных тестировщиков, QA инженеры и, если необходимо, сотрудники со стороны заказчика.
После этого тимлид определяет время, которое потребуется на тестирование. Совместно с разработчиками определяют предрелизные и релизные даты. Лучше назначить их с запасом, чтобы осталось время еще раз прогнать продукт на тестовом сервере перед релизом.
Каждый тестировщик работает только над своей узкой задачей. К примеру, пока один участник команды тестирует функционал пересчета товара из тонн в штуки и в погонные метры, другой параллельно тестирует сервис рассылок. Это позволяет ускорить процесс и не дает отделу разработки простаивать в ожидании новых задач. Сам процесс тестирования может быть как полностью ручным, так и отчасти автоматизированным (CI/CD). Чтобы свести к минимуму рассинхронизации баз данных, используют подход миграций. И это также ускоряет работу.
После того как все баги устранены, производится регрессионное тестирование. Это повторная проверка уже протестированных участков, чтобы убедиться, что сделанные исправления не привели к возникновению новых дефектов. Если все в порядке, продукт можно выкатывать на препродакшн.
Виды тестов:
Тестирование функциональности. Проверка взаимодействия клиента и сервиса. Корректно ли работают все кнопки, формы и другие пользовательские элементы.
Тестирование веб-сервисов. Проверка корректности вызываемых веб-приложением сервисов на предмет обработки данных, изменения статусов объектов, возвращение информации из базы данных и т. д.
Тестирование кроссбраузерности и кроссплатформенности — как продукт отображается на различных устройствах и экранах.
Интеграционное тестирование, E2E — как отдельные блоки продукта взаимодействуют друг с другом.
Нагрузочное тестирование — как сервер справляется с большим количеством запросов.
UI тестирование — насколько внешний вид и функционал сервиса понятен пользователю.
Как мы разобрали выше, тестированием продукта должны обязательно заниматься профессионалы с релевантным опытом. Но это совсем не значит, что у заказчика нет возможности сократить затраты на проверку продукта. Совсем не обязательно требуется тестирование по каждому из пунктов. Личный кабинет клиента для сайта металлургического завода и интернет-магазин подарков не будут прогонять по одинаковому сценарию. Именно поэтому первым этапом должна быть консультация с бизнес-аналитиками. Они помогут понять, какие этапы тестирования и ресурсы услуги вам потребуются, на каких пунктах получится сэкономить и какие необязательны.
Хочется отметить, что работа над продуктом не заканчивается даже после релиза. Полученные в ходе тестирования выводы и наработки можно использовать для дальнейшего развития сервиса, добавления нового функционала и фичей. Поэтому лучше всего, если весь цикл разработки вы заказываете у одной компании — так вы получите готовый продукт, который при высокой нагрузке будет работать бесперебойно.
Источник: https://www.novostiitkanala.ru/news/detail.php?ID=164084
