Один QA в поле воин?
Всем привет.
Меня зовут Пронин Евгений, я Senior QA Engineer. Я работал в студии ITTerritory в полноценном отделе тестирования с несколькими коллегами, также имел опыт как единственный инженер в стартапах. Я расскажу о своем опыте и поделюсь некоторыми наблюдениями, которые возможно помогут тем, кто тянет бремя тестирования в одиночку или решает в скором времени это попробовать :)
Почему экономят на тестировщиках?
Бизнес разработки игр по своей основной сути ничем не отличается от любого другого бизнеса главной задачей которого была и остается — это заработок денег.
Так как на любом из этапов проект может не реализовать ожидания, то небольшие студии пытаются сохранить деньги путем сокращения издержек. Это может быть использование триального ПО вместо приобретенных лицензий, отсутствие предоставляемой техники, отсутствие офиса, отсутствие привычных бенефитов в виде печенек, психолога и массажиста и так далее. Помимо предложенных ранее решений можно снизить затраты за счет уменьшения ФОТ или говоря простым языком — нанимая лишь ограниченное число сотрудников в отдел.
Зачастую таким «экономичным» отделом становится — отдел тестирования.
На этапе формирования и подготовки прототипа у QA нет полноценной нагрузки. Да, вы можете возразить, что в предыдущих статьях я говорил, что QA нужен с самого начала для выстраивания процесса тестирования, для интеграции тестирования в процесс разработки, для помощи руководству в настройке и выработке максимально производительного процесса разработки. Однако все это будет совершенно излишним, если средств в бюджете у вас максимум на 1–2 проекта. Лучше сохранить эти деньги на новый быстрый прототип или страхование рисков, чем на несколько полузагруженных тестировщиков.
Именно по этой причине большинство стартапов предпочитают ограничиться одним QA-инженером непосредственно до момента получения метрик, а иногда и вплоть до момента вынужденного расширения.
Почему QA вообще тяжело?
Как правило, QA страдает от проблем всех отделов тяжелее всего, так как находится в конце производственного цикла. Некорректно оцененные разработчиками задачи, неучтенные менеджментом риски, неграмотно распланированная передача задач между отделами все это ломает планы тестирования. Так как бизнесу в большинстве ситуаций очень важно сохранять даты mileston’ов, то принимается решение жертвовать не временем на разработку функционала, а временем на тестирование.
В некоторых компаниях возможны изменения сроков релиза, но для стартапов это критично.
Но это общие сложности для любого отдела тестирования, а теперь поговорим про сложности, которые могут возникнут из-за того, что вы единственный QA.
Что же вас ждет как единственного QA?
С момента трудоустройства вы, так называемый, Фёдор Иванович Крузенштерн — человек и пароход, в нашей истории человек-оркестр.
Так как у вас нет прямого руководителя, который занимался бы менеджерскими задачами, то значит эту лямку придется тянуть вам.
В некоторых компаниях роль менеджера QA отдела на себя берут PMы, CTO, Тех.лиды. Однако сейчас тенденция идет к тому, что эти обязанности выполняет сам QA-инженер.
Итак, по пунктам, вы берете на себя следующие обязанности:
Организация и управление процессами тестирования.
Разработка и внедрение стратегии тестирования.
Определение методов и процедур тестирования.
Выбор и настройка инструментов тестирования.
Планирование и анализ результатов тестирования.
Разработка и сопровождение документации по тестированию.
И непосредственно само тестирование.
Выглядит внушительно, не так ли?) А теперь посмотрим, с какими проблемами вы можете столкнуться если вы единственный специалист:
Одиночество: Вы можете почувствовать изоляцию из-за отсутствия коллег для общения и обмена идеями. Это также может повлиять на ваше моральное состояние и мотивацию.
Ответственность за принятие решений: Вам приходится нести основную ответственность за принятие ключевых решений. Это может быть стрессовым и создавать дополнительное давление.
Отсутствие обмена опытом: Без наличия коллег в отделе вы можете упустить возможность обмена опытом и учебы на их ошибках или успехах. Это может замедлить ваш профессиональный рост.
Риск одиночной точки отказа: Если вы заболеете, уйдете в отпуск или столкнетесь с неотложными обстоятельствами, отдел может столкнуться с проблемами, такими как задержки в проектах или ухудшение отношений с клиентами.
Трудности с балансом между работой и личной жизнью: Поскольку на вас лежит большая ответственность, может быть сложно находить баланс между рабочим временем и личной жизнью.
Отсутствие разнообразия в идеях: Без наличия коллег для обсуждения идей, вы можете оказаться в ситуации, когда вам сложно оценить различные точки зрения и подходы к решению задач.
Получается, что на нас лежит большая ответственность и при этом мы работаем за себя и QA Lead. Может возникнуть впечатление, что такая работа для мазахистов, но везде где есть минусы есть и плюсы.
Какие есть плюсы?
Поработав некоторое время как единственный QA я отметил для себя такие положительные аспекты:
Независимость: Вы полностью контролируете свою работу и принимаете решения без необходимости согласовывать их с коллегами. Это может способствовать более быстрому принятию решений.
Гибкость: Вы можете организовывать свой рабочий день так, как вам удобно, и адаптировать свой график под свои потребности.
Быстрое внедрение изменений: Без необходимости консультироваться с другими вы можете быстро внедрять изменения и экспериментировать с новыми идеями.
Личный рост: Ответственность за весь отдел может стимулировать ваш профессиональный и личный рост. Вы вынуждены развиваться и учиться самостоятельно.
Освобождение от конфликтов: Отсутствие коллег может снизить вероятность конфликтов внутри отдела и упростить взаимодействие.
Инструменты настроены под вас: У меня так было с оформление тест-кейсов. Я привык формулировать их под себя, актуализировать в удобное для меня время, переодически изменять состав так, чтобы он был максимально продуктивным.
Как можно помочь себе?
Работая в роли единственного специалиста, я разработал набор методов, которые помогли мне уменьшить влияние негативных аспектов как от работы QA в целом, так и от работы в одиночку.
При оценке задач всегда закладывайте риски на личные проблемы. Так как вы единственный специалист, вам нужно максимально подстраховаться. Болезни, жизненные случайности могут очень сильно отложить процесс релиза.
И еще раз закладывайте риски. Теперь уже на проблемы своих коллег. К сожалению, часто менеджмент игнорирует возможные форс-мажоры либо закладывает очень минималистичные. По итогу разболевшийся программист будет дописывать функционал во время регресса, уменьшая ваше время на тестирования.
Фиксируйте любые требования или договоренности с менеджментом в общих документах. На ретроспективе вы сможете поднять эти моменты и объяснить почему вы поступали именно так и кто вам это поручил.
Требуйте рекапы любых голосовых обсуждений. Часто случается, что исполнитель и заказчик о чем-то договорились, но никого об этом неинформировали. Так как проверять именно вам, то важно, чтобы у вас была вся актуальная информация.
Требуйте немедленных внесения правок в дизайн-документ при появлении новых изменений. Спустя какое-то время вы не сможете найти (вспомнить) все обсуждения и договоренности в чатах, ваших записях, задачах.
Переработки должны подробно обсуждаться с менеджментом и выноситься на ретроспективу. Кранч — это результат ошибок в планировании. Постоянный кранч — это выгорание для всей команды.
Приоритизируйте задачи и кейсы. Правильный план работ позволит вам покрыть самые уязвимые для багов функциональности и снизить их количество на продакшене.
Позитивные кейсы в первую очередь. В случаях острой нехватки времени возможно стоит обойтись без корнер и негативных кейсов. Функционал, в первую очередь, должен работать согласно дизайну.
Запрашивайте читы, моки и все что вам необходимо, чтобы самостоятельно создавать тестовое окружение. Чем больше у вас будет инструментов, тем проще и быстрее вам будет тестировать.
Автоматизируйте все, что попадается вам под руку: скачивание приложения, установка приложения, снятие скриншота, запись видео, создание бага. Это все занимает минуту-другую, но когда вам придется повторить это раз 30 за день, то вы будете счастливы, что эту вы сэкономили полчаса.
Будьте честны относительно ваших знаний с коллегами. Если вы не обладаете той или иной экспертизой, лучше об этом упомянуть, чтобы получить помощь или ликбез или дополнительное время на исследование/тестирование/изучение. Хуже оказаться с критичным багом в продакшене, чем признаться в недостатке опыта.
Ограничьте себя в митах. Большое количестов созвонов съедает уйму времени и сил. Планируйте только очень важные миты на первую половину дня, так как до обеда вы — максимально продуктивны.
Сохраняйте Work-Life balance. Ежедневная переработка истощает наши внутренние ресурсы. При исчерпании запаса ресурсов вы, скорее всего, заболеете. Так как вы единственный QA, то это нанесет гораздо больший вред проекту, чем польза от ежедневных переработок.
Кому не стоит работать одному?
Очевидно, если вы зависимы от команды. Отсутствие возможности консультироваться или обсуждать идей вас будет угнетать.
Гиперответственным людям. Вы будете всегда чувствовать, что должны вытянуть продукт. Вы скорее всего сгорите и пошатнете свое здоровье.
Неуверенным людям. Вам нужно будет принимать решения и много. Возможно вас может это ввести в панику.
Неопытным специалистам. Очень спорный пункт. При условиях поддержки со стороны квалифицированных коллег из других отделов неопытный сотрудник может очень быстро набрать нужных знаний и стать экспертом. Однако если у вас этой поддержки нет, то ваш проект будет немного страдать пока вы учитесь и допускаете ошибки, либо вы параллельно будете получать знания из доступных источников и работать, что очень тяжело. Поэтому я настоятельно не советую работать Junior и Junior-Middle специалистам в одиночку.
На этом все. Уверен, что есть много специалистов, которые имеют аналогичный опыт. Поделитесь в комментариях что вам помогало, что мешало и как вы это преодолели.
