С чем не хочешь столкнуться на новой работе

Критерии выбора нового рабочего места

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

1. Токсичная культура и отсутствие психологической безопасности

Это фундаментальный блокер для любого QA.

• Культура обвинений (Blame Culture): Когда дефект в продакшене приводит не к анализу процесса, а к поиску «крайнего» — тестировщика или разработчика. Это убивает прозрачность, люди начинают скрывать ошибки и информацию.

  # Пример "культуры обвинений" на практике:
  # Вместо конструктивного: "Почему баг прошел на прод? Давайте улучшим тест-кейс и добавим автоматизацию на этот сценарий."
  # Звучит как: "Кто это пропустил? Это вина QA. Составим выговор."
  

• QA как "полиция качества" или "ворота": Если от моей единоличной подписи зависит выход релиза, это признак глубокой дисфункции. Качество создаётся всей командой на всех этапах, а QA — это эксперт и партнёр, а не контролёр.

2. Архаичные процессы и пренебрежение современными практиками

• Полностью ручное регрессионное тестирование перед каждым релизом без инвестиций в автоматизацию. Это неэффективно, демотивирующе и приводит к усталости от тестирования.
• Отсутствие CI/CD и длинные релизные циклы: Когда процесс выкатки — это многодневный мануальный квест. Я верю в скорость и стабильность через непрерывную интеграцию и непрерывную доставку.
• Тестирование — последний этап (Waterfall): Когда разработка «перебрасывает» готовую фичу через стену для тестирования. Это создаёт узкие места, снижает качество дизайна и приводит к конфликтам.

3. Непонимание роли QA и низкий статус профессии

• QA как "человек-кликер": Если от меня ожидают только выполнения готовых чек-листов без участия в планировании, оценке рисков, дизайне фич и улучшении процессов — это тупиковый путь.
• Отсутствие инженерного подхода: Когда в команде нет понимания ценности тест-анализа, пирамиды тестирования, работы с метриками качества или тест-дизайна.

  // Пример инженерного подхода: тест не как набор шагов, а как проверка поведения.
  // Плохо: "1. Ввести 'abc' в поле логина. 2. Нажать Enter."
  // Хорошо (в концепции): 
  @Test
  public void shouldNotAuthenticateWithInvalidCredentials() {
      var result = authService.login("abc", "anyPassword");
      assertThat(result.isSuccessful()).isFalse();
      assertThat(result.getError()).isEqualTo(ErrorType.INVALID_LOGIN);
  }
  

• Недоинвестирование в инструменты и обучение: Нельзя ожидать высоких результатов, если у команды нет доступа к современным средам, системам управления тестами (TestRail, Qase), инструментам для автотестов или бюджета на курсы и конференции.

4. Нереалистичные ожидания и управление

• Миф о 100% качестве и нулевых багах: Это противоречит законам сложности систем. Разумнее говорить об приемлемом уровне риска и скорости реакции на инциденты.
• Оценка эффективности QA по количеству найденных багов: Это провоцирует конфликт интересов с разработчиками и не отражает реальной ценности — предотвращения дефектов, снижения рисков и уверенности в продукте.
• Постоянные авралы и выгорание как норма: Если «горят» все релизы подряд — это проблема планирования и приоритизации, а не повод для героизма.

Итог

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