Как тестировать код, когда сроки горят

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

Меня зовут Ульяна, я тестировщик в Selectel ^[1]. Однажды и в моей жизни произошла такая история: заказчики торопили разработку, а времени на тесты не хватало. Как быть в этой ситуации и выйти из нее с наименьшим ущербом для своей психики и хорошим результатом — расскажу в статье.

Используйте навигацию, если не хотите читать текст полностью:
→ Что случилось ^[2]
→ Как я взяла себя в руки и сделала невозможное ^[3]
→ Выводы ^[4]

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

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

Шаг 1. Настроиться на работу

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

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

Любимые мемы, которые помогли мне настроиться.

Шаг 2. Обсудить интерфейс и провести первые тесты

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

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

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

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

Шаг 3. Отказаться от лишних тестов

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

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

Шаг 4. Провести финальное тестирование и выпустить в прод

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

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

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

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

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

• Если менеджер требует срочного релиза, часть ответственности можно переложить на него.
• Нервы, негативные эмоции и суета не помогают в работе. Если зашкаливает, стоит сначала успокоиться, прийти в себя и только потом возвращаться к задаче. Так работа пойдет гораздо быстрее и с меньшим количеством ошибок.
• Не все вещи одинаково важны. Что-то можно отложить, что-то может оказаться лишним, и это можно не реализовывать, а что-то, наоборот, очень важно. Нужно выяснять всю информацию из доступных источников, анализировать и учиться грамотно приоритизировать задачи и действия.
• Учимся планированию и тайм-менеджменту. Сколько времени займет каждая задача, что мы успеем сделать сейчас, а что придется отложить на потом. То есть важно сначала выяснить детали и расставить приоритеты, а потом приступать к работе.
• «Работа не волк, работа — ворк». Этот пункт — следствие всех предыдущих. При планировании нужно учитывать только рабочее время. Не стоит тратить на задачи выходные — иначе наступит усталость, а за ней придет выгорание.

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