Почему твой разработчик злится? Если поковыряться в мемах про айтишку, то можно нарыть достаточно много разнообразного контента на тему вечного противостояния между разрабами и тестерами, отсюда вытекает достаточно много стереотипов о вражде между ними. Это всё конечно же шутки и за гаражами мы не выясняем отношения друг с другом, но и мемы не рождаются на пустом месте. Работа в коллективе - это почти всегда потенциальные конфликты. Мы все разные. У нас могут отличаться культурные ценности, взгляды на работу и процессы, разные характеры, разные поколения и разная зона ответственности. Всё это частенько становится плодородной почвой для холиваров и разборок, которые могут очень деструктивно влиять на общие рабочие процессы и подрывать командный дух. Ты не можешь контролировать на всё это и залезть каждому коллеге в голову, чтобы избежать любых недопониманий, но кое-что сделать ты всё же можешь. Попробовал составить список самых распространённых вещей, которые раздражают и злят твоих коллег из разработки: - Приносить необдуманные баг репорты. Многие QA испытывают эйфорию, когда увидели что-то неправильно работающее и быстрее стремятся это зафиксировать, и отнести разработчику, но не все баги одинаково полезны. Когда работаешь второпях и необдуманно, то очень часто получаешь на такие баги ответ "Не воспроизводится". Сделаешь так раза 2-3 и сразу начнёшь раздражать своего коллегу, и скорее всего получишь от него порцию токсичных сообщений. Не торопись любую проблему оформлять в баг репорт, убедись, что точно собрана вся фактура и баг стабильно воспроизводится. - Приносить дубли баг репортов. Перед тем, как что-то заводить, попробуй проверить, а не завели ли это до тебя. Да, не всегда получается найти в таск трекере первую задачу, но как минимум постараться точно стоит. - Приносить не до конца оформленные баг репорты. Если к тебе часто приходят за уточнениями по каждому багу, скорее всего ты что-то делаешь не так. У большинства разработчиков знания о системе очень сильно ограничены контекстом их кода, они не знают продукт так же хорошо, как знаешь ты. Не поленись нормально описать шаги, прикрепить все тестовые данные и обязательно пропиши внятный ожидаемый результат. - Задавать поверхностные вопросы. Перед тем как что-то спрашивать, потрать 20 минут времени на ресерч и поиск. Посмотри все статьи и ссылки прилинкованные к таске, почитая статьи в корпоративной базе знаний, если за 20 минут поиска ничего не нашлось, скорее всего вопрос не самый тривиальный и его можно задать. - Спихивать на разраба бизнесовые решения. Если вы с разработчиком уперлись в какой-то спорный момент, и этот момент не технический, то не стоит на него давить, чтобы он решил как должно быть. Есть продакты, есть аналитики, стоит переадресовать эти спорные моменты им, чтобы они приняли волевое бизнес решение. - Писать о проблемах до конца тестирования. Не стоит разрывать личку разраба, принося по крупинке баги. Нужно закончить тестировать хотя бы какой-то блок задачи и принести проблемы целиком, чтобы на них можно было бы взглянуть комплексно, видя общую картину проблем. - Звать разработчика на все встречи подряд. Перед тем, как добавить коллегу разраба во встречу или кинуть ссылку на звонок, задумайся, а точно ли он нужен и сможет помочь? Никто не любит сидеть в звонке и никак в нём не участвовать. - Заниматься избыточным тестированием. Невозможно заниматься тестированием задачи бесконечно, все баги мира не отловишь и мариновать неделями задачи не стоит. А на что злятся твои разработчики? Делись в комментариях💅 #БОзаметки #безотказов Навигация канала | Подписаться | Менторство