Home

Оригинальная публикация

Тестировщик и разработчик — два разных мира: иногда про них говорят, что они как кошка с собакой. Вряд ли совместная работа принесёт большую пользу, если взаимопонимание находится на низком уровне: например, когда тестировщик дёргает разработчика по мелочам, нечётко описывает кейсы или сваливает кучу мелких багов в одну задачу, разработчика всё это только раздражает и демотивирует… 

Собрали 5 советов, которые помогут начинающему тестировщику найти взаимопонимание с разработчиками. 

В поисках багов помнить про пользу для продукта: что повышает качество, а что — вредит

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

Мы выбрали несколько ситуаций, которые на первый (и часто неопытный) взгляд выглядят логично и естественно, но почему-то не приводят к позитивному результату. 

Первая ситуация

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

✅ Cначала проверить позитивные кейсы и убедиться, что продукт работает верно при адекватных данных. Это важно: пользователь не должен наткнуться на проблему в позитивном сценарии. 

Однажды разработчик поправил баг для негативного, нераспространённого кейса, а основной кейс сломал. Я сомневалась в правильности работы: кейс то срабатывал, то нет. Но разработчик убеждал: «Смотри, у меня же работает, значит, норм». 

В итоге три тестировщика проверили негатив, но никто не проверил самый распространённый сценарий. О том, что проблема есть, стало ясно только на проде: о баге заявили клиенты. Пришлось в срочном порядке выкатывать багфикс.  

Вторая ситуация

❌ Придираться к любой детали. Например, тестировщик обнаруживает сдвиг кнопки на один пиксель и заводит задачу. А ведь это может быть не баг, а вынужденное решение. 

✅ Cначала разобраться, почему этот компонент такой. В случае с пикселем тестировщику следовало бы зайти в DevTools браузера, сравнить реализацию с макетом и увидеть, что это точно не косяк разработчика, — это дизайнер нарисовал нечётное количество пикселей. Получается, решать вопрос с лишним пикселем необходимо с дизайнером, а не c разработчиком.

Исследовать проблему, прежде чем создавать задачу и назначать её на разработчика

Определять, где фронтенд, а где бэкенд, и ставить задачу правильному подразделению. Бывает, что начинающий тестировщик заводит задачу для фронтендера: 500 не падает, ничего страшного не происходит — значит, «что-то» не обрабатывает фронт. Такое суждение бывает ошибочным. 

Прежде чем заводить задачу, лучше заранее проверить в DevTools браузера, какой ответ пришел от сервера: может оказаться, что данных для фронта не хватает, и обработка происходит насколько возможно. 

Проверять, воспроизводится ли баг «на живом». Это может оказаться более критично, чем если бы баг воспроизводился только в тестовом окружении. 

На носу релиз. Команда дорабатывает существующую функциональность, которая есть на проде. Тестировщик находит баг по своей фиче в тестовом окружении. Не проверяя его на проде, бежит к разработчику: «Всё пропало, тут баг, надо править». Разработчик бросает текущие задачи, начинает править баг, сроки съезжают…

Оказывается, баг-то живёт на проде давно, и он не критичный: воспроизводится сложно. В этом случае релиз двигать не нужно. Баг поправить в штатном режиме.

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

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

Думать об удобстве разработчика

Формулировать задачи подробно и чётко. Составили небольшой чек-лист, который поможет в этом:

• Шаги описаны без пропусков: разработчик может пройти по ним и в точности воспроизвести баг.

• Приложены все скрины и видосы.

• Указаны настройки окружения: иногда в задаче не указано окружение, где воспроизводится ошибка, и тогда «поймать» её сложнее.

• Понятно, в какой ветке (задаче) сломана функциональность. Это нужно, чтобы направить задачу разработчику, который точно в контексте.

• Есть данные для авторизации: приложение для пользователей с разными правами ведёт себя по-разному.

• Дан пример для воспроизведения: готовая публикация, уже заведенный компонент в приложении, ссылка на эту сущность. 

• Даны логи ошибок или описание состояния приложения. Знание системы логов очень выручает — Kibana или Grafana много что могут показать.

Объединять мелкие задачи в одну: группировать похожие замечания в одну задачу и не плодить множество мелких. Например, можно смело объединять замечания по дизайну одного компонента или текстам.

Писать замечания, относящиеся только к конкретной задаче. Случается, что новички отписывают всё, что находят, как замечания к проверяемой функциональности: не исследуют, воспроизводилось ли это ранее. Важно не кидать при проверке все найденные баги и мало связанные замечания в одну задачу: это может раздражать и демотивировать разработчика.

Развивать технические скилы

Рано или поздно у тестировщика появляются вопросы.  

• Как посмотреть логи и определить, в чём ошибка? Бывает сложно разобраться в записях Kibana, когда в одну секунду в лог складывается по 1000 событий. Плюс надо суметь прочитать JSON или XML: понять, что взять из конкретной записи и где найти результат события.

• Как изменить настройки аккаунта в базе самостоятельно, чтобы не просить об этом разработчика? Изучить SQL и структуру базы, с которой работаешь, научиться писать запросы для выборки или апдейта.

• Как протестировать API? Познакомиться с Postman, научиться писать тесты для API, разобраться в используемых методах и читать swagger-схему.

• Как протестировать интеграцию desktop и web-версий? Где прописать ключи для связи? Залезть в реестр операционной системы, найти нужный каталог и прописать необходимую информацию или обнулить значения, как будто приложения никогда и не было на компьютере.

• Как устроено взаимодействие сайта и CRM? Отследить запросы в Fiddler, проверить, все ли данные передаются и верный ли ответ приходит. Или наоборот: подменить значения параметров, чтобы завалить запрос и проверить реакцию системы.

• Как достучаться до данных, если у меня Windows, а данные только в Linux? Установить Cygwin64 Terminal и с помощью запросов легко постучаться в Unix-систему.

Работа с Postman, MySQL, системами сбора логов, знание Bash и принципов взаимодействия с Git помогает совершенствовать технические навыки и обогащает знания QA о продукте. Тестировщик и разработчик начинают работать, как слаженный механизм, и общаются «на одном языке».  

Разговаривать

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

Обговорить с разработчиком базовые принципы взаимодействия перед стартом работы:

• Собирать все баги в одной задаче или делать на каждый баг отдельную задачу? 

• Когда можно обратиться лично, а когда лучше написать в чат?

• Запросить локаторы элементов страницы для написания автотестов. 

Не замалчивать проблемы. Если задача блокирует и тормозит процесс, не стоит молчать и ждать — разработчика нужно поставить в известность как можно скорее.

5 принципов плодотворного взаимодействия тестера с разработчиками

1. Всегда держать в голове цель: зачем мы ищем баг и как это поможет всему продукту. Не искать баг ради бага. 

2. Сразу давать коллегам всю информацию, которая нужна для погружения в контекст и работы над багом. Не подразумевать, что «это они и так знают, а то и так понятно». Лучше разжевать, чем недосказать.

3. Научиться заводить задачи так, чтобы разработчику было комфортно с ними работать. Например, объединять мелкие задачи в один тикет, определить, что адресовать фронтенд, а что — бэкенд-разработчикам. Писать замечания, относящиеся только к актуальной задаче. Помнить, что разработчиков демотивирует, когда все баги сваливаются в одну объемную задачу.

4. Развивать смежные технические скилы. Это поможет общаться с разработчиком на одном языке, а также выполнять мелкие задачи самостоятельно, не привлекая коллег из dev.

5. Разговаривать и обсуждать все спорные моменты — например, во время ретроспективы. Не замалчивать проблемы: лучше сказать сразу, чем ждать, пока случится катастрофа.

Расскажите в комментариях, какие принципы совместной работы с разработчиками применяете вы? Что помогает вам эффективно работать на одну цель и создавать качественные продукты? Как не ставить друг другу палки в колёса? 

Обсудить в форуме