Для меня в свое время было шоком, что можно не стремится делать идеально, а стремится делать стабильно и предсказуемо хорошо.
Идеально - это прекрасная история, но часто у бизнеса нет на это ни сил не времени, а человек-перфекционист перегорает достаточно быстро.
Что же я делала, чтобы меня попускало?
⸻
-
Отслеживала автоматический критик-монолог
Написала на на листе типичные фразы: «Если я не найду 100 % багов - значит я плохой тестировщик»
Поменяла их на «Задача тестирования - найти критичные дефекты. Остальное - бонус»
Каждый раз, когда слышала старую фразу, проговаривала новую вслух -
Проверка фактов (КПТ-упражнение)
Когда кажется, что «всё плохо», я концентрировалась на обьективных данных
- – число открытых багов
- – % критичных дефектов в продакшн
- – отзывы коллег по качеству выпуска
Сравнивала с предыдущими релизами и оценивала прогресс
-
Метод «достаточно хорошо»
Для каждой задачи установила минимальный порог качества (Definition of Done)
Решила заранее, что выполнено «достаточно хорошо», чтобы закрыть тикет и двигаться дальше
Фокусируйровалась на рисках бизнеса, а не на микродеталях интерфейса
-
Планёрка «быстрая ретроспектива страха»
В конце спринта спрашивала у себя : «Что мы боялись не успеть или не заметить?»
Отметчала, сколько страхов оказалось реальными, а сколько - выдуманными
Переносила истинные проблемы в план улучшений
-
Техника «шаблонного вопроса»
Вместо «а что если я что-то пропущу?» задавала себе «что я могу проверить прямо сейчас, чтобы снизить риск?»
Уточняла конкретный чек-лист: API-стабильность - сценарии переключения сети - отзывчивость экрана
Делала эти проверки по расписанию, а не по тревоге
-
Ограничение времени на проверку
Ограничивала время на проверку задач
По истечении времени оформляла то, что есть, и шла дальше к следующей задаче
Так я тестировала действительно важное
-
Рефрейминг результата
После каждого релиза завела «дневник успеха»:
- - баги, которые удалось предотвратить
- - метрики стабильности (Crash Rate, SLA-показатели)
- - отзывы коллег и пользователей
Стало видно, что мы улучшили
Это поможет увидеть вклад вашего тестирования не как «что могло пойти не так», а как «что мы улучшили»
Перфекционизм в QA - это симптом высокой ответственности. Используйте эти приёмы, чтобы не позволить тревоге захватить вашу энергию, а направить её на реальные улучшения продукта.
