Сегодня мир отмечает День тестировщика.
По этому случаю мы решили помочь вам взглянуть на работу этих специалистов с разных точек зрения, чтобы сотрудничество принесло всем участникам максимальную пользу и минимум стресса.
Фото: Дэвид Геринг CC BY
1. «Проверьте еще раз, бага там точно нет».
Начнем с фундаментальной проблемы.
На форуме Ars Technica есть старая тема , в котором один разработчик рассказывает о своей глубокой ненависти к «педантичным» тестировщикам.
Его ужасно раздражает, что некоторые специалисты по тестированию часами ищут мельчайшие баги.
И что самое неприятное, их все равно находят. Что может пойти не так : Не все готовы признать свои ошибки.
Кто-то заводит старую песню про «не баг, а фичу», пытаясь доказать, что все так и было задумано.
Другие настойчиво просят перепроверить код и убедиться в отсутствии ошибки.
Тестировщик просто старается хорошо выполнять свою работу, а вместо благодарности его отправляют на перепроверку.
Как быть : Всё просто: если тестировщик находит ошибку в вашем коде и вы понимаете, что он прав, лучше признать этот факт. У вас обоих одна цель — выпустить отлаженный и работающий продукт. Юмор помогает достичь взаимопонимания по этому вопросу.
Здесь статья , в котором тестировщики собрали «золотой фонд» высказываний разработчиков, пытающихся защитить свой код. Советуем вам пройтись по ним и представить, как звучат эти «классические» фразы с точки зрения тестировщика.
2. «Одна неделя до релиза.
Надеюсь, на ближайшие два дня у тебя больше ничего не запланировано.
Иногда код поступает к тестировщикам за несколько дней до релиза.
Тогда им приходится работать под давлением.
Некоторые специалисты по контролю качества учитывать что коллеги просто недооценивают свою работу.
Они якобы думают, что найти ошибки легко и быстро, поэтому откладывают отладку на последнюю минуту.
Что может пойти не так : В условиях аварийной работы испытатели не только раздражаются, но и теряют бдительность.
Нехватка времени - одна из главных причин , из-за чего тестировщики пропускают ошибки.
Как быть : Существует несколько моделей развития.
С точки зрения качества дифференцировать два основных подхода: каскадный и Agile. В первом случае тестировщики получают фрагменты кода поэтапно.
Во втором случае тестируют код параллельно с его написанием.
Agile помогает привлечь специалистов по обеспечению качества к проекту на ранней стадии.
Благодаря этому нет необходимости тестировать «за час до релиза».
Кроме того, такой подход позволяет не находить ошибки, а предотвращать их появление.
Если ваши тестировщики жалуются на постоянную нехватку времени и отсутствие ошибок, присмотритесь к этой методологии.
Фото: Тим Риган CC BY
3. «Я быстро исправил код. Посмотрите, пожалуйста"
Допустим, ваша команда работает по водопадной модели и умеет грамотно планировать этапы разработки.Тестировщики получают код, и времени на отладку вроде бы хватает. Но у разработчиков есть привычка прилагать на этом этапе минимальные усилия.
Они получают подробный отчет об ошибках, кратко его читают, быстро исправляют очевидные ошибки и отправляют код на следующий этап тестирования.
Что может пойти не так : Проблема в том, что код после поверхностных изменений часто возвращается с ещё большим количеством ошибок.
Тестировщик потратил время на составление подробного отчета и в ответ на него получил какой-то ответ. Ему придется пройти этот путь еще несколько раз только потому, что разработчик не хочет тратить время на «мелкие баги».
Как быть : Очевидно, спешить не стоит. Но этого недостаточно.
Вам нужно разобраться, почему вы не уделяете отчету должного внимания.
Если это простая лень, помочь себе можете только вы.
Есть и другие причины.
Например, вы думаете, что инженеры по контролю качества засыпают вас сообщениями о мелких ошибках.
Тогда вам нужно уточнить этот вопрос на уровне руководства — не должны ли вас тестировщики отвлекать по «мелочи».
Скорее всего, ответ будет утвердительным.
Некоторые менеджеры по продукту даже просить разработчики намеренно добавляют в код мелкие ошибки, чтобы тестировщики всегда были начеку.
Важно принять этот подход и относиться к сообщениям об ошибках с должной осторожностью.
4. «Кажется, я уже разобрался с этим багом.
Но я точно не помню».
Иногда поверхностный подход является системной проблемой.
В некоторых командах отчеты об ошибках теряются во времени и пространстве.
Никто не реагирует на сообщения должным образом и не отмечает, решена ли проблема или все еще находится в подвешенном состоянии.
Что может пойти не так : Разработчики исправляют какой-то баг, вносят в код, по их мнению, «незначительные» изменения, забывают уведомить об этом тестировщиков и отправить код на релиз.
В результате проблема проявляется, когда уже слишком поздно.
А «крайним» часто оказывается тестер.
Как быть : Проблему хаоса нужно решать системно.
Беспорядок губителен для разработки, поэтому процесс общения в команде придется полностью перестраивать.
Здесь стоит воспользоваться основными советами по налаживанию коммуникации между разработчиками и QA-инженерами: определитесь с терминологией; четко сформулировать требования; ввести иерархию приоритетов для различных ошибок.
Что касается путаницы с ошибками, то есть хорошие практические советы: а) пусть ошибки сообщают обо всем; б) далее важно расставить их по приоритетности; в) любая закрытая ошибка подразумевает, что будет написан функциональный тест; г) статус «решено» присваивается не разработчиком, а тестировщиком.
Такой подход гарантирует, что проблема действительно будет решена.
Фото: Тим Риган CC BY
5. «Зачем мне это проверять? Я не тестер!»
В некоторых командах ответственность за отладку полностью лежит на тестировщиках.Разработчики не тратят время на самые очевидные модульные тесты.
Они уверены, что это не их работа.
По большому счету это так, хотя существуют разные точки зрения на этот вопрос (мнения сообщества можно прочитать Здесь ).
Что может пойти не так : Тестировщикам в такой ситуации приходится иметь дело со всеми недостатками подряд — даже с самыми примитивными и глупыми ошибками.
Конечно, это раздражает. Как быть : Многие разработчики выступают за самотестирование перед отправкой в отдел контроля качества.
Это помогает не только разгрузить тестировщиков, но и научиться смотреть на продукт с точки зрения критика и пользователя.
Бытует мнение, что это полезно для профессионалов и лучше влияет на конечный результат. Для тех, кто не хочет утруждать себя проверками, есть автоматические инструменты.
Они помогают найти самые очевидные ошибки.
В любом случае, даже если в команде есть QA-инженеры, строгое разделение на разработчиков и QA — не самый оптимальный подход.
6. «Игорь, сегодня ты работаешь вместе с Олегом.
Тебе понравится" Менеджеры по продукту не ограничиваются водопадом и Agile. Некоторые из них любят экспериментировать.
Например, устраивать сеансы парного программирования и тестирования.
Что может пойти не так : Это эффективный способ отловить ошибки, но у него есть и недостатки — люди могут не в восторге от нововведений.
QA-специалисту, привыкшему работать один, на другом этаже и на своем оборудовании, может быть просто некомфортно покидать привычную среду.
Кроме того, его может просто не устроить опыт и знания своего партнера.
В результате вместо успешных тестов продакт-менеджеры получают двух недовольных сотрудников.
Как быть : Главный совет – не рубите с плеча.
Практики Agile и DevOps могут показаться привлекательными, но без должной подготовки они не дадут результатов.
7. «Я возьму ваше устройство на тестирование, вы согласныЭ»
У разработчика есть время заняться отладкой, он просит у тестировщика устройство для тестов «буквально на 20 минут» и уходит с ним на много часов.Что может пойти не так : Чаще всего разработчик вообще не возвращает устройство на место, а если и возвращает, то полностью разряженным.
Учитывая, что на этом устройстве у тестировщиков могут быть параллельные задачи, это не может не раздражать.
Как быть : Ставьте себе напоминания, ставьте стикеры, делайте что угодно, но, пожалуйста, возвращайте вещи тестировщиков в нужное место и вовремя.
Фото: Дэйв Аллен CC BY И главный совет разработчикам и продакт-менеджерам, который напрашивается сам собой из всех предыдущих: уважайте труд и время других людей и как можно чаще ставьте себя на место тестировщика.
Ведь если бы не он, о ваших багах знал бы весь мир.
Теги: #программирование #тестирование #тестирование ИТ-систем #праздники #день тестировщика
-
Цвет Как Фактор Производительности Труда
19 Oct, 24 -
Кланг Api. Начало
19 Oct, 24 -
Карма Падает - Минусов Не Прибавляется
19 Oct, 24 -
Jython Против Groovy Против Jruby Против…
19 Oct, 24
