Привет, Хабр! Меня зовут Герман, я давно работаю в тестировании (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. Я создал волонтёрский проект Джуны — где начинающие тестировщики бесплатно протестируют ваш сайт, бота или ноу-код решение. Если есть что протестировать — пишите :)
Комментарии (27)
Dynasaur
00.00.0000 00:00+4Вообще, прочитав вашу статью, возникло ощущение, что у вас недоработан процесс. Тестировщик ловит баги, документирует и передаёт команде. Он не должен критиковать, извиняться, опасаться ранить нежную душу разработчика. И оценивать работу разработки он не должен. Он просто должен делать свою работу строго по процедуре. Все понимают, что это его работа.
Да, все мы люди, можем постебаться над чьей-то ошибкой и обидеть человека. Этого надо избегать, но этого нет в процедуре, это именно человеческие отношения и эмоции. Если придерживаться процедуры, то никого не обидите.
На планировании разработчики забывают взять в работу баги — не
критикуй. Создай бота, который раз в неделю будет присылать в slack топ
самых критичных багов.Опять не понятно. На разборе багов команда определяет приоритеты и сроки. На следующем разборе начинаем с наиболее приоритетных. Что значит забывают? На разборе у всех перед глазами приоритеты и сроки, и все своими глазами видят кто что просрочил и забыл. Это объективно и вашей вины в этом нет, но все всё видят и тот кто забыл сам всё понял.
Не нужно эти эмоции передавать разработчику в баг-репорте.
Пиши по делу: [crit][prod] Не работают переводы на счета нерезидентов.
Затронуло 60% пользователей.Вот, верно! Эмоции в сторону, пиши по делу, тогда никому не обидно. Лучше писать сухим языком. Бывает, в командах принят весёленький сленг и попсовые обороты. Но в баг-репортах его избегайте. И не только по тому, что кого-то можно обидеть, а ещё и по тому, что могут понять не так. Сухо и по деловому.
lxsmkv
00.00.0000 00:00+3Ого, это я что-ли уже авторитетным стал? Приятно :)
Сильно конечно еще от команды и процесса зависит. Бывают проекты где тестировщики и разработчики общаются ислключительно через багтрекер. Тогда сухо и по делу.
Если это сопровождающее разработку тестирование в гибком процессе, с живым общением, то нужно налаживать связи. Ни одна ошибка в программе не дает права быть бестактным по отношению к людям и их работе. Всегда в первую очередь думаем о человеке или людях, а потом о баге. Баги ведь они приходят и уходят, а с людьми вам работать всегда.
Не забывайте, например, извиняться если в чем-то оказались хоть малость не правы.
Если приходится давать оценочное суждение, указывайте на что опираетесь в своей оценке.
Не ленитесь выяснять и давать дополнительную полезную информацию. Не думайте, что разработчик "сам разберется там". Если есть возможность выделить режим возникновения сбоя, то не нужно перекладывать эту работу на разработчика. Или хотя бы указать те режимы в которых ошибка не проявляется. Как я это называю "дайте разработчику шанс".
В конце концов не бойтесь спросить самих разработчиков как им удобнее, чтобы вы делали свою работу.
Не знаешь как описать ошибку - просто "пиши что видишь", это будет лучше любого придуманного, сформулированного описания.
Не забывайте проявлять доброту и заботу, и тогда вас будут ценить. А то ведь у айтишников довольно бинарный мир. Дуализм например очень часто проявляется в высказываниях. Разработчики - тестировщики. Баг - фича. Тест красный - тест зеленый.
Мне кажется нужно разбавлять это черно-белое полотно человеческими качествами.
scoffs
00.00.0000 00:00+3Не совсем понятно зачем тестировщику критиковать, если его дело - найти баг.
Ладно там ещё на ревью кода встречается критика (и то редко), но какое отношение к ней имеет поиск багов - не понимаю.
lxsmkv
00.00.0000 00:00Верное замечание. Задача тестировщика добывать и доносить до заинтересованых лиц релевантную информацию о качестве продукта, вовремя и точно. Тестирование - это способ добычи такой информации. Наш "товар" - информация. Мы не искусствоведы, мы не оцениваем. Мы детективы. Дедукция, логика, факты, доказательства - это наше все.
Допустим высота навигационной полосы слишком маленькая а спецификации нет. Нельзя просто заявиться и сказать - слишком маленькая высота, неудобно. Тестировщик не единственный пользователь. Он представитель всех пользователей. Значит проведи исследование, собери информацию как это выглядит на разных устройствах, чем обуславливается неудобство пользования (например, при беглом переключении мы иногда можем задеть другой навигационный блок) Никакой критики, только факты, выявление обстоятельств.
И такой случай, в отсутствии спецификации, лучше перед написанием багрепорта обсудить с командой.
Так же это отношение отражается в письменной речи. Если мы пишем репорт то он будет максимально по делу. Никаких оценочных или сравнительных прилагательных. Т.е. мы не пишем "размер главной навигационной панели слишком маленький", Мы не пишем "кнопки главной навигации перекрывают рубрикатор при разрешении .. на .. пикселей". Тестировщик молодец, что залез в DevTools и выяснил какие-то технические детали, но технический анализ лучше предоставить специалистам. Можно добавить заметку в конце багрепорта о найденых технических аспектах. А в заголовке багрепорта достаточно написать что-то вроде "переключаясь между рубриками можно задеть главную навигацию". Надо уметь быть простым пользователем. (Не имитировать тупого юзера, а быть простым пользователем, это разные вещи :)
Т.е. мы собрали факты, в защиту пользователя, а большое оно или маленькое, что на что заплывает - не наше дело. Факт в том что есть дефект, есть необходимость в проведении улучшения, вот доказательства этой необходимости, собраны экспериментальным путем с точки зрения пользователя и задокументированы в багрепорте.scoffs
00.00.0000 00:00+3Извините, но слишком уж много воды и толком ничего по делу моего комментария.
Т.е. мы собрали факты, в защиту пользователя
Зачем его защищать? Вы слишком уходите в какие-то абстракции и примеры.
Задача тестировщика - дать понятие о качестве продукта и о том, какие в нём проблемы.
Если тестировщик качественно оформляет отчёты (баг-репорты), основываясь на общепринятых стандартах, и прочее, то ни в какой нормальной компании никто и слова ему не скажет.lxsmkv
00.00.0000 00:00Так ведь нет как таковых стандартов. Есть скорее широко признаные практики. От проекта к проекту все может быть весьма индивидуально. Поэтому я говорю о принципах, приводя пример. Категоричность - враг гибкости. А гибкость на мой взгляд одно из важнейших качеств для тестировщика. Тогда он сможет адаптироваться к любой среде, а не талдычить "есть стандарты, я их придерживаюсь. Вот шаблон, я по нему и пиишу". Можно и так, но тогда не будет развития. А я делаю упор на принципы, из которых сами собой будут произрастать хорошие тестировщики, и как возможная часть их работы - хорошие багрепорты.
Тестировщик в конце концов не машина по документации багов в джире. Хотя наверное многие до сих пор так считают. Джира - всего лишь один из инструментов, багрепорт - всего лишь один из методов передачи информации о дефектах.
scoffs
00.00.0000 00:00+1Так ведь нет как таковых стандартов. Есть скорее широко признан(н)ые практики.
Есть негласные правила (общепринятые), например, при нажатии кнопки на любом экране, она должна что-то делать, валидация полей ввода (инпутов) и вывод понятных ошибок для юзера, если он что-то не так делает, защита от уязвимостей (XSS, CSRF, SQL Injection etc), удобный и понятный UX/UI и тд, именно над этим должен работать тестировщик (с UI/UX всё же дизайнер работает больше, но никто не запрещает тестировщику репортить непонятный дизайн).
Как бы вы не пытались что-то доказать, заголовок статьи и содержимое немного странное (возможно, автор не так выразился или уж у него слишком странное видение "тестировщиков").Примеры:
Тестировщик — это критик
С чего вдруг? Непонятно.
Когда ты работаешь тестировщиком — тебе приходится критиковать: тут баг, а тут авторизация не работает, а тут ручка вернула 500-ку, а тут документация устарела, а тут логов в кибане нет, а тут тестовое окружение недоступно.
Это называется не критиковать, а искать ошибки в ПО.
Касательно пунктов - некоторые из них достаточно неплохие и могут помочь тестировщикам в становлении лучше. Например, 'Разберись в азах хороших интерфейсов', 'Научись выражать своё мнение'. Остальное мне показалось достаточно посредственным.
lxsmkv
00.00.0000 00:00+2Да, глагол точно не из повседневного инструментария тестировщика :) Критика - это оценочные суждения, а тестировщик не дает никаких оценок. Не должен. Как градусник, не дает оценки температуры, а просто ее показывает. Оценивать будет наблюдатель по обстоятельствам. Другое дело - применять критическое мышление. Эту способность нельзя переоценить.
Научиться безучастно наблюдать не так просто как может показаться со стороны. Мне как-то один разработчик посоветовал, и я эту фразу запомнил на всю жизнь: "Пиши что видишь, а не то что ты думаешь, что ты видишь"
FireHawk
00.00.0000 00:00Тестировщик не единственный пользователь. Он представитель всех пользователей. Значит проведи исследование, собери информацию как это выглядит на разных устройствах, чем обуславливается неудобство пользования
А вы точно знаете чем отличается тестировщик от Product Owner?
При отсутствии спеки тестировщик конечно может руководствоваться здравым смыслом, статьями в интернете, умными книжками, но если в проекте работает процессы, то он просто заведёт баг на спеку/UI и предоставит им возможность заниматься своим делом, в то время как сам будет заниматься своим.
R3B3LL10N
00.00.0000 00:00Его дело не "найти баг", а проверить ПО на соответствие требованиям заказчика. Баги есть всегда. И опытный QA их может найти очень и очень много. Но джуна от мидла и сеньора отличает понимание того что и нахрена ты вообще делаешь. Задача не найти побольше багов чтобы задолбать разрабов, нам не доплачивают за это, а проверить что таска в целом проделана в соответствии с ТЗ, на её функционал ничего не влияет и юзабилити остаётся на качественном уровне.
Как только начнёшь понимать, что баги вёрстки куда более приоритетны с точки зрения заказчика и юзеров, чем какой-то вычурный сценарий нажатия 20 кнопок в нужном порядке, который положит сайт - вот тогда ты станешь специалистом QA. Просто репортить баги может и обычный юзер без технических знаний.
Dynasaur
00.00.0000 00:00вычурный сценарий нажатия 20 кнопок в нужном порядке, который положит сайт
Вот это очень ценный баг. По тому, что если вы выпустите с ним в прод, периодически кто-то будет нажимать эти 20 кнопок в этом порядке и у вас будет ложиться сайт. И вы всей командой с ума сойдёте пока найдёте причину. А все ваши пользователи будут тем временем минусовать вашу компанию на всех доступных ресурсах.
R3B3LL10N
00.00.0000 00:00Нет. Во первых, это слишком сложный сценарий для рядового юзера. Никто так делать не будет. Во вторых, вопрос в том на чьей стороне ложится сайт. На клиентской - ничего страшного. На серверной - это какая-то очень страшная уязвимость безопасности и нужно искать причину, а не фиксить последствия. В третьих, пример был взят чисто из головы, без глубокой проработки. Естественно тут в зависимости от обстоятельств это может быть и что-то критичное, и пустяковое.
Я к тому что бОльшая часть времени должна уходить на критические тесты. Можно потратить день и найти этот сценарий, но при этом не успеть протестить логин форму и пропустить критикал. В отдельных случаях выгоднее реагировать постфактум, по репортам от юзеров. В других же наоборот уделить большее внимание тестированию. Грамотная приоретизация и отличает джуна от мидла.
scoffs
00.00.0000 00:00Никто так делать не будет
Это может сыграть с вами злую шутку, если сценарий не переходит за рамки "скажи 1234 про себя, перережь провод, воткни спустя 4 часа, 1231 раз обнови страницу, нажми кнопку Главная мизинцем левой ноги"
upd: мой пример слишком гиперболизирован (преувеличен и туповат), но суть понятна.
Понятно, что поиск и исправление минорных ошибок: опечатки, поехавшая кнопка на экране в 300px и тд, которые не нарушают бизнес-логику приложения / сайта надо в последнюю очередь, но их не надо полностью игнорировать.
Dynasaur
00.00.0000 00:00+1Я не знаю вашей ситуации, но и вы не знаете что будет делать пользователь. Жизнь показывает, что если пользователь может что-то сделать, то рано или поздно он это сделает. Что полностью соответствует закону Мерфи: "Если что-нибудь может пойти не так, оно пойдёт не так".
Dynasaur
00.00.0000 00:00+1Ну а вообще да, тестирование это больше искусство, чем наука, правильно понять что именно тестировать сложно, есть разные методики составления программ тестирования, но ни одна из них не гарантирует правильности в каждом конкретном случае. И тут очень важно тестировщику понимать что делает разработка. Если коммуникация не работает, то разработчики пилят новые фичи, рефакторят, а тестировщики об этом не знают, не понимают, соответственно не тестируют.
khulster
00.00.0000 00:00а проверить что таска в целом проделана в соответствии с ТЗ, на её функционал ничего не влияет и юзабилити остаётся на качественном уровне.
А потом окажется, что функционал по ТЗ отрабатывал только потому, что уровнем выше был другой баг, которым вы решили не задалбывать разработчика. И спустя пару релизов этот самый баг вдруг починили.
Звучит как начало увлекательного сериала. "Костыли: начало".
vindy123
00.00.0000 00:00Бедные полицейские, инспектора общепита и пожарной охраны, этим тоже сложно хорошими для всех быть, наверное. Если ранимого тестировщика это утешит - то можно знать, что люди из техподдержки наоборот будут на руках носить его и пиво в баре ставить за максимальное количество не дошедшего до продакшена кала) Я - такой человек из поддержки, и QA - мои лучшие друзья.
Nialpe
00.00.0000 00:00+3У тестировщика две основные задачи: поиск несоответствия продукта требованиям и описание результатов поиска.
У меня, как у разработчика, нет никаких психологических травм, если в моей работе есть изъяны - errare humanum est. Но вызывает легкую форму непонимания бессвязный поток сознания, которые вываливают некоторые представители цеха QA. Слава Богу, в последнее время нашел команду, где ребята и девчата специалисты - приятно работать.
Вражда между разработкой и тестированием (если она есть где-нибудь) - признак отсутствия профессионатизма с обоих сторон.
Vpan
00.00.0000 00:00На мой взгляд, поиск несоответствия продукта требованиям это задача аналитика. Здесь под требованиями я имею ввиду исходные пожелания заказчика, в какой-то степени обработанные. Задача тестировщика - поиск несоответствия продукта техническому заданию (верификация, здесь связка тестировщик-разработчик) и здравому смыслу (валидация, здесь связка тестировщик-аналитик(проектировщик/архитектор и т.д.)).
Вражда между разработкой и тестированием это признак отсутствия профессионализма хотя бы с одной стороны (возможно, что и с двух, но это необязательно). Умение работать с неадекватными коллегами это не необходимое условие профессионализма, это софт-скиллы на уровне, превышающем планку, отделяющую тестировщика-профессионала от тестировщика-непрофессионала.
Ignavus
00.00.0000 00:00Позволю себе не согласиться с основным посылом: тестировщик - не критик, а контроль качества.
Критик высказывает своё мнение, суждение. Тестировщик работает с фактами.
И когда контроль начинает скатываться к критике, тогда и возникают проблемы "как не обидеть".
Dynasaur
Что-то не понятная мне проблема, хотя много лет руковожу тестированием. Баг есть баг, дело тестировщика его найти и описать. Если баг пойман, задокументирован и объективно существует - то честь тестировщику и хвала, молодец! Если их много - какие к тестировщику претензии, они же все реальные? Ни разу не сталкивался с такого рода претензиями к тестировщику.
auresio
Я вам объясню потому что работаю именно с таким тестировщиком.
"Баг" заводится на любое некоректное поведение...вообще любое, даже если это единичный глюк тестовой среды или просто некоректный вася пупкин...или просто кривые исторические данные. Любые объяснения, что это не баг просто игнорируются. Попытки донести что ценность бага прежде всего в повторяемости тоже игнорируются. Попытки выяснить как повторить "баг" приводят к пояснению "ну я работала, а вот оно мне выскочило". При этом от тебя требуют уделить время каждому "багу", на их обсуджение тратится время на созвонах и митингах, в том числе с начальством. По сути много проблем из ничего. При этом тестировщик на хорошем счету, а команда разработчиков уже ругается про себя матом и иногда вслух.
scoffs
Если в вашей компании принимаются шаги воспроизведения багов как это:
То лучше искать новое место работы или нового тестировщика.
Arhammon
"матом и иногда вслух ." видимо недостаточно вслух.
Dynasaur
Это проблемы организации процесса. Да, тестировщик регистрирует всё, что случилось нештатного (ну, кроме предельно очевидной ерунды), так как в момент возникновения проблемы он не всегда может сразу понять в чём проблема. Да и вообще нет ни одного человека в мире, кто может сразу понять причину, значимость и повторяемость любой проблемы. Потом баги разбираются и сортируются - в том числе на ошибки данных, ошибки пользователя, ошибки тестовой среды. Да, это отнимает время, но как иначе? Пока вы не разберёте, вы не знаете насколько это серьёзная проблема. После того как стало понятно, что ошибка в тестовых данных, тикет может быть либо закрыт, либо получает соответствующий приоритет.
А вот это явный минус тестировщику, если это происходит массово. Описание сценария воспроизведения - неотъемлемая часть баг-репорта. Конечно, не всегда удаётся поймать сценарий воспроизведения, бывают "мигающие" баги. Такие баги ловить труднее всего и они отнимают у всех много времени, ничего не поделаешь, это жизнь. Тут нет вины ни тестировщика, ни разработки, всем надо конструктивно искать причину вместе. Но, к счастью, их не так много.