Как стать автором
Обновить

Как тестировщику критиковать и сохранить хорошие отношения с командой?

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров10K
Всего голосов 10: ↑7 и ↓3+9
Комментарии27

Комментарии 27

Если будешь заводить много багов — считай, критикуешь разработчика. Мало — могут сказать, что ты не эффективный QA.

Что-то не понятная мне проблема, хотя много лет руковожу тестированием. Баг есть баг, дело тестировщика его найти и описать. Если баг пойман, задокументирован и объективно существует - то честь тестировщику и хвала, молодец! Если их много - какие к тестировщику претензии, они же все реальные? Ни разу не сталкивался с такого рода претензиями к тестировщику.

Я вам объясню потому что работаю именно с таким тестировщиком.
"Баг" заводится на любое некоректное поведение...вообще любое, даже если это единичный глюк тестовой среды или просто некоректный вася пупкин...или просто кривые исторические данные. Любые объяснения, что это не баг просто игнорируются. Попытки донести что ценность бага прежде всего в повторяемости тоже игнорируются. Попытки выяснить как повторить "баг" приводят к пояснению "ну я работала, а вот оно мне выскочило". При этом от тебя требуют уделить время каждому "багу", на их обсуджение тратится время на созвонах и митингах, в том числе с начальством. По сути много проблем из ничего. При этом тестировщик на хорошем счету, а команда разработчиков уже ругается про себя матом и иногда вслух.

Если в вашей компании принимаются шаги воспроизведения багов как это:

"ну я работала, а вот оно мне выскочило"

То лучше искать новое место работы или нового тестировщика.

"матом и иногда вслух ." видимо недостаточно вслух.

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

Попытки выяснить как повторить "баг" приводят к пояснению "ну я работала, а вот оно мне выскочило"

А вот это явный минус тестировщику, если это происходит массово. Описание сценария воспроизведения - неотъемлемая часть баг-репорта. Конечно, не всегда удаётся поймать сценарий воспроизведения, бывают "мигающие" баги. Такие баги ловить труднее всего и они отнимают у всех много времени, ничего не поделаешь, это жизнь. Тут нет вины ни тестировщика, ни разработки, всем надо конструктивно искать причину вместе. Но, к счастью, их не так много.

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

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

На планировании разработчики забывают взять в работу баги — не
критикуй. Создай бота, который раз в неделю будет присылать в slack топ
самых критичных багов.

Опять не понятно. На разборе багов команда определяет приоритеты и сроки. На следующем разборе начинаем с наиболее приоритетных. Что значит забывают? На разборе у всех перед глазами приоритеты и сроки, и все своими глазами видят кто что просрочил и забыл. Это объективно и вашей вины в этом нет, но все всё видят и тот кто забыл сам всё понял.

Не нужно эти эмоции передавать разработчику в баг-репорте.
Пиши по делу: [crit][prod] Не работают переводы на счета нерезидентов.
Затронуло 60% пользователей.

Вот, верно! Эмоции в сторону, пиши по делу, тогда никому не обидно. Лучше писать сухим языком. Бывает, в командах принят весёленький сленг и попсовые обороты. Но в баг-репортах его избегайте. И не только по тому, что кого-то можно обидеть, а ещё и по тому, что могут понять не так. Сухо и по деловому.

Ого, это я что-ли уже авторитетным стал? Приятно :)

Сильно конечно еще от команды и процесса зависит. Бывают проекты где тестировщики и разработчики общаются ислключительно через багтрекер. Тогда сухо и по делу.

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

Не забывайте, например, извиняться если в чем-то оказались хоть малость не правы.

Если приходится давать оценочное суждение, указывайте на что опираетесь в своей оценке.

Не ленитесь выяснять и давать дополнительную полезную информацию. Не думайте, что разработчик "сам разберется там". Если есть возможность выделить режим возникновения сбоя, то не нужно перекладывать эту работу на разработчика. Или хотя бы указать те режимы в которых ошибка не проявляется. Как я это называю "дайте разработчику шанс".

В конце концов не бойтесь спросить самих разработчиков как им удобнее, чтобы вы делали свою работу.

Не знаешь как описать ошибку - просто "пиши что видишь", это будет лучше любого придуманного, сформулированного описания.

Не забывайте проявлять доброту и заботу, и тогда вас будут ценить. А то ведь у айтишников довольно бинарный мир. Дуализм например очень часто проявляется в высказываниях. Разработчики - тестировщики. Баг - фича. Тест красный - тест зеленый.
Мне кажется нужно разбавлять это черно-белое полотно человеческими качествами.

Не совсем понятно зачем тестировщику критиковать, если его дело - найти баг.

Ладно там ещё на ревью кода встречается критика (и то редко), но какое отношение к ней имеет поиск багов - не понимаю.

Верное замечание. Задача тестировщика добывать и доносить до заинтересованых лиц релевантную информацию о качестве продукта, вовремя и точно. Тестирование - это способ добычи такой информации. Наш "товар" - информация. Мы не искусствоведы, мы не оцениваем. Мы детективы. Дедукция, логика, факты, доказательства - это наше все.

Допустим высота навигационной полосы слишком маленькая а спецификации нет. Нельзя просто заявиться и сказать - слишком маленькая высота, неудобно. Тестировщик не единственный пользователь. Он представитель всех пользователей. Значит проведи исследование, собери информацию как это выглядит на разных устройствах, чем обуславливается неудобство пользования (например, при беглом переключении мы иногда можем задеть другой навигационный блок) Никакой критики, только факты, выявление обстоятельств.
И такой случай, в отсутствии спецификации, лучше перед написанием багрепорта обсудить с командой.

Так же это отношение отражается в письменной речи. Если мы пишем репорт то он будет максимально по делу. Никаких оценочных или сравнительных прилагательных. Т.е. мы не пишем "размер главной навигационной панели слишком маленький", Мы не пишем "кнопки главной навигации перекрывают рубрикатор при разрешении .. на .. пикселей". Тестировщик молодец, что залез в DevTools и выяснил какие-то технические детали, но технический анализ лучше предоставить специалистам. Можно добавить заметку в конце багрепорта о найденых технических аспектах. А в заголовке багрепорта достаточно написать что-то вроде "переключаясь между рубриками можно задеть главную навигацию". Надо уметь быть простым пользователем. (Не имитировать тупого юзера, а быть простым пользователем, это разные вещи :)
Т.е. мы собрали факты, в защиту пользователя, а большое оно или маленькое, что на что заплывает - не наше дело. Факт в том что есть дефект, есть необходимость в проведении улучшения, вот доказательства этой необходимости, собраны экспериментальным путем с точки зрения пользователя и задокументированы в багрепорте.

Извините, но слишком уж много воды и толком ничего по делу моего комментария.

Т.е. мы собрали факты, в защиту пользователя

Зачем его защищать? Вы слишком уходите в какие-то абстракции и примеры.
Задача тестировщика - дать понятие о качестве продукта и о том, какие в нём проблемы.
Если тестировщик качественно оформляет отчёты (баг-репорты), основываясь на общепринятых стандартах, и прочее, то ни в какой нормальной компании никто и слова ему не скажет.

Так ведь нет как таковых стандартов. Есть скорее широко признаные практики. От проекта к проекту все может быть весьма индивидуально. Поэтому я говорю о принципах, приводя пример. Категоричность - враг гибкости. А гибкость на мой взгляд одно из важнейших качеств для тестировщика. Тогда он сможет адаптироваться к любой среде, а не талдычить "есть стандарты, я их придерживаюсь. Вот шаблон, я по нему и пиишу". Можно и так, но тогда не будет развития. А я делаю упор на принципы, из которых сами собой будут произрастать хорошие тестировщики, и как возможная часть их работы - хорошие багрепорты.

Тестировщик в конце концов не машина по документации багов в джире. Хотя наверное многие до сих пор так считают. Джира - всего лишь один из инструментов, багрепорт - всего лишь один из методов передачи информации о дефектах.

Так ведь нет как таковых стандартов. Есть скорее широко признан(н)ые практики.

Есть негласные правила (общепринятые), например, при нажатии кнопки на любом экране, она должна что-то делать, валидация полей ввода (инпутов) и вывод понятных ошибок для юзера, если он что-то не так делает, защита от уязвимостей (XSS, CSRF, SQL Injection etc), удобный и понятный UX/UI и тд, именно над этим должен работать тестировщик (с UI/UX всё же дизайнер работает больше, но никто не запрещает тестировщику репортить непонятный дизайн).


Как бы вы не пытались что-то доказать, заголовок статьи и содержимое немного странное (возможно, автор не так выразился или уж у него слишком странное видение "тестировщиков").

Примеры:

Тестировщик — это критик

С чего вдруг? Непонятно.

Когда ты работаешь тестировщиком — тебе приходится критиковать: тут баг, а тут авторизация не работает, а тут ручка вернула 500-ку, а тут документация устарела, а тут логов в кибане нет, а тут тестовое окружение недоступно.

Это называется не критиковать, а искать ошибки в ПО.

Касательно пунктов - некоторые из них достаточно неплохие и могут помочь тестировщикам в становлении лучше. Например, 'Разберись в азах хороших интерфейсов', 'Научись выражать своё мнение'. Остальное мне показалось достаточно посредственным.

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

Научиться безучастно наблюдать не так просто как может показаться со стороны. Мне как-то один разработчик посоветовал, и я эту фразу запомнил на всю жизнь: "Пиши что видишь, а не то что ты думаешь, что ты видишь"

Тестировщик не единственный пользователь. Он представитель всех пользователей. Значит проведи исследование, собери информацию как это выглядит на разных устройствах, чем обуславливается неудобство пользования

А вы точно знаете чем отличается тестировщик от Product Owner?

При отсутствии спеки тестировщик конечно может руководствоваться здравым смыслом, статьями в интернете, умными книжками, но если в проекте работает процессы, то он просто заведёт баг на спеку/UI и предоставит им возможность заниматься своим делом, в то время как сам будет заниматься своим.

Его дело не "найти баг", а проверить ПО на соответствие требованиям заказчика. Баги есть всегда. И опытный QA их может найти очень и очень много. Но джуна от мидла и сеньора отличает понимание того что и нахрена ты вообще делаешь. Задача не найти побольше багов чтобы задолбать разрабов, нам не доплачивают за это, а проверить что таска в целом проделана в соответствии с ТЗ, на её функционал ничего не влияет и юзабилити остаётся на качественном уровне.

Как только начнёшь понимать, что баги вёрстки куда более приоритетны с точки зрения заказчика и юзеров, чем какой-то вычурный сценарий нажатия 20 кнопок в нужном порядке, который положит сайт - вот тогда ты станешь специалистом QA. Просто репортить баги может и обычный юзер без технических знаний.

 вычурный сценарий нажатия 20 кнопок в нужном порядке, который положит сайт

Вот это очень ценный баг. По тому, что если вы выпустите с ним в прод, периодически кто-то будет нажимать эти 20 кнопок в этом порядке и у вас будет ложиться сайт. И вы всей командой с ума сойдёте пока найдёте причину. А все ваши пользователи будут тем временем минусовать вашу компанию на всех доступных ресурсах. 

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

Я к тому что бОльшая часть времени должна уходить на критические тесты. Можно потратить день и найти этот сценарий, но при этом не успеть протестить логин форму и пропустить критикал. В отдельных случаях выгоднее реагировать постфактум, по репортам от юзеров. В других же наоборот уделить большее внимание тестированию. Грамотная приоретизация и отличает джуна от мидла.

Никто так делать не будет

Это может сыграть с вами злую шутку, если сценарий не переходит за рамки "скажи 1234 про себя, перережь провод, воткни спустя 4 часа, 1231 раз обнови страницу, нажми кнопку Главная мизинцем левой ноги"

upd: мой пример слишком гиперболизирован (преувеличен и туповат), но суть понятна.

Понятно, что поиск и исправление минорных ошибок: опечатки, поехавшая кнопка на экране в 300px и тд, которые не нарушают бизнес-логику приложения / сайта надо в последнюю очередь, но их не надо полностью игнорировать.

Я не знаю вашей ситуации, но и вы не знаете что будет делать пользователь. Жизнь показывает, что если пользователь может что-то сделать, то рано или поздно он это сделает. Что полностью соответствует закону Мерфи: "Если что-нибудь может пойти не так, оно пойдёт не так".

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

 а проверить что таска в целом проделана в соответствии с ТЗ, на её функционал ничего не влияет и юзабилити остаётся на качественном уровне.

А потом окажется, что функционал по ТЗ отрабатывал только потому, что уровнем выше был другой баг, которым вы решили не задалбывать разработчика. И спустя пару релизов этот самый баг вдруг починили.

Звучит как начало увлекательного сериала. "Костыли: начало".

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

У тестировщика две основные задачи: поиск несоответствия продукта требованиям и описание результатов поиска.

У меня, как у разработчика, нет никаких психологических травм, если в моей работе есть изъяны - errare humanum est. Но вызывает легкую форму непонимания бессвязный поток сознания, которые вываливают некоторые представители цеха QA. Слава Богу, в последнее время нашел команду, где ребята и девчата специалисты - приятно работать.

Вражда между разработкой и тестированием (если она есть где-нибудь) - признак отсутствия профессионатизма с обоих сторон.

На мой взгляд, поиск несоответствия продукта требованиям это задача аналитика. Здесь под требованиями я имею ввиду исходные пожелания заказчика, в какой-то степени обработанные. Задача тестировщика - поиск несоответствия продукта техническому заданию (верификация, здесь связка тестировщик-разработчик) и здравому смыслу (валидация, здесь связка тестировщик-аналитик(проектировщик/архитектор и т.д.)).

Вражда между разработкой и тестированием это признак отсутствия профессионализма хотя бы с одной стороны (возможно, что и с двух, но это необязательно). Умение работать с неадекватными коллегами это не необходимое условие профессионализма, это софт-скиллы на уровне, превышающем планку, отделяющую тестировщика-профессионала от тестировщика-непрофессионала.

Джуны — это волонтёрский проект

Про PPS — спасибо, что подсказал :)

Позволю себе не согласиться с основным посылом: тестировщик - не критик, а контроль качества.

Критик высказывает своё мнение, суждение. Тестировщик работает с фактами.

И когда контроль начинает скатываться к критике, тогда и возникают проблемы "как не обидеть".

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации