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

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

В промежутке между ними предстоит еще довольно много испытаний

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

Я размещаю свой ответ на вопрос на нашем внутреннем форуме.Если у вас есть час или около того..послушайте песню Мэри Поппендик Соревнуясь на основе скорости Видео. Рекомендуемые

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

Разработчик / модульные тесты ________=_______ Тестирование юзабилити и исследовательские работы тестирование

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

Приемо-сдаточные испытания для заказчика ___=_____ Тестирование свойств

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

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

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

Answer 9

Вот несколько способов, с помощью которых тестирование разработчиком является наиболее эффективным / с наибольшей отдачей:

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

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

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