Тестеры не виноваты в ваших багах

Каждый раз когда выходит забагованное нечто - я вижу в интернете одни и те же комментарии: куда смотрели тестеры? У них вообще был QA-отдел? почему игру выпускают без тестирования? Как можно было не заметить ЭТО?

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

Первое: большинство багов всегда находят пользователи.

Во всех продуктах есть баги, где-то больше, где-то меньше. Но чисто статистически, команда разработки не может найти багов больше, чем пользователи. Потому что пользователей больше на много порядков + пользователям доступны все спеки мира + пользователи совершают сценарии, которые просто не имеет смысла проверять при стандартном процессе. Другое дело, что тестеры отлавливают большинство критических проблем, которые полностью поломали бы пользовательский опыт, либо привели бы к каким-нибудь секьюрным проблемам. Кстати, новичка в тестировании легко заметить, когда он в исследовательском тестировании начинает искать баги, а не проверять, что все работает при разных сценариях (нет, это не равнозначные значения)

Второе: тестировщики сообщают о состоянии проекта, а не делают/чинят баги.

Несмотря на то, что именно QA-инженеров чаще всего связывают с качеством продукта (тут у нас как-бы даже в названии специальности есть quality), сами тестировщики имею довольно опосредованное влияние на качество. Очень грубое упрощение, но самое большое влияние на качество имеют разработчики. Потому что если разработчик напишет идеальный код без единой ошибки (при идеально составленных требованиях), то тестировщик попросту не понадобится. Так как у нас все будет работать и так. Однако, этот вариант идеальный и нигде не встречается. Тестировщик нужен для того, чтобы проверить работу программиста, аналитика, дизайнера, etc и сообщить о том, движется ли команда в правильном направлении, соответствует ли продукт заданным требованиям и соответствует ли он вообще здравому смыслу. И после того как тестировщик посмотрел и рассказал о состоянии продукта, приходит ЛПР (лицо принимающее решение) и принимает решение, что делать дальше. И тут мы подходим к тому что
Третье: баги - это всегда компромисс.

Любая разработка это менеджмент ресурсов. У нас есть ресурс разработчиков, ресурс тестеров, ресурс дизайнеров/моделеров/вставить что угодно. И когда менеджер направляем разработчика править баг или работать с техдолгом, то в это время этот юнит не занимается разработкой фич. А именно фичи делают продукт тем, что он есть. И в большинстве случаев новая фича приоритетней чем уменьшение количества багов. Задача тестировщика - очень сильно покричать о встреченных проблемах и рассказать о их серьезности, посчитать риски, если тестировщик покруче. Но приоритет в любом случае будет ставить человек, стоящий выше. И выбирать что делать в новом спринте - тоже он. Поэтому не удивительно, что многие баги висят не исправленными годами. Это не потому что о них не знают, это не потому что все ленивые скоты, и не потому что всем пофиг. А дело лишь в том, что взять и найти ресурс под починку вещей, которые не то чтобы сильно влияют на юзер экспириенс, вместо того, чтобы делать что-то новое/чинить важное - признак непрофессионализма.
Конечно, все это не отменяет того факт, что тестировщики могут дико облажаться и пропустить в прод какую-нибудь лютую дичь, такое встречается повсеместно. Но это точечные случаи, а не общее состояние. Не думайте, что команда разработки вообще не видит, что она делает. Она прекрасно понимает, что выкатывает на прилавок. А вот можно ли такое выкатывать в нынешнем состоянии - вопрос на совести совсем не тестировщиков.

p.s.: написал это больше для людей не в теме, так что пожалуйста охладите холиварные порывы, если они вдруг появятся. Я прекрасно знаю, что в разных компаниях задачи тестеров отличаются, что некоторые различают тестеров/qa/qc и так далее, профессия полна тонкостей о которых можно спорить часами. Пост не об этом.

#разработка #разработкаигр