Тестирование приложения с часто меняющимся кодом: проблемы и решения

Ключевые слова: тестирование, стартап, agile, автоматизация, регрессия, развертывание, спринт, обнаружение ошибок, контроль качества, веб-приложение.

Тестирование приложения в стартапе может быть сложной задачей из-за частых изменений в кодовой базе и требованиях. В этой статье я расскажу о моём опыте работы тестировщиком на подобном проекте, выявлении и решении основных проблем, которые повлияли на процесс тестирования и качество продукта. В статье также обсуждаются решения, которые были мною внедрены для преодоления этих проблем. Что в свою очередь привело к повышению эффективности тестирования более чем на 300%, а также ускорению процесса доставки продукта в пользовательскую среду в 3 – 4 раза. Проблемы и решения связаны со временем развертывания проекта, количеством задач, регрессионным тестированием, обнаружением ошибок, а также продолжительностью спринта и временем релиза продукта. Статья завершается некоторыми предложениями по дальнейшему совершенствованию и будущим исследованиям оптимизации процесса тестирования.

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

Недавно у меня появилась возможность поработать тестировщиком в стартапе. В этой статье я опишу основные проблемы, с которыми я столкнулся в качестве тестировщика на этом проекте, и действия, которые я предпринял для их решения.

Проект включал разработку веб-приложения для управления продажами. Он характеризовался ограниченными ресурсами, как людскими, так и материальными. Я был единственным тестировщиком в команде в противопоставление растущему числу разработчиков (сначала три, позже пять). Код приложения постоянно менялся в связи с появлением новой функциональности и меняющимися требованиями. Спринты были очень короткими, продолжались всего одну неделю. Релизы часто проходили в пятницу вечером, по “лучшим” традициям разработки, чтобы не срывать сроки.

Проблемы

Основными проблемами, которые повлияли на процесс тестирования и качество продукта, были:

• Длительное время развертывания: развертывание тестируемой ветви в тестовой среде занимало от 20 минут до 1,5 часа в зависимости от того, включало ли это обновление базы данных или нет. Это задержало процесс тестирования и сокращало время, доступное для тестирования.

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

• Большой объем регрессионного тестирования: из-за частых изменений в коде и требованиях регрессионное тестирование было особенно необходимо, чтобы убедиться, что существующая функциональность не была нарушена новыми изменениями. Однако регрессионное тестирование было трудоемким и утомительным, особенно из-за отсутствия тестовых примеров или доступных автоматизированных тестов.

• Увеличение числа ошибок в клиентской среде: несмотря на усилия по тестированию, некоторые ошибки не обнаруживались до релиза и достигали клиентской среды. Они негативно сказывались на опыте пользователей и требовали исправления в последующих спринтах. Таким образом, задачи накапливались с течением времени, и тестирование становилось все более изнурительным.

Решения

Решения, которые были внедрены для исправления этих проблем, были следующими:

• Увеличение числа тестовых сред: вместо одной было создано несколько тестовых сред. Это позволяло распараллелить задачи: пока одна тестовая среда использовалась для развертывания кодовой ветки, другая использовалась для тестирования. Более того, при развертывании кодовой ветки с обновлением базы данных использовалась усеченная версия базы данных, чтобы уменьшить ее размер и ускорить процесс в 4 – 5 раз.

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

• Написание тестовых случаев и автоматизированных тестов: тестовые случаи писались для каждой задачи, чтобы обеспечить четкие инструкции по тестированию и служить источником достоверности (ранее на написание тестовых примеров не было времени, и дизайн использовался в качестве справочного материала). Для некоторых задач также были написаны автоматизированные тесты с использованием Cypress. Эти тесты сократили усилия на ручное тестирование и одновременно с этим увеличили охват тестирования. Однако автоматизированные тесты писались в последующих спринтах, когда функциональность уже была выпущена в клиентскую среду. Этот подход был выбран потому, что код был более стабильным после выпуска, что сводило к минимуму постоянное переписывание тестов из-за исправлений ошибок или изменений.

• Увеличение продолжительности спринта и перенос даты выпуска: продолжительность спринта была увеличена с одной недели до двух недель. Это дало больше времени для тестирования и сократило количество онлайн встреч, таких как планирование и ретроспектива. Дата релиза также была перенесена с пятницы на понедельник. Это позволило провести окончательное тестирование на свежую голову после выходных, что повысило качество тестирования. Это также позволило избежать вывода приложения с возможными ошибками в клиентскую среду на период выходных дней.

Вывод

В этой статье я рассказал об опыте тестирования приложения с часто меняющимся кодом в стартапе. Определил основные проблемы, которые повлияли на процесс тестирования и качество продукта, такие как длительное время развертывания, большое количество задач, большой объем регрессионного тестирования и растущее число ошибок в процессе производства. Также я изложил решения, которые были внедрены для преодоления этих проблем и повышения эффективности тестирования, такие как увеличение числа тестовых сред, сокращение количества задач, написание тестовых примеров и автоматизированных тестов, увеличение продолжительности спринта и перенос даты выпуска приложения. Эти решения помогли улучшить процесс тестирования и снизить нагрузку на тестировщика. Однако все еще есть некоторые области для улучшения и будущих исследований в области оптимизации процессов:

• Увеличение охвата и надежности автоматизированных тестов: автоматизированные тесты были написаны только для некоторых задач и в последующих спринтах. Следует писать больше автоматизированных тестов для критической функциональности и делать это параллельно с разработкой. Автоматизированные тесты также следует регулярно запускать и поддерживать в рабочем состоянии, чтобы обеспечить их точность и полезность.

• Внедрение непрерывной интеграции и доставки: непрерывная интеграция и доставка (CI/CD) - это практика, которая включает автоматическое и частое создание, тестирование и развертывание кода. CI/CD может улучшить процесс тестирования за счет сокращения времени развертывания, раннего обнаружения ошибок, увеличения обратной связи и обеспечения согласованности и качества.

• Улучшение коммуникации и сотрудничества между членами команды: коммуникация и совместная работа необходимы для успешного тестирования в стартапе. Члены команды должны регулярно и четко делиться информацией, ожиданиями, отзывами и предложениями. Они также должны использовать такие инструменты, как системы отслеживания ошибок, приложения для чата или видео звонки, чтобы облегчить общение и совместную работу.

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

Шевчук Виталий (Vital Shauchuk)