Отдел обеспечения качества (QA) занимается поиском багов в ПО. Методы отличаются в разных компаниях, но обычно этим занимаются сотрудники, знакомые с программным обеспечением. Они используют его различными способами и пытаются найти баги, которые упустили разработчики.
Термин QA может относиться к самому процессу, к организации, а также к отдельному тестировщику в рамках этой организации. Обычно тестировщиков в организации по обеспечению качества называют “QA”. В этой статье для единообразия будем использовать общую аббревиатуру QA вместо более точного «тестировщик отдела обеспечения качества».
В разных компаниях отличается степень ответственности QA за общее качество продукта. Иногда термин «обеспечение качества» не совсем применим к этому отделу, если он только ищет баги и подсчитывает их количество.
Ниже приведены проблемные личности в отделе обеспечения качества (QA):
- Пожарный шланг
- Обвинитель
- Паникёр
- Ученый
- Вводящий в заблуждение
- Угнетённый
- Случайный кликер
- Беспечно дерзкий
Пожарный шланг
Тестировщик, который выдаёт огромное количество отчётов об ошибках настолько быстро, что команда разработчиков никогда не закончит работу.
- Может мутировать в паникёра
- Опасен в сочетании с менеджером проектов типа статистик
- Вероятность исправления: высокая
- Опасность для проекта: высокая
Проблема
Если найден баг, важно составить чёткий отчёт и сразу присвоить его соответствующему разработчику. Тем не менее, некоторые тестировщики способны находить баги быстрее, чем команда разработчиков их исправляет. Из-за этого список багов постоянно растёт, и все они никогда не могут быть закрыты.
На первый взгляд может показаться, что здесь проблема с качеством продукта, но не всегда это так. В отличие от обычного тестировщика, который работает с сильно глючной программой, пожарный шланг генерирует лавину отчётов с одним или несколькими характерными свойствами:
- Их отчёты слабо детализированы, что позволяет быстрее сообщать о большем количестве ошибок.
- Многие баги являются дубликатами других, так как представляют собой лишь вариации одной основной причины.
- Нет времени на воспроизведение ошибки, поскольку для написания отчёта достаточно один раз её увидеть.
Тестеры типа пожарный шланг часто появляются под прямым или косвенным давлением компании: чем больше ошибок вы обнаружите, тем лучше выполняете свою работу. Это приводит к тому, что тестировщики QA, которые старательно отслеживают фактическую первопричину ошибок и сообщают о них чётко и кратко, считаются менее продуктивными, чем пожарные шланги, выдающие максимальное количество отчётов за единицу времени.
Деятельность таких тестировщиков способна породить панику на проекте, поскольку создаётся впечатление, что продукт плохого качества, а проект теперь отстаёт от графика. Их влияние на моральный дух может быть немедленным и драматичным: команда разработчиков молит прервать поток баг-репортов.
Решение
Прежде чем исправлять пожарного шланга, жизненно важно точно его идентифицировать и не спутать с эффективным QA, который столкнулся с очень глючной системой. Самое ясное доказательство дают жалобы разработчиков:
- Большинство ошибок являются дубликатами.
- У многих багов одинаковые очевидные первопричины, поэтому их можно было сообщить как один баг.
- Сообщения об ошибках не содержат подробностей.
Для исправления ситуации пожарному шлангу следует объяснить, что нет никакого стимула сообщать о большом количестве ошибок, а цель состоит в улучшении качества системы и помощи разработчикам. После этого качество продукта должно улучшаться теми же (или лучшими) темпами, но без паники.
Обвинитель
QA, который после каждого найденного бага обвиняет разработчиков, что они не тестируют свою программу.
- Может мутировать в паникёра
- Опасен в сочетании с менеджером проектов типа статистик
- Вероятность исправления: высокая
- Опасность для проекта: низкая
Проблема
Теоретически, разработчик может найти и исправить любой баг до передачи продукта в отдел QA. Поэтому некоторые тестировщики воспринимают каждую найденную ошибку как ещё одно доказательство, что разработчики недостаточно тестируют свою работу. Этот неопровержимый аргумент позволяет обвинителю ещё громче высказывать пренебрежительное мнение о команде разработчиков.
Обвинитель разъедает мораль команды. Вместо помощи в улучшении качества продукта он старается доказать, что команда разработчиков не справляется с работой. Каждая ошибка добавляется к куче доказательств, что разработчики чрезмерно полагаются на QA вместо того, чтобы выявлять баги самостоятельно.
К сожалению, обвинители создаются в результате типичного и довольно предсказуемого процесса:
- В продакшне обнаружена критическая ошибка.
- Тестировщика обвиняют, что он пропустил этот баг.
Это происходит слишком часто, и поэтому QA естественно защищает себя, используя неопровержимый аргумент.
Решение
Прежде чем исправлять обвинителя, организация должна сначала прекратить обвинять QA за баги в продакшне. Того, кто так поступает, нужно обучить более продуктивным методам улучшения качества ПО.
Когда организация перестала укорять QA за баги в продакшне, можно исправить тестировщика-обвинителя, предложив ему сменить свой взгляд и своё отношение.
Следует довести до него, что разработчики являются просто людьми, а всем людям свойственно ошибаться. Отдел QA должен компенсировать это естественное человеческое свойство разработчиков, действуя как защита от ошибок, влияющих на клиентов. Кроме того, из-за нудного и утомительного процесса кодирования разработчику очень легко не увидеть лес за деревьями: он настолько сосредоточен на решении конкретной проблемы, что забывает проверить казалось бы очевидные вещи.
Изменение отношения: нужно помнить, что все мы работаем в команде, Товарищи не должны обвинять друг друга в совершении ошибок, а должны помочь исправить их на благо команды. Для QA особенно важно установить партнёрские отношения с командой разработчиков ради проекта, а решающее значение для качества продукта имеет бесперебойный процесс выявления багов, отчётность и жизненный цикл их исправления.
Паникёр
QA, который заявляет, что у всего продукта неприемлемый уровень качества, при этом его мнение основано только на поверхностном впечатлении.
- Может мутировать в обвинителя или пожарного шланга
- Опасен в сочетании с менеджером проекта типа пессимист
- Вероятность исправления: высокая
- Опасность для проекта: высокая
Проблема
По своей сути у разных функций приложения разное качество. Некоторые могут быть относительно простыми или разработаны высококвалифицированными разработчиками, и поэтому там мало или вообще нет ошибок. Другие относительно сложные или разработаны менее опытными разработчиками — и, следовательно, там полно ошибок. Паникёру не повезло сразу столкнуться с областью низкого качества — и он без какого-то дополнительного исследования объявил, что весь продукт негоден.
Можно много рассуждать о том, как QA утомляют разработчиков и тратят их время (см. тестировщик типа вводящий в заблуждение), но здесь двоякая ситуация. В самом деле слишком часто разработчик сознательно отдаёт в QA слабо протестированный софт, чтобы получить вознаграждение за выполненную работу или заявить, что он уложился в срок. Когда QA начинает тестировать такую систему, то сразу сталкивается с множеством ошибок, которые должен был увидеть разработчик. Поэтому понятно, что он экстраполирует увиденное на весь продукт и заявляет о критически низком качестве.
У паникёра обычно есть некоторые полномочия в отделе QA, и его мнение уважают. Чем выше уровень его полномочий, тем разрушительнее влияние на проект. Типичный сценарий выглядит следующим образом:
- Продукт передаётся в QA.
- Паникёр начинает тестирование области ужасного качества.
- Паникёр останавливает всё тестирование и сообщает начальству о серьёзной проблеме с качеством продукта.
Это классический случай выбрасывания ребёнка вместе с водой. Иногда QA делает правильный выбор, особенно когда команда разработчиков имеет репутацию передачи непроверенного программного обеспечения в QA. Но бывает, что тревогу поднимают из-за одного слабого разработчика, чей код первым попался паникёру.
Решение
Тестировщик становится паникёром, если его многократно подводила команда разработчиков. Если бы она всегда поставляла высококачественное программное обеспечение, то не было бы причин для недоверия. Но если тестировщик стал паникёром, команде разработчиков будет трудно вернуть доверие, особенно если в команде действительно есть разработчики слон в посудной лавке и некомпетентный.
Как правило, в больших командах разработки код низкого качества возникает из-за отдельных разработчиков, а не всей команды. Поэтому крайне важно, чтобы работу менее компетентных разработчиков тестировали в последнюю очередь или чтобы она не попалась паникёру. Впрочем, это скрывает истинную проблему, что в команде есть разработчики, которые негативно влияют на проект.
Учёный
Тестировщик, который большую часть времени тратит на документирование ошибок, а не на поиск новых.
- Может мутировать в угнетённого
- Опасен в сочетании с менеджером продукта типа автор патента
- Вероятность исправления: высокая
- Опасность для проекта: низкая
Проблема
Поиск проблем в системе может быть увлекательным, как поиск сокровищ. А когда вы найдёте это сокровище, не менее интересно решать головоломку. Можно утверждать, что тестировщик, который рассматривает процесс поиска ошибок таким образом, идеален. Но возникает проблема, если он стремится тщательно документировать своё увлекательное путешествие. Вместо того, чтобы сосредоточиться на основной проблеме, разработчик вынужден читать длинную историю с множеством малополезных подробностей, пытаясь выбрать релевантную информацию.
Учёный буквально воспринимает требование «тщательно документировать баги». Он описывает их в виде текстовой истории, а не краткого описания с чёткой последовательностью шагов для воспроизведения. Чтение таких отчётов занимает очень много времени, и в конце концов бывает всё равно неясно, в чём именно проблема. Обычно такое описание включает несколько багов, при этом относится к широкой области системы, а не к конкретной проблеме.
Основная жалоба от разработчиков при получении сообщений об ошибках от учёных — слишком низкое отношение сигнал/шум. Они тратят время на просеивание потока сознания, ища конкретные детали. Это потеря времени и разработчика, и тестировщика.
Решение
Учёного QA легко исправить, обучив его писать корректные отчёты. Часто исправление происходит мгновенно, как только ему объяснят, что от него требуется. Наиболее эффективный способ обучения правильному стилю — переписать один или несколько отчётов в корректном формате, который послужит образцом на будущее. В итоге восторженный тестировщик будет писать чёткие и краткие отчёты об ошибках, которые невозможно сделать более идеальными.
Вводящий в заблуждение
QA, который часто сообщает об ошибках неточно, что ведёт разработчика по неправильному пути, когда он пытается воспроизвести и исправить проблему.
- Может мутировать в паникёра
- Опасен в сочетании с менеджером проектов типа статистик
- Вероятность исправления: высокая
- Опасность для проекта: высокая
Проблема
Отчёт об ошибке должен включать следующее:
- Возможность определить, что на самом деле есть ошибка
- Возможность определения шагов для воспроизведения бага
- Целостное описание ошибки, часто с указанием основной причины
- Чёткие шаги для воспроизведения бага
На любом из этих этапов отчёт может ввести в заблуждение разработчика, в результате чего он зря потратит время:
- Если ошибки нет, разработчик тратит время на поиск проблемы, которая не существует
- Если ошибка не может быть воспроизведена, разработчик тратит время на её воспроизведение
- Если ошибка не описана должным образом, разработчик тратит время на поиск слишком конкретной или слишком широкой основной причины
- Если шаги для воспроизведения неточные, разработчик тратит время на попытки их интерпретировать или может объявить об отсутствии бага, хотя он есть
Иногда разработчик путается из-за простой ошибки тестировщика. Но вводящий в заблуждение тестировщик часто генерирует такие отчёты, вызывая значительное недовольство у разработчиков. Если ситуация будет продолжаться, тестер в конечном итоге потеряет доверие разработчиков, и те перестанут исправлять даже настоящие баги, отклоняя такие отчёты об ошибках.
Решение
Вводящий в заблуждение QA часто хорош в поиске ошибок, только плохо их документирует. Поэтому стоит потратить усилия на его обучение.
Один из наиболее эффективных методов состоит в наблюдении за разработчиком, который на основании его отчёта пытается определить проблему. Достаточно просто посидеть рядом с разработчиком, который получил один его отчётов, и спокойно наблюдать (без вмешательства), как разработчик пытается разобраться. Обычно это приведёт к здоровому разговору о том, как лучше сообщать о багах, что принесёт пользу и разработчику, и QA.
Угнетённый
QA, который избит разработчиками до такой степени, что вряд ли сообщает о каких-либо ошибках, опасаясь издевательств с их стороны.
- Может мутировать в беспечно дерзкого
- Опасен в сочетании с разработчиками типов примадонна и захватчик заложников
- Вероятность исправления: низкая
- Опасность для проекта: низкая
Проблема
Возможно, нет большего проявления снисходительности, чем типичное отношение разработчиков к QA. Кроме того, нередко можно увидеть, что агрессивные разработчики открыто запугивают тестировщика, даже если он сообщает о натуральной ошибке в их коде. Чтобы противостоять этому, успешный QA при работе с агрессивными разработчиками должен обладать следующими характеристиками:
- Уже завоевал большое доверие разработчиков, так что к его багам всегда относятся серьёзно.
- Способен проявить не меньшую агрессию и упорство в споре с разработчиком, который не признаёт баг.
К сожалению, не многие тестировщики обладают такими характеристиками, поэтому разработчики часто вытирают о них ноги и в первую очередь обвиняют QA в обнаружении нового бага. Каким бы нелогичным это ни казалось, но такова типичная картина в следующих условиях:
- У разработчика высокое чувство собственной важности (см. разработчик типа примадонна)
- Разработчик считает, что он намного лучше тестировщика знает, как работает система (см. разработчик типа захватчик заложников)
После того, как QA тщательно избивают в течение долгого времени, он обычно избегает конфронтации с враждебными разработчиками, чтобы снизить уровень стресса. Как следствие, о багах этих конкретных разработчиков редко сообщают, хотя они могут существовать. Как правило, ситуация обнаруживают только тогда, когда возникают проблемы в продакшне и начинается расследование, почему отдел тестирования не выявил баг. Угнетённый тестировщик предоставит любое из следующих объяснений:
- Он поговорил с разработчиком, и тот сказал, что это не ошибка.
- Он подал отчёт об ошибке, но разработчик его отклонил.
- Он нашёл ошибку, но «не думал, что она достаточно важная».
Пассивный характер часто мешает распознать угнетённого QA. Ключом будет анализ разработчиков, с которыми работает этот QA — поиск очевидных признаков враждебности.
Решение
Разработчики очень часто напрямую издеваются над тестировщиками. Таким образом, с ними следует поступить как с любыми хулиганами:
- Потребовать немедленно прекратить издеваться над QA и воздержаться от агрессивного поведения.
- Обучить профессиональному общению.
- Уволить, если разработчик не может исправить своё поведение.
В особо тяжёлых случаях придётся вмешаться отделу кадров, особенно если ситуация деградировала до открытой враждебности.
Печально, что эта ситуация является скорее нормой, чем исключением. Разница только в степени враждебности.
Случайный кликер
QA, который ищет ошибки методом рандомных кликов.
- Может мутировать в пожарного шланга
- Опасен в сочетании с менеджером продукта типа автор патента
- Вероятность исправления: низкая
- Опасность для проекта: низкая
Проблема
Поиск багов в системе осуществляется двумя основными методами:
- По плану тестирования путём методической обработки списка тестовых случаев.
- Случайное блуждание по приложению в попытке эмулировать действия пользователя.
Написать план тестирования — трудоёмкая задача, и нет никакой гарантии, что к моменту начала тестирования план будет ещё актуален после изменения требований. Это может привести к тому, что тестировщик полностью откажется от планов тестирования, а вместо этого просто взаимодействует с приложением в надежде найти баги.
Действительно, при случайном взаимодействии с приложением обнаруживаются ошибки, особенно на ранней стадии разработки продукта. Однако по мере взросления продукта найти ошибки таким способом будет намного сложнее, так как оставшиеся баги скрыты в пограничных случаях. Это приводит к ложному чувству безопасности, как будто у приложения нет ошибок, хотя его просто не протестировали как следует.
Важно помнить, что случайное взаимодействие с приложением по-прежнему остаётся допустимой методологией, поскольку может выявить ситуации, не задокументированные в плане. Но это лишь дополнение к плану тестирования, а не замена.
Решение
Случайный кликер может появиться в одном из двух случаев:
- Его не обучили, как правильно тестировать приложение.
- Он активно избегает работы по написанию плана тестирования.
Если проблема в недостатке обучения, то нужно обеспечить его. Однако в этом случае тестировщик всё равно может попасть во вторую категорию, не желая составлять план тестирования, даже если знает, что должен это делать.
Для написания хорошего плана тестирования требуется редкий уровень организации, усердия и концентрации. В результате определённые типы людей наслаждаются такой работой, но большинство — нет. Если вам очень повезёт, у случайного кликера обнаружатся характеристики, необходимые для написания хороших планов тестирования, но вероятность невелика.
Беспечно дерзкий
Тестировщик, отчёты которого настолько пассивно-агрессивны, что разработчики интерпретируют их как грубые.
- Может мутировать в обвинителя
- Опасен в сочетании с разработчиком типа примадонна
- Вероятность исправления: низкая
- Опасность для проекта: низкая
Проблема
Правильное составление отчёта об ошибке — трудоёмкий и когнитивно тяжёлый процесс, а некоторые QA не хотят прикладывать достаточно усилий. Как правило, это тестировщики с некоторыми правами: они считают, что им необязательно стараться и подбирать формулировки. Они также часто пренебрежительно смотрят на разработчиков и не считают, что стоит тратить время на какой-то анализ ошибок: общего заявления достаточно, чтобы разработчики метнулись выяснять, в чём дело.
Типичные баг-репорты от беспечного тестера содержат такие фразы:
- «Это не работает»
- «Это опять сломано»
- «Проблема была бы очевидна, если бы вы на самом деле использовали эту функцию»
- «Не знаю, почему это упустили»
- «Проверьте тщательнее в следующий раз»
- «Не знаю, почему мы не можем правильно это реализовать»
Очевидно, что разработчики не очень довольны отчётами, где используются подобные фразы вместо шагов для воспроизведения ошибки. Такое редко выдаёт профессиональный QA-аналитик, но часто встречается, если об ошибке сообщает другой сотрудник компании, которого попросили поискать баги. Обычно это бывает, когда перед релизом осталось мало времени, а тестировщиков не хватает. В результате такой «помощи», как правило, возникает хаос, так как отчёты отвергаются разработчиками, порождая ещё больше споров в команде, что ещё больше углубляет негодование.
Решение
Вообще, поиском багов должны заниматься профессиональные тестировщики. К сожалению, в отрасли существует мнение, что баги может искать каждый, но это не так. Более точно сказать, что любой может обнаружить ошибку, но как правило, только профессиональные специалисты QA могут идентифицировать важные ошибки, скрытые в пограничных ситуациях, и сообщить о них таким образом, чтобы разработчик мог сразу понять, воспроизвести и, следовательно, исправить этот баг.
Беспечно действующий тестировщик считает, что у него есть полное право на такие легкомысленные отчёты. Если он входит в отдел QA, его следует предупредить, чтобы он исправил своё контрпродуктивное поведение. Если же поиск багов не входит в его прямые обязанности, то ему следует запретить сообщать об ошибках, пока он не научится делать это профессионально.
Зачастую гораздо эффективнее просто удалить беспечно-дерзкого тестировщика, чем пытаться исправить его. Своими действиями он определённо даёт понять, что не хочет заниматься тестированием, так что его удаление в общих интересах.
См. также:
Автор: m1rko
