Comments 11
Добрый день!
Спасибо за статью, весьма интересное мнение, особенно для первой статьи :)
Пишите, обязательно, еще!
Ниже дал некоторые комментарии как руководитель отдела разработки.
В самом низу есть определенные выводы.
Пишу то, в чем с вами, как автором, не согласен.
Могу быть не прав - везде своя кухня :)
Если хотите, то можем подробно обсудить потом детали - открыт к диалогу,
чем смогу - помогу :)
Но часто между ними возникает напряжение: тестировщики находят баги, разработчики видят их как критику. Как это изменить?
В данном случае вы видите, скорее всего, лишь часть картины.
Разработчик воспринимает это как критику не потому, что это его ущемляет, а потому, что это "не предусмотрено ТЗ".
Есть задача "собрать автомобиль на 4 человека".
Разработчик это делает.
Следом приходит тестировщик и садится на автомобиль сверху, составляет баг-репорт "проехал сверху - сдувает".
Разработчик идет к бизнес аналитику и спрашивает "а разве это бизнес-кейс?"
Аналитик идет к заказчику, который отвечает "Да, давайте предусмотрим такой вариант, мы про него совсем забыли".
Дедлайн никто не передвинет.
Т.е. то, что вы воспринимаете как негатив к тестировщику на деле является ошибками технического задания.
Используйте технический язык, но адаптируйте его:
Не начинайте разговор с эмоций ("Это же непрофессионально!").
Объясните, почему баг важен: "Если пользователь не может завершить покупку, это приведет к потере 20% конверсии".
Эмоции в баг репортах вообще недопустимы и не требуются.
Каждый выполняет работу так, как может.
Иногда кастомизация превращается в "кастылизацию" и с этим ничего не поделаешь.
Есть баг - его требуется описать.
Объяснять почему этот баг это важно - все же не задача тестировщика.
Это больше к руководителю проекта вопрос :)
Вы можете не знать "подкапотья" задумки и поставить высший приоритет вообще не важному багу.
Разработчики ценят, когда тестировщики не просто находят ошибки, но помогают их решать. Например: «Я попробовал найти способ обойти этот баг, но не получилось. Возможно, стоит пересмотреть архитектуру модуля?»
Рекомендую не давать советы по исправлению - это бесит разработчиков :)
У вас недостаточно для этого опыта и в большинстве случаев вы работаете в варианте Grey или Black Box, не понимая особенностей реализации.
Либо ваше место не в тестировании :)
Вы можете дать предположение о причинах формата "тронул модуль А - вылетел модуль Б", вот такой комментарий действительно поможет, он устанавливает причинно-следственную связь и дает предположение о том, где может быть источник.
Сфокусируйтесь на общих целях — качественном продукте. Вместо «Вы снова всё испортили» скажите: «Давайте вместе разберемся, как это исправить».
В каждой компании, конечно, своя кухня...
Однако, если тестировщик даст комментарий формата "вы виноваты",
то первое, что я сделаю как руководитель отдела - это задумаюсь, нужен ли такой тестировщик, который вместо командной игры перекидывает ответственность :)
Попахивает токсичностью очень сильно.
Разработка - это "мы", т.е. нет виноватых вообще.
Есть задача, которую требуется решить в нужный срок.
Все ошибаются и разработчики не исключение :)
Иначе следом можно сказать, что тестировщик пропустил баг в прод.
"Видишь баг?
Нет? Он просто еще не стрельнул!" :)
Предлагайте сценарии тестирования:
Если требования нечеткие, создайте примеры использования. Например: "Если пользователь заполнит форму с ошибками, как система должна реагировать?"
Не предлагайте, а готовьте.
Одна из важных задач тестировщика подготовить сценарии тестов.
В идеале их лучше иметь на руках до начала разработки, чтоб разработчик на их базе понял в каких местах потребуется валидация данных.
По сути большая часть багов - это не валидированные элементы бизнес-логики.
Но опять же, они должны быть согласованы с руководителем проекта.
Иначе будет история про "погрыз провод - меня ударило током".
Не надо тестировать то к чему не будет доступа у потенциального пользователя.
И не надо мешать тесты производительности, регрессию, ИБ и т.п. с тестами пользователей.
Везде свои особенности.
Покажите, что вы понимаете бизнес-задачи:
Откровенно вредный совет.
Вы либо их понимаете, либо нет.
Не надо показывать, что вы их понимаете.
Иначе наступит момент Х, когда ожидание разойдется с реальностью очень сильно.
Все думают, что вы понимаете, а вы "показываете, что понимаете".
С аналитиками, не знакомыми с ИТ, говорите простым языком. Например, вместо «API‑запросы» скажите «запросы между системами».
Опять же, в каждой компании своя кухня.
Но аналитик требований без знания ИТ?
Это очень серьезная проблема для компании.
С технически подкованными коллегами можно обсуждать детали, но не перегружайте их технической терминологией.
Опять же вредный совет.
Его стоит переформулировать так:
"Если не уверены в термине - не употребляйте его вообще, иначе запутаете специалиста".
Будьте терпеливы к изменениям:
Аналитики часто пересматривают требования. Вместо раздражения предложите: «Давайте вместе пробежимся и посмотрим, как это повлияет на текущие сценарии».
Смена ТЗ всегда будет вызывать раздражение, без вариантов.
К сожалению.
Причина до банального проста - потерянное время, как итог "горящие дедлайны".
Утешать никого не требуется - это реалии разработки в РФ :)
Объясняйте технические ограничения через выгоды для пользователя:
Если маркетолог хочет добавить анимацию, но она вызывает лаги, скажите: «Давайте сначала убедимся, что система не тормозит. Тогда анимация будет радовать пользователей, а не раздражать».
Если маркетолог хочет добавить анимацию, то его остановит только требуемый бюджет или сроки :)
Маркетологу нет дела тормозит или нет анимация, его задача сделать так, чтоб продукт вызывал нужные эмоции и как итог активнее продавался.
Сделать, чтоб не тормозило - задача разработчика (в данном случае фронт разработчика).
Задача тестировщика, на мой взгляд, не лезть к маркетологу и заниматься тестированием.
Для этого есть линейный руководитель, который, если нужно, донесет нужные мысли горизонтально или вертикально.
Используйте данные для аргументации:
Если маркетолог настаивает на дизайнерском решении, покажите, как оно может повлиять на производительность. Например: «Такой слайдер увеличивает время загрузки на 3 секунды, что снижает вовлеченность на 15%» — конечно же, если тестировщик обладает такими навыками расчета =).
Категорическое нет :)
Если он настаивает - руководитель проекта должен обратиться к тим лиду,
тим лид к разработчику,
а разработчик должен придумать метод оптимизации анимации.
Ваш вариант - это вместо решения бизнес-задачи за которую платит ваш заказчик - найти причину "почему мы не справились".
Сейчас вы не реализуете задумку, завтра вам не дадут новый проект.
Все очень просто :)
Используйте метрики, понятные бизнесу:
Вместо «найдено 50 багов» скажите: «Риск ошибок в платежной системе снижает доверие пользователей. Мы можем сэкономить 1 000 000 рублей, если исправить это до запуска».
Кесарю - кесарево, слесарю - слесарево.
Зачем тестировщику лезть в бюджетное планирование? :)
Вы уверены, что ваш комментарий не приведет к пересогласованию бюджета и остановке проекта?
Вы уверены, что ваша методика оценки совпадает с реальными рисками для бизнеса?
Вы уверены, что ...
Не бойтесь говорить о рисках:
Бизнес ценит честность. Скажите: «Если мы не протестируем этот модуль, вероятность сбоя на День Святого Валентина составляет 30%».
Бизнес ценит выполнение взятых на себя обязательств :)
Если вы сказали, что сдадите продукт 01.07, а сдали его 01.12 - это очень плохо.
Даже если вы сказали об этом честно 01.06.
На этом моменте перестал писать конкретные комментарии.
Далее напишу общим итоговым комментом.
В вашем описании тестировщик сочетает в себе все классы, получается некоторый универсал, который знает сразу все и на уровне специалиста.
При этом деление на конкретные штатные единицы существует не просто так.
Попытка влезть в чужие вопросы будет восприниматься строго негативно хотя бы потому, что у вас не хватит экспертизы.
При этом вы, по сути текста, как раз предлагаете этим заниматься.
Тестировщику платят за тестирование.
За тест кейсы, проверку обратной совместимости, выявление багов кроссплатформенности и прочие вещи, которыми просто некогда заниматься разработке и менеджерам.
Тестировщик - важное звено само по себе и не требуется перетягивать на себя чужой функционал, иначе наступит момент,
когда вы сломаете чужой ворк флоу
при этом не выполнив свой.
Надеюсь мое мнение будет вам полезно и для статей, и в работе :)
Да, ваше мнение полезно, и в большинстве я согласен с комментариями. Где то не так сформулировал, где то не договорил про формы коммуникации. Обязательно это учту в следующих постах и буду конкретнее писать, например, что не все бизнес-аналитики понимают что такое API и как оно работает =)
Есть моменты с которыми частично не согласен, но это опять же упирается в "везде своя кухня", и процессы везде разные, не всегда они каноничны.
В целом, спасибо за уделенное статье внимание, это мотивирует!
Добрый день, тоже подумал, что описывается не столько QA, сколько некий "универсал", сочетающий в себе несколько должностей (QA, аналитика, менеджера, немного от руководителя проекта). Но может примерно так выглядит работа на маленьком проекте/статапе? (Сам на таком не работал, но почему-то так мне представляется такая работа :-) )
Проект огромный, но у нас разные команды с разными подходами в управлении. Бывает такое, что просто необходимо срочным образом избежать всю бюрократическую рутину, и да, тут ты становишься на какую то долю и руководителем, и аналитиком - и идешь к бизнесу чтобы решать вопросики)
Если рассматривать отдельно QA специалиста, то да, в основном это просто линейный сотрудник, который должен следить только за качеством фичей, но если у него появится чуть больше ролей (даже на капельку) это в любом случае облегчит работу большой команды.
п.с. опять же, стоит учитывать первого комментатора и его фразу "везде своя кухня" =)
На стартапе да, схожий расклад.
Чем больше человек универсал - тем лучше.
Но опять же, сейчас даже в QA стек такой, что приходится какой-либо профиль выбирать по итогу.
А вот руководители, аналитики и тим лиды как раз должны быть "универсалами", чтоб понимать вектор потенциальных сложностей при разработке.
Иначе, как описал автор,
будет "аналитик не знает, что такое API".
Очень узкий и очень "свой" взгляд. Это, в общем, не плохо - если не возводить "свое" в абсолют и не считать непреложной истиной
"Не хватит компетенций, не лезь, не твоё дело...". Сколько раз я слышал это и от разработчиков, и от руководителей, и от архитекторов. Некоторых удавалось переубедить на ранних этапах sdlc, некоторые с разбегу въезжали в жир ногами - тут, главное, как завещал Канер - отчёт в трёх экземплярах - один разработке, один менеджменту, один себе 😁
Автору - согласен по всем основным пунктам. Именно это работа хорошего тестировщика/QA 🙂↕️
Рад что вызвал положительные эмоции, спасибо!
"Не хватит компетенций, не лезь, не твоё дело... " - никогда такого не слышал, но думаю меня бы это демотивировало.
В любом случае, лично мое понимание этого самого качества - это не просто закрыть таску с комментом что все ок. Я привык еще и пойти показать эту фичу аналитикам или бизнесу, обсудить с лидом, завести 3-4 задачки на доработку и улучшение и отправить их бизнесу, а там уж пусть сами думают, хватит ли на это ресурсов или нет) От меня не убудет, а вот вовлеченность в проект, и то что душа болит за продукт - сразу на лицо)
Добрый день, заинтересовало ваше мнение :)
Можете рассказать о случаях, когда экспертиза QA оказалась выше экспертизы разработчика?
Если возможно, то опишите кейс, в котором это произошло.
Так как наша кухня работает чуть иначе, интересно, как это работает у других - может что-то полезное смогу почерпнуть для себя :)
Эффективная коммуникация в ИТ: как тестировщики могут стать связующим звеном между отделами