Тестирование разработчиков и командное тестирование QA - каково правильное разделение работы?

Пытаясь отстаивать большее количество тестов разработчиков, я нахожу аргумент: «Разве это не работа QA?» используется много. На мой взгляд, нет смысла возлагать на команду QA все обязанности по тестированию, но в то же время Спольски и другие говорят, что вы не должны использовать разработчиков за 100 долларов в час, чтобы делать то, что может делать тестировщик за 30 долларов в час. . Каков опыт других сотрудников компании со специальной командой QA? Где следует провести разделение работы?

Уточнение: я имел в виду QA как команду проверки и проверки. Разработчикам не следует проводить валидацию (тестирование, ориентированное на клиента), но где находится точка подразделения верификации (функционального тестирования)?

Ответов (9)

Решение

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

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

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

В этом свете дело не столько в использовании разработчиков для тестировщиков, сколько в некотором разрозненном парном программировании, когда один разработчик делает акцент на контроле качества.

С другой стороны, многие тесты (например, базовые функциональные возможности пользовательского интерфейса) откровенно не требуют такого рода навыков. В этом смысл Джоэла.

Для многих компаний я мог видеть систему, в которой команды программистов обменивают обязанности по обзору кода и тестированию для кода друг друга. Члены группы Business Logic, например, могли бы время от времени проводить экскурсии по тестированию и проверке кода для команды пользовательского интерфейса, и наоборот. Таким образом, вы не «тратите впустую» талант разработчика на постоянное тестирование, но вы получаете преимущества, заключающиеся в том, что код подвергается (надеюсь) экспертной проверке и наказанию. Затем более традиционная команда QA может заняться тестированием «черного ящика».

Есть 2 типа групп qa, которые хотят сохранить статус-кво. Мы всегда так поступали. Они естественно ненавидят и избавляются от тех, кто пытается сделать вещи более эффективными и, следовательно, выходит за пределы их зоны комфорта. Со мной такое случалось не раз. К сожалению, менеджеры по контролю качества так же некомпетентны, как и их команды по контролю качества. Таким образом, менеджер по качеству, который руководил в течение последних 6 лет, убьет любую автоматизацию, введет множество процессов только для того, чтобы оправдать свое существование. Это ответственность высшего руководства - признать это. Есть несколько технических специалистов, которые разбираются в инструментах. К сожалению, язык программирования - это не инструмент, а видение. Работа с этими людьми действительно зависит от того, как много они хотят учиться и насколько руководство готово рискнуть, чтобы что-то изменить. Тесты должны быть написаны так же, как основной код написан, объектно-ориентированная структура проста в обслуживании. Я считаю, что разработчикам стоит пересмотреть qa-тесты. В большинстве случаев я обнаруживал, что автоматизация ничего не тестирует. К сожалению, работа над qa считается низшим классом, поэтому разработчики не беспокоятся. Мне самому везет, когда я получаю поддержку от влиятельного разработчика в группе, который готов объяснить мои усилия менеджеру. К сожалению, это работает только в половине случаев. Тестировщики ИМХО должны отчитываться перед дев-менеджером. И вся команда должна нести ответственность за то, какие тесты qa на самом деле тестируют. Мне самому везет, когда я получаю поддержку от влиятельного разработчика в группе, который готов объяснить мои усилия менеджеру. К сожалению, это работает только в половине случаев. Тестировщики ИМХО должны отчитываться перед дев-менеджером. И вся команда должна нести ответственность за то, какие тесты qa на самом деле тестируют. Мне самому везет, когда я получаю поддержку от влиятельного разработчика в группе, который готов объяснить мои усилия менеджеру. К сожалению, это работает только в половине случаев. Тестировщики ИМХО должны отчитываться перед дев-менеджером. И вся команда должна нести ответственность за то, какие тесты qa на самом деле тестируют.

Вот несколько причин, по которым тестирование для разработчиков является наиболее эффективным / максимальным вознаграждением:

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

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

Мы говорим о контроле качества или валидации? Я думаю о QA как о контрольных списках проверок, соблюдении стандартов кода, руководящих принципах пользовательского интерфейса и т. Д. Если мы говорим о валидации, разработчикам не имеет смысла тратить много времени на создание и выполнение формальных тестовых примеров, но разработчики должен содержать все обоснование и проектную документацию, необходимую для создания хороших тестов.

Всегда должно быть какое-то тестирование разработчика. Если разработчик создает слишком много ошибок, то позже он / она тратит время на исправление этих ошибок. Важно, чтобы у разработчиков не выработалась позиция, которая гласит: ну, хорошо, если я оставлю ошибку, она будет обнаружена, и я получу шанс ее исправить.

Мы стараемся удерживать порог количества ошибок. Если этот порог будет превышен во время тестирования, ответственность за это несет разработчик. Вам решать, каков этот порог (для нас он может варьироваться от проекта к проекту).

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

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

Я выкладываю свой ответ на вопрос на нашем внутреннем форуме. Если у вас есть час или около того ... послушайте Конкуренцию Мэри Поппендик на основе видео Speed . рекомендуемые

Примечание (от тестировщиков - я имею в виду команду QA)

Разработчик / Модульные тесты ________ = _______ Юзабилити-тестирование и исследовательское тестирование

'================================================= =================

Приемочные / клиентские испытания ___ = _____ Тестирование собственности

Представьте, что это квадрат с четырьмя квадрантами. :)

Левая половина должна быть автоматизирована.

  • Тесты разработчика подтверждают, что код работает так, как хотел кодировщик. Инструменты: NUnit / xUnit / любой самодельный инструмент
  • Клиентские тесты подтверждают, что код работает так, как этого хотел заказчик. Тесты должны быть очень простыми в написании и не должны требовать от клиента изучения .NET / Java. В противном случае заказчик не будет писать эти тесты (хотя ему может потребоваться помощь разработчика). Например, Fit использует таблицы HTML, которые можно писать в Word. Инструменты: Здесь также лежат инструменты FIT Regression. Запись-воспроизведение.

Правая половина лучше использует время и усилия хороших тестировщиков. например, никакой автоматический тест не может сказать вам, можно ли использовать X-диалог. Люди в этом лучше, чем машины.

  • Юзабилити. Попытайтесь сломать систему (поймайте необработанные сценарии сбоя, введите нулевые значения). В основном ловите то, что упустил разработчик.
  • Для проверки собственности снова требуются люди. Здесь вы проверяете требуемые клиентом свойства, которые требуются вашей системе. например, «Производительность» - соответствует ли время отклика вашего диалогового окна 2 секундам? Безопасность - может ли кто-нибудь взломать эту Систему? и т.д. Доступность - ваша система онлайн в 99,99% случаев?

Тестировщикам не следует тратить время на выполнение планов тестирования левой половины. Это ответственность разработчиков за то, чтобы код работал так, как задумал заказчик и разработчик. Фактически, тестировщики могут помочь заказчику сформулировать приемочные испытания.

Моя общая позиция заключается в том, что тестировщики никогда не должны находить ошибки на уровне модулей (включая пограничные случаи). Тестеры ошибок должны находить на уровне компонентов, интеграции или системы. Конечно, сначала тестировщики могут обнаружить ошибки «счастливого пути» и другие простые ошибки, но эти аномалии следует использовать, чтобы помочь разработчикам улучшаться.

Частично ваша проблема может заключаться в использовании разработчиков за 100 долларов в час и тестировщиков за 30 долларов:}. Но независимо от стоимости, я думаю, зная, что ошибки, обнаруженные на ранних этапах цикла разработки, неизбежно дешевле, вы, вероятно, все равно сэкономите деньги, предоставив разработчикам больше возможностей для тестирования. Если у вас есть высокооплачиваемая команда разработчиков и хак-тестеры, вы, вероятно, обнаружите много больших очевидных проблем, но вы пропустите множество более неясных ошибок, которые будут преследовать вас позже.

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

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

Разработчики должны проводить модульное тестирование с охватом кода написанного кода в качестве минимальной цели.

Между ними еще предстоит провести немало испытаний.

  • полное тестирование пути кода
  • Компонентное тестирование
  • Интеграционное тестирование (компонентов)
  • Системное (интеграционное) тестирование
  • так далее

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

Поговорите друг с другом, узнайте, что всем удобнее всего делать. Это займет некоторое время, но оно того стоит.

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

Кроме того, я обнаружил, что мы проводим много QA при проверке кода, поскольку люди будут предлагать дополнительные крайние и угловые случаи, которые они хотят видеть добавленными в проверяемые модульные тесты (вместе с кодом, который они тестируют, конечно). .