Должны ли разработчики участвовать в этапах тестирования?

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

Поэтому мой вопрос прост: должны ли разработчики участвовать в этапах тестирования, и не слишком ли это «опасно». Боюсь, что это даст руководителям проектов ложное чувство лучшего качества, поскольку работа уже выполнена, но будут ли добавленные man.days иметь какую-то ценность? Я не совсем уверен, что разработчики проводят тесты (здесь без обид, но мы все знаем, что довольно сложно сломать в несколько кликов то, что вы сделали за несколько дней).

Спасибо, что поделились своими мыслями.

(*) По непонятным причинам увеличение количества тестеров на сегодняшний день не вариант.

(Просто заранее, это не дубликат того, должны ли программисты помогать тестировщикам в разработке тестов? Что говорит о подготовке тестов, а не о выполнении тестов, где мы избегаем участия разработчиков)

Глядя на ваш вопрос очень буквально («участвует в») Мой единственный ответ является абсолютно однозначным

ДА

У разработчиков никогда не должно быть окончательного мнения о собственном коде.

Но разработчики должны участвовать в тестировании работы других разработчиков. Это делает две вещи:

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

Наконец, почему бы вам не использовать как можно больше глаз? Вы редко можете позволить себе пройти процесс найма и адаптации, чтобы привлечь дополнительных специалистов по контролю качества на время кризиса. Итак, где вы найдете дополнительные глаза, которые вам нужны? Или вы пытаетесь пережить время кризиса с тем же количеством QA, которое было у вас все это время? Даже если разработчики тратят 20% своего времени на тестирование и 80% исправляют обнаруженные ошибки, приложение все же больше смотрит на приложение, чем раньше. Автоматизированное тестирование дает вам только определенный уровень уверенности и никогда не будет на 100%.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

Для всего, кроме юнит-тестирования, абсолютно нет. Разработчики слишком много знают о приложении и о том, как оно «должно» работать, чтобы быть объективными тестировщиками.

Принципиальное различие в философии тестирования между разработчиками и Qs заключается в следующем: программист обычно проверяет свою программу, чтобы доказать, что его код работает («положительное» тестирование). QA может и делает это, но также уделяет дополнительное внимание поиску того, что не работает , пытаясь взломать программное обеспечение (используя «отрицательное» тестирование).

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

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

Ну с точки зрения тестирования, есть 3 типа.

Черный ящик, серый ящик и белый ящик.

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

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

Вот основная часть: Белая коробка относится к разработчикам, тестирующим продукт на уровне кода. Это означает, что они выполняют модульное тестирование, отладку и т. Д.

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

UNIT TESTING является обязательным для всех разработчиков

Для получения информации о том, как это можно использовать в ваших интересах, прочитайте следующие ссылки, если вы занимаетесь разработкой на C ++:

• Краткое введение в Google C ++ Testing Framework
• Инструменты модульного тестирования C / C ++ с открытым исходным кодом. Часть 1. Знакомство с платформой модульного тестирования Boost
• Инструменты модульного тестирования C / C ++ с открытым исходным кодом. Часть 3. Знакомство с CppTest

НЕТ СПОСОБА, КАК ЧЕЛОВЕК МОЖЕТ ДЕЛАТЬ ЭТИ ИСПЫТАНИЯ. НИ ЗА ЧТО.

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

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

Ты пишешь:

Проблема в том, что из-за проблем с ресурсами (*) этапы тестирования слишком длинные и часто укорачиваются из-за нехватки времени, потому что разработчики их не делают. Одна из крупнейших интернет-компаний, предоставляющая самые стабильные продукты, вообще не использует тестеры. Они используют только автоматическое тестирование, все сделано самими разработчиками. Результаты в 10 раз лучше, чем когда разработчик оставляет тестирование «тестерам».

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