Чего не хочешь касаться в работе

Мои профессиональные ограничения как QA Engineer

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

Аспекты, которых я сознательно избегаю:

1. Тестирование без документации или четких требований

• Полное отсутствие спецификаций или пользовательских историй превращает тестирование в гадание. Я откажусь начинать тестирование, если нет хотя бы минимального набора критериев приемки (acceptance criteria).
• Пример ситуации, которую я не буду поддерживать:

# НЕПРИЕМЛЕМО:
Когда разработчик говорит: "Просто потестируй, всё поймешь"
# ПРИЕМЛЕМО:
Когда есть хотя бы базовые сценарии:
Given пользователь на главной странице
When он нажимает кнопку "Купить"
Then открывается форма оформления заказа

2. Работа в условиях постоянного "ручного пожара"

• Регулярные авралы из-за отсутствия тестовой стратегии, автоматизации и профилактических мер. Я готов помогать в критических ситуациях, но если это становится нормой — это сигнал о системных проблемах процесса.

3. Конфликтная коммуникация вместо конструктивной критики

• Я избегаю формулировок в стиле "ваш код не работает" в пользу "я обнаружил отклонение от ожидаемого поведения". Различие в подходе:

**Непродуктивно:**
• "Эта фича сломана"
• "Вы опять допустили баг"

**Продуктивно:**
• "Нашел расхождение: при X ожидается Y, но наблюдается Z"
• "Можем обсудить edge case, который не был покрыт"

4. Тестирование в изоляции от команды

• QA как "отдел полиции", который только ищет виноватых. Я верю в модель "качество закладывается на всех этапах", где тестировщик — партнер разработчиков, а не надзиратель.

5. Работа с устаревшими методами без возможности улучшений

• Компании, где отвергаются современные подходы: CI/CD, автоматизация регресса, тестирование производительности как часть pipeline. Пример технического долга, который я не поддержу:

# Процесс, от которого я откажусь:
Ручное тестирование 1000 тест-кейсов перед каждым релизом
# Процесс, который я предложу:
Автоматизация 80% регрессионных проверок + risk-based ручное тестирование

6. Нарушение этических границ

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

Что стоит за этими ограничениями?

Мой опыт показал, что соглашаться на перечисленные условия означает:

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

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

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