У QA инженера это особенно выделяется. Сама наша профессия уже подталкивает к буквоедству: мы составляем чек-листы, описываем требования, шаги воспроизведения, проставляем статусы, процессы. Без этого тестирование быстро превращается в хаотичное «тыканье в приложение». И это правда. Но иногда можно уйти в крайность, и QA начинает защищать процесс вместо продукта.

Расскажу про баг «не по шаблону». Тестировщик находит проблему, но разработчик отвечает: «По требованиям всё верно». И формально он почти всегда прав. А пользователь всё равно будет страдать. Хороший QA в такой ситуации смотрит не только в тикет, но руководствуется здравым смыслом: как это выглядит для человека, который будет пользоваться системой каждый день.

Конечно же, всегда есть обратная сторона. Некоторые тестировщики настолько хотят быть «гибкими», что перестают фиксировать договорённости. В голове всё понятно, устно обсудили, «да потом поправим». А через неделю никто уже не помнит, что именно решили. Сколько раз я сам так делал по неопытности, в пылу рабочего процесса, а потом встречал у своих подчиненных. Сотни случаев, когда забыли подитожить и где-то указать. Спустя время получаем баги, конфликты и бесконечные созвоны. Формальности начинают казаться душнотой ровно до первого серьёзного инцидента.

Очень показателен подход к баг-репортам.

Буквоед напишет: * окружение, * браузер, * build, * 25 шагов, * 14 скриншотов, * логи за последние полчаса. Из этого всего будет невозможно понять, что именно ломает систему.

Слишком гибкий специалист делает наоборот: «Всего-то кнопка сломалась, легко повторить». И разработчик полдня будет пытаться воспроизвести проблему. Или сразу писать Вам и отвлекать.

Нормальный баланс выглядит иначе: Необходимо дать достаточно информации, чтобы проблему можно было быстро понять и исправить, но не превращать баг-репорт в томик "Война и мир".

То же самое с тест-кейсами. Плохой буквоед будет проверять пиксельные отступы в момент, когда на проде падает оплата. Потому что «тест-кейс надо пройти полностью». Гибкий специалист умеет менять приоритеты и понимать контекст.

Именно поэтому сильные QA со временем становятся менее «процессными» внешне. Не потому что им всё равно на качество, а потому что они начинают понимать, зачем конкретный процесс существует и где он реально приносит пользу.