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

_{Фото: 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}

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