Особенности проекта
Как было:
На проекте существовала команда разработки, но без тестировщика. Проект невероятно быстро рос и появилась необходимость феншуйно внедрить и настроить тестирование на проекте.
Этапы работы
Анализ и планирование работы
Описали баги, которые обнаружили на предпроектном исследовании, также записали видео инцидента, чтобы клиент видел, как мы будем находить и оформлять баги в Jira еще до заключения договора.
Распределили структуру внедрения тестирования по спринтам.
Тест-кейсы
До этого тестирование проводилось без определенных сценариев. При таком подходе проскальзывают баги и не учитываются всевозможные действия юзера.
Внедрение TestRail
С помощью TestRail мы структурировали всю документацию, а также во время смоука и регрессионного тестирования видели какие чек-листы и тест-кейсы не выполнялись, что позволило минимизировать количество возможных багов в релизе.
Внедрили сервис для записи багов “Bird eats bug”
Внедрили “Bird eats bug”, это позволило записывать баги с отображением консоли, сети, информации о системе, что ускорило понимание причины бага.
Переработали процесс тестирования, внедрив новые этапы
Усовершенствована доска kanban, на которой для тестирования было выделено три колонки: testing, testing pass и ready to prod.
Флоу следующий: все тикеты после разработки попадают в колонку testing.
После успешного тестирования тикет попадает в колонку testing pass, если были найдены недочеты или баги, тикет отправляется в разработку на исправление. После того как накопилось достаточное количество тикетов перед релизом в колонке testing pass, проводится повторное тестирование тикетов.
Smoke тесты
Провели smoke test для того, чтобы проверить работают ли основные функциональности на проекте. И передать билд обратно в разработку при наличии явных багов, чтобы не тратить время на заведомо дефектную версию.
Регрессионное тестирование
Регрессионное тестирование всегда выполняется перед релизом, оно показывает как влияет новый функционал на ранее разработанный, и в целом, проверяет общее функционирование системы. После успешного проведения регрессионного тестирования, тикеты попадают в колонку ready to prod. И только после этого происходит релиз.
Проблемы на проекте
Каждый день сервис выкатывает новую NFT в одно и тоже время. Сотни тысяч юзеров идут, чтобы забрать ее. В такие моменты мы отлавливали 502 ошибку из-за перегруза.
Заказчик решил данную задачу оптимизацией ресурсов тестирование. Безусловно внедрение нагрузочного тестирования следующий обязательных шаг.
Заказчик, не лишенный самоиронии, создал NFT с отсылкой к памяти об этом баге.
Результаты
Технологии
Команда
Владимир Белов лид тестирования