Дедлайн был вчера: как тестировать код в срочных релизах и не выгорать

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

Всем привет! Меня зовут Ульяна, я тестировщик в Selectel. Мы регулярно релизим новые фичи в своих продуктах, следовательно, постоянно их проверяем. В этой статье я хочу рассказать об опыте, который получила на старте карьеры, работая в небольших компаниях — как тестировать код, если сроки постоянно горят.

Используйте навигацию, если не хотите читать текст полностью:

→ Что случилось

→ Как я взяла себя в руки и сделала невозможное

→ Выводы

Как-то в размеренную и четко регламентированную процессами жизнь нашей команды прилетела молния. Нам сообщили, что HR решили изменить внутреннюю систему (для сотрудников) через два месяца. А так как системой занималась моя команда, задача стала нашей.

На подготовку спецификации, разработку и тестирование заложили всего три недели. То есть мы оказались в ситуации, когда все нужно делать в ускоренном темпе.

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

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

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

В эту же встречу мы уместили совместное тестирование, на котором нашли основные ошибки и распределили по времени исправления. Критичные добавляли в текущую задачу, чтобы пофиксить сразу. А менее важные, долго реализуемые или не влияющие на UX и работу системы, отложили на потом.

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

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

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

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

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

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

В компании существует правило: после 17:00 не релизить, чтобы не пришлось откатывать или исправлять ошибки среди ночи. Ближе к вечеру мы поняли, что релиз переносится на завтра — так у нас появилось время, чтобы добавить и протестировать еще одну фичу.

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

Я сделала для себя несколько выводов.

Заключения, возможно, очевидные, но не когда сталкиваешься со стрессовыми ситуациями в реальности. Желаю вам спокойствия, терпения и поменьше таких срочных задач!

Пройдите небольшой опрос, чтобы мы могли показывать вам только лучшие материалы. Среди всех участников разыграем игрушечного Тирекса. Результаты — 13 декабря.