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

Прекрасно, вам должны платить просто так! Ведь мы работаем только так как написано в ISTQB, а там много чего написано) И на заборе тоже написано...

Вам задают простой вопрос, почему вы пропустили баг на прод? Это обычный разбор полетов после релиза и нужно учится на своих ошибках, прежде чем стартанет следующий горящий релиз! И нам необходимо объяснить причину, которая скрывается не только в процессах тестирование, но и в процессах всей команды.

Причины пропуска багов:

Парадокс пестицида (одни и те же кейсы каждый раз).
Слабое покрытие тестами всего функционала (матрица трассировки).
ТК кривые и косые - нет точных описаний и отсутствие подготовки тестовых данных.
ТК никто не проходит, а просто красят в зеленый.
Требования поменялись в последний момент.
Отсутствие времени на тест-дизайн и анализ требований.
Отсутствие времени на регресс.

Причины возникновения багов я описывал в этой статье. Но проблема здесь не в возникновении бага, всем плевать почему разработчик не проходит самопроверку после выполнения задачки и багов тьма тьмущая. Здесь претензия почему тестирование упускает баги, ведь этап тестирования это узкое горлышко бутылки.

Хотя кто слушает тестировщиков, точно не разработка. И выходит так, что разработка делает, что хочет, а отдувается тестирование т.к. неважно кто начал, важно кто продолжил.

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

Экономия на сотрудниках бывает разная:

Взять дешевого разработчика - "У нас трудные времена и бюджет урезали."
Взять джуна тестировщика единственного на проект - "Ему соседние команды помогут влиться в процессы. Из джуна сделаем мидла!"
Имитация Agile-процессов - "Зачем нам ретро каждые 3 недели. Это на каждого сотрудника по 3 часа тратиться. Пусть лучше делом займутся."
Поиск виноватых в обнаруженных багах на проде - "Ты пропустил баг, из-за тебя сейчас будет хотфикс. Нужно подключится в 21:00 к хотфиксу."

На помощь приходит QA-лид, который тебя выслушает и предпримет меры по устранению нарушенных процессов, ну или свалит на тебя всю вину - смотря как тебе повезло с лидом.

А куда будут записаны найденные нарушения и кто возьмет ответственность по исправлению? Для начала определим первопричины бага...

На каких этапах возникают баги:

От идеи в бизнес аналитику - клиентский путь неверный, надо было не так делать. Обычно тестировщика это не касается и никто нагло на него такой косяк не сваливает.

От системного анализа в разработку - описано с точки зрения системных требований нереально и разработка сделала как посчитало нужным самостоятельно. Между друг другом (аналитик и разработчик) не связались, а спрашивают с тестировщика "Почему реализовано не так?".

От разработки в тестирование - были пропущены ошибки по разным причинам, я их описал выше в "Причины пропуска багов".

После определения причины это выносится на общие процессы команды: команда разработки проводит самопроверку своих выполненных задач, и если нужно, отчитывается по чек-листу что было проверено. Этот чек-лист может составить тестировщик на этапе анализа требований и прикрепить к задаче на самопроверку разработчика.

Почему разработчик должен тестировать? Потому-что это не тестирование, а success test, то есть надо обязательно проверить как работает твой чудесный код. Если разработчик не должен проверять свою работу, то и аналитик не должен проверять свой системный анализ. Но каждый сотрудник проверяет письма на ошибки, документы на корректность перед отправкой и т.д. И разработчик тоже обязан проверять свою работу. Я лично слышал от разработчика "Я не тестировщик, чтобы тестировать".

Если процесс сломался на разработке, то остается это подсветить и объяснить со своей позиции почему отсутствие самопроверки оказывает прямое воздействие на качество функционала на проде.

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

Хочу прояснить, что тестирование зависит от контекста и я не могу вам дать готовые решения как правильно протестировать ваш функционал. Спасибо за понимание!

Как итог нет виноватого, каждый ИТ-специалист влияет на качество функционала:

Владелец продукта (отвечает за цель и движение продукта)
Бизнес аналитик (отвечает за клиентский путь, удобство использования продукта)
Системный аналитик (отвечает за внедрение и использование инструментов разработки)
Команда разработки (отвечает за реализацию функционала)
Команда тестирования (отвечает за проверку функционала)
DevOps инженеры (отвечают за равертывание функционала)

Помимо вышеперечисленных есть также Head of QA, Релиз менеджер и Tex-лид, которые также влияют на процесс разработки и обеспечения качества.

Памятка для тестировщика:

Если в команде нет цели найти причину бага, а есть лишь цель найти виноватого, то необходимо взять ответственность за освещение данной проблемы. Иногда это поможет запустить процесс по исправлению ситуации. Разговор - это самое эффективное средство, в сравнении с молчанием и уходом из команды. Также считаю нет ничего страшного подсветить проблемы работы лида, раз уж на вас всё сваливают) Молчание - знак согласия.

Контакты:

Мой Telegram-канал QAtoDev
Моя бесплатная QA-песочница по тестированию и подготовки к собеседованию