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

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

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

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

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

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

Для многих компаний я мог бы увидеть систему, в которой команды программирования обмениваются обязанностями по проверке кода и тестированию для кода друг друга. Например, члены команды бизнес-логики могли бы периодически проводить экскурсии, тестируя и просматривая код для команды UI, и наоборот. Таким образом, вы не обладаете талантом разработчика "wasting" на очном тестировании, но вы получаете преимущества, подвергая код (надеюсь) экспертной проверке и наказанию. Затем более традиционная команда QA может приступить к тестированию "black box".

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

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

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

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

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

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

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

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

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

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

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

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

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

Приемочные / клиентские испытания _ _ _ = _ _ _ _ _ тестирование свойств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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