Программисты отдают на тестирование программы работающие менее чем нап

Программисты отдают на тестирование программы работающие менее чем наполовину

Есть требования, программисты отдают на тестирование программы реализующие менее половины требований, либо очень сырую версию, где любой шаг влево-вправо от smoke сценария вызывает дефект.

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

Как максимально правильно реагировать на такую ситуацию?

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

Вроде бы всё хорошо — руководство устраивает тот уровень качества, который выдает разработка. Разве это проблема?

руководство устраивает тот уровень качества, который выдает разработка.

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

руководство устраивает тот уровень качества, который выдает разработка.

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

Вполне объяснимые претензии. Качество продукта никудышное - проверили не все, а ошибки, которые нашли не исправили. Другое дело, кто сказал, что за качество отвечает только тестировщик? Программист отвечает за качество не меньше, а может быть и больше. Задача тестировщиков предоставить Руководству информацию о качестве продукта. Если вы ее не предоставляете - вы плохой тестировщик. Если вы ее предоставляете, то тогда уже забота Руководства сделать так, что бы качество улучшилось. Например, снизить нагрузку на разработчиков; уволить младших программеров и нанять вместо них гуру; разогнать всех тестировщиков, что бы не мешались под ногами. Вариантов много...

Задача тестировщика - довести до Руководства, что протестировано, а что не протестировано и сколько дополнительно нужно времени, что бы протестировать все, что планировалось. Какие серьезные, на ваш взгляд, ошибки еще не исправлены. Внимание: то, что кажется вам серьезным дефектом, может оказаться не столь важным недочетом для Руководителя, а то, что вам кажется мелочью может оказаться самой серьезной проблемой во всем продукте. Как узнать что важно, а что нет? Поговорить, спросить, посоветоваться, изучать матчасть, влезать в нюансы бизнес-процессов. Чем полезнее будет предоставляемая вами информация - тем выше рейтинг тестировщиков в глазах Руководства. Станьте звездами команды разработки и к вашему мнению будут прислушиваться чаще!

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

Если что-то не было должным образом протестировано то сверху спускают претензии к качеству.

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

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

Анализ причины: ресурсов для тестирования явно не достаточно (+ обоснование, что действительно недостаточно).

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

Уже проходили это - работает, а если не сработает, значит то качество, которого Вы добиваетесь, никому не нужно. А вот с этим что делать - решать Вам лично :)

Тикстоун