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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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