Тестирование проектов: ожидание и реальность

Людям свойственно не замечать свои косяки. Мозг подсознательно будет уводить от "глючной" кнопки или сценария, если это твой код ) Хороший/вредный тестер всегда нужен команде )

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

Если условные аналитики плохо описывают функционал, то стоит искать способы давления на них: через тех, кто от этого страдает, через безопасников (если они есть). Люди должны работать нормально, а не сваливать исправление своих косяков на коллег. Не «Горят сроки, надо сегодня выпустить релиз», а «Я решил выслужиться перед заказчиком, понимаю риски недостаточного тестирования и невозможности его проведения в такой срок, ответственность несу единолично сам».

Часто проблемы возникают в том числе из-за того, что многие люди достаточно умные и хитрые не только для того, чтобы работать хорошо, и придумывать решения для сложных задач, но и для того, чтобы умело скидывать ответственность, получая ништяки. Условный начальник взял ещё один проект на отдел, получил +20% денег, качество упало, а в этом уже виноваты тестировщики.

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

Чем вообще в проекте занят аналитик, если работу за него делают тестировщики?))) и где тут автоматизация? Если нет хотя бы юнит тестов, тестировщики вечно будут бегать с горящими задами, особенно если проект разрастется. Не всё знают про паттерн пирамиды тестирования "рожок мороженого", зато всё в него исправно попадают.