gatling

Для начала, спасибо всем ответившим!

0. Чего руководство хочет от структурированного тестирования?

1. Забудьте про автотесты.

2. Нарисуйте, что у вас сейчас есть по процессу. Как он идет? Где тратится много лишнего времени? Из-за происходят сбои?

3. Готовую схему из п.2 можно будет обсуждать с руководством и показывать, где идут проколы. И только после этого стоит менять сам процесс в сторону структурирования и организации.

0. ВСе очень просто, руководство хочет поднять уровень кач-ва тестирования, чтоб критичные баги перестали проникать на продакшн по вине плохо тестирования

1. Забыли :)

2. Очень сложно это описать. Сейчас процесс очень прост. "-Вася надо посмотреть этот модуль. - Окэээй!", соответственно что нашел - заводится на разработчику , и уже тестировщик общается с разработчиком. И посему не самые  добросовестные работники пропускают много багов закрывая таски как провенные.

3. Примерно нарисовали совместно схему. Будем пытаться ее внедрять.

С выяснения вопроса: чего им надо от тестирования? Каким определением они вообще пользуются в своих планах?

Ответы выше.

 

 

Наш проект ... с постоянно горящими сроками, и  с огромным кол-вом хотелок, доработок и т.п.

 

У вас сроки назначаются руководством или программисты и тестировщики делают оценку трудозатрат?

 

Есть шансы приоритезировать хотелки и  фиксировать scope, скажем, на неделю? Т. е. перейти от code-n-fix к коротким итерациям?

 

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

Шансы есть всегда :) вроде бы почти получилось догвоориться об этом.