Главная » Хабрахабр » 7 советов, как не взбесить коллегу-тестировщика в его праздник

7 советов, как не взбесить коллегу-тестировщика в его праздник

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

Фото: David Goehring CC BY

1. «Перепроверь-ка еще разок, там точно нет бага»

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

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

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

2. «До релиза неделя. Надеюсь, на ближайшие два дня ты не планировал других дел»

Тогда им приходится работать в аврале. Иногда код приходит к тестировщикам за несколько дней до релиза. Якобы они думают, что поиск багов — это легко и быстро, поэтому откладывают отладку на последний момент. Некоторые QA-специалисты считают, что коллеги просто недооценивают их труд.

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

С точки зрения QA различают два основных подхода: каскадный и Agile. Как быть: Есть несколько моделей разработки. Во втором случае они тестируют код параллельно с его написанием. В первом случае тестировщики получают фрагменты кода поэтапно.

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

Фото: Tim Regan CC BY

3. «Я быстренько подправил код. Посмотри, пожалуйста»

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

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

Но этого мало. Как быть: Очевидно, не стоит торопиться. Если это банальная лень, помочь себе можете только вы. Нужно разобраться, почему вы не уделяете должное внимание отчету. Например, вы считаете, что QA-инженеры заваливают вас отчетами о малозначимых багах. Бывают и другие причины. Скорее всего, ответ будет положительный. Тогда нужно прояснить этот вопрос на уровне руководства — должны ли тестеры отвлекать вас «по мелочам». Важно принять этот подход и относиться к баг-репортам с должным вниманием. Некоторые продакт-менеджеры даже просят разработчиков специально добавлять в код мелкие баги, чтобы тестировщики были всегда настороже.

4. «Кажется, я уже разобрался с этим багом. Но точно не помню»

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

В итоге проблема всплывает, когда уже слишком поздно. Что может пойти не так: Разработчики устраняют какой-то баг, вносят, как им кажется, «незначительные» изменения в код, забывают уведомить об этом тестировщиков и отсылают код на релиз. И «крайним» зачастую оказывается тестировщик.

Беспорядок вредит разработке, поэтому придется полностью перестроить процесс коммуникаций в команде. Как быть: Проблему хаоса нужно решать системно. Что касается путаницы с багами, есть хорошие практические советы: а) пусть баги репортят все; б) далее их важно приоретизировать; в) любой закрытый баг подразумевает, что будет написан функциональный тест; г) статус «решено» присваивает не разработчик, а тестировщик. Здесь стоит воспользоваться базовыми советами по налаживанию коммуникации между разработчиками и QA-инженерами: определиться с терминологией; понятно формулировать требования; ввести иерархию приоритетности для различных багов. Этот подход гарантирует, что проблема действительно будет решена.

Фото: Tim Regan CC BY

5. «Почему это я должен тестировать? Я же не тестировщик!»

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

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

Это помогает не только разгрузить тестировщиков, но и научиться смотреть на продукт с точки зрения критика и пользователя. Как быть: Многие разработчики выступают за самостоятельные тесты перед отправкой в QA-отдел. Для тех, кто не хочет себя утруждать проверками, есть автоматические инструменты. Есть мнение, что это полезно для профессионалов и лучшим образом сказывается на конечном результате. В любом случае — даже если в команде есть QA-инженеры, жесткое разделение на разработчиков и QA — не самый оптимальный подход. Они помогают найти самые очевидные баги.

6. «Игорь, сегодня работаешь в паре с Олегом. Тебе понравится»

Некоторые из них любят экспериментировать. Продакт-менеджеры не ограничиваются каскадным подходом и Agile. Например, устраивать сеансы парного программирования и тестирования.

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

Agile- и DevOps-практики могут казаться привлекательными, но без должной подготовки не дадут результата. Как быть: Главный совет — не рубить с плеча.

7. «Я возьму твой девайс для тестов, ты же не против?»

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

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

Как быть: Ставьте себе напоминания, клейте стикеры, делайте что угодно, но, пожалуйста, возвращайте вещи тестировщиков на место и в срок.

Фото: Dave Allen CC BY

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Не позволяйте 3D-принтеру лениться

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

[Перевод] Знакомимся с альфа-версией снапшотов томов в Kubernetes

перев.: оригинальная статья была недавно опубликована в блоге Kubernetes и написана сотрудниками компаний Google и Huawei (Jing Xu, Xing Yang, Saad Ali), активную деятельность которых вы непременно видели в GitHub'е проекта, если когда-либо интересовались фичами и проблемами K8s, связанными с ...