Solo QA в команде. Часть II.
6. Тестовую документацию оформляй однообразно. Гораздо проще просматривать документы оформленные одинаково, чем документы оформленные каждый по-своему. Сэкономишь и время и силы;
_7. Создавай баг-репорты сразу как заметил баг._ Если отложить создание баг-репорта потому что баг кажется незначительным, то мало того что он может оказаться критичным, но и даже если баг всё-таки окажется некритичным, то он рискует на долгое время затеряться в баг трекере - чем позже будет создан баг-репорт, тем меньше вероятность что он будет исправлен в ближайшее время;
_8. Приходи на созвон по новым фичам даже если тебя туда не звали._ Часто в некоторых командах QA подключают к фиче только на поздних этапах разработки, из-за чего у QA нет возможности внести свои правки в требования или высказаться о рисках. В итоге на тест фича может попасть с проблемами которые было было проще решить на этапе планирования фичи;
_9. Анализируй макеты сайта / приложения разрабатываемой фичи._ Макет и фактическая реализация могут различаться, потому что дизайнер не всегда знает технические тонкости того для чего он рисует макет. Проще "сгладить углы" и внести правки в макет, чем в функциональность;