company_banner

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


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

    Mail.Ru Group

    729,10

    Строим Интернет

    Поделиться публикацией
    Комментарии 18
      0
      А как получается 7й пункт когда возвращают устройство полностью разряжаным? Если речь идет о телефоне, то разраб же отлаживает, а значит телефон заряжается
        0

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

        +4
        Нулевой пункт — не пытаться звонить ему с поздравлениями в воскресенье.
          +1

          -1. Не предлагайте ему работу в mail.ru

            +1
            А мне кажется тут пропущен пункт «не учите тестировщика КАК тестировать»
              0
              Eсть такое немножко :)
              Mне как-то раз ТЛ сказал «в идеале багрепорт должен содержать минимум шагов для воспроизведения». А я в тот раз в спешке сделал запись экрана, что баг все еще воспроизводится, чтобы его просто не закрыли. Как я обиделся на такое замечание! Один единственный раз мне пришлось поступить «не по Кодексу Самурая», и сразу прилетело. Я же молчу, что в идеале программа которую пишет человек с профессией Software Engineer не должна нуждаться в тестировании…
              0
              По п.5. А может кто-нибудь посоветовать статью, в которой описываются плюсы от тестирования кода самим разработчиком?
                0
                я думаю их нет. Это ведь почему делается… это как вычитка текста. Лучше всего ее сделает не автор с экрана, а другой человек с распечатки. Поэтому тестирует лучше третье лицо и официальную сборку (типа «распечатку»), а не dev билд («у меня на машине/в IDE/ работает»).
                  +1
                  Согласен — сторонний взгляд часто спасает. Меня беспокоят другие случаи — когда разработчик поменял одну строчку и сразу пушнул, не убедившись, что приложение даже запускается. Да, CI это не обновит на деве, но всё равно много пройдёт времени, прежде чем разработчик поймёт, что ещё не закончил с этой задачей.
                  +1
                  Обычно тестирование кода разработчикам не заменяет тестирование тестировщиком. Тестирование кода разработчиком как правило предусматривает проверку базовых позитивных сценариев. Очевидный плюс — что исключены ситуации когда на тестирование прилетает в принципе не рабочий код, который протестировать невозможно, потому что в нем базовый функционал не работает.
                  А еще очень полезно, если разработчик эти базовые сценарии задокументирует, т.к. некоторые вещи, очевидные разработчику не всегда очевидны тестировщику и наоборот, и такой сценарий иногда позволяет увидеть / понять причину логических ошибок.
                  0

                  Так agile поможет или не?)

                    0

                    Насчёт второго пункта и рекомендации использовать agile — а чем это собственно поможет? Допустим есть спринт две недели, есть куча задач, которые занимают скажем неделю и больше. Разработчики делают эти задачи, тестировщики в лучшем случае занимаются какими то exploratory задачами, в худшем просто курят бамбук. И за два дня до закрытия спринта и вваливается дохрена задач от разработчиков на валидацию — и привет аврал.

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

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

                          +1
                          У каждой компании свои вариации организации рабочего процесса. Ясное дело, что и при скраме/аджайле бывают факапы. Но истина в том, что все задачи не одинаковы объёмом, плюс, как вы заметили, разработчики на дев-контуре могут начинать делать задачи на следующий спринт во время простоя в текущем спринте.
                          Опять же, в компании в которой я тружусь, мы имеем право переносить задачи и снимать их с релиза в том случае, когда они не аффектят задачи параллельных команд и подразделений, что добавляет дополнительную гибкость в рабочий процесс. Также мы можем при необходимости вывести задачу в не до конца готовом виде, если в ней есть критические недостатки, чтобы не откатывать всю разработку или выводить задачи поэтапно — на часть пользователей или дробить разработку на малые части. Плюс можно выводить доработку в заблокированном или скрытом виде. В общем, возможностей море.
                          И да, как показывает практика, скрам более гибок нежели водопад. Но есть области, где водопад единственно возможен.
                        +1
                        Тестировщики не курят бамбук, а готовят тестирование этих будущих задач — создают тестовые данные, если нужно, уточняют требования, пишут тесты и чеклисты.
                        Плюс не все задачи приходят за 2 дня до конца спринта. Если разработчики выкатывают новый билд каждый раз, когда что-то готово, то спринт проходит довольно мирно. Аджайл не спасение ото всех бед, конечно. Но он довольно неплохая штука.
                        0
                        Написано так, будто никто свой код не тестирует и не должен. Компилится, мол, и так сойдет.
                          0
                          Статься в целом содержательная но и не нова по своей сути… Мне не понравилось что половина более менее интересной(не обязательно полезной) информации нужно читать по ссылке, да еще и на английском языке… Как бы статья на русском и ни что не намекает на содержание в ней инглиша. Я как бы не против, но считаю, статья от этого страдает.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое