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