Сообщений в теме: 7

[leftCh]

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

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

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

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

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

[rlabs]

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

[leftCh]

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

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

[aurik]

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

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

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

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

[leftCh]

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

[barancev]

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

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

[saveug]

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

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

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

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

[garryname]

Тикстоун