Привет, Хабр! Меня зовут Герман, я давно работаю в тестировании (ex Тинькофф, Островок, Яндекс).
Про тестировщика создаётся стереотип ворчуна, который постоянно всем недоволен и занимается только тем, что ищет изъяны в чужой работе.
Поделюсь своим опытом — как тестировщику критиковать и сохранить хорошие отношения с командой.
Твою критику не должны воспринимать в штыки. С командой тебе работать несколько лет, ходить с ними в барчик и ещё карьеру как-то строить.
Тестировщик — это критик
Когда ты авторитетный критик — к твоему мнению прислушиваются. Вышел Hogwarts Legacy – перед покупкой игры ждём, что скажут критики.
Когда ты работаешь тестировщиком — тебе приходится критиковать: тут баг, а тут авторизация не работает, а тут ручка вернула 500-ку, а тут документация устарела, а тут логов в кибане нет, а тут тестовое окружение недоступно.
Если будешь заводить много багов — считай, критикуешь разработчика. Мало — могут сказать, что ты не эффективный QA.
Как же критиковать и сохранить хорошие отношения с командой?
1. Начни писать
Прочитай книги Ильяхова. Попробуй написать про свой полезный опыт в песочницу Т-Ж. Хорошо сформулируй технический вопрос на Stackoverflow.
Это даст тебе навык системно и структурно доносить свою мысль другому человеку текстом и нормально описать проблему в баг-репорте.
2. Развивай критическое мышление
Задавай себе вопрос — «а почему так?». Не принимай всё на веру. Критическое мышление хорошо развивает широкий кругозор: путешествия и опыт работы на нескольких проектах.
С развитым критическим мышлением у тебя получится хорошо аргументировать свою позицию.
3. Отключай эмоции
Пользователь, который не смог сделать денежный перевод (словил баг),
может нагрубить в саппорт — вы а#у#ли там!
Не нужно эти эмоции передавать разработчику в баг-репорте.
Пиши по делу: [crit][prod] Не работают переводы на счета нерезидентов.
Затронуло 60% пользователей.
4. Научись выражать своё мнение
Прочитай статью на Habr или VC.
Если не согласен с автором — попробуй написать в комментариях свою критику так, чтобы она была конструктивной.
5. Разберись в азах хороших интерфейсов
Прочитай Ководство Лебедева, чтобы критиковать UX решения и объективно аргументировать своё мнение.
6. Учись в процессы
Очередной раз досталась задача без описания — не критикуй. Заведи сам шаблон задачи и попроси проджекта его использовать.
На планировании разработчики забывают взять в работу баги — не критикуй. Создай бота, который раз в неделю будет присылать в slack топ самых критичных багов.
И прочитай книгу Товеровского по управлению проектами.
7. Сначала хвали, потом критикуй
Со временем ты замечаешь, что когда разработчик показывает тебе наработки по сайту — твоя первая реакция: «смотри, в футере съехала кнопка».
Ты уверен, что тем самым помогаешь разработчику. Но ждут от тебя в этот момент не критики. Оцени его работу — «Ого! Мне нравится!» И затем расскажи про найденные баги — структурировано, но не обидно.
P.S. На пост меня вдохновил один из многочисленных комментариев от @lxsmkv
P.P.S. Я создал волонтёрский проект Джуны — где начинающие тестировщики бесплатно протестируют ваш сайт, бота или ноу-код решение. Если есть что протестировать — пишите :)
