Для начала, спасибо всем ответившим!
0. Чего руководство хочет от структурированного тестирования?
1. Забудьте про автотесты.
2. Нарисуйте, что у вас сейчас есть по процессу. Как он идет? Где тратится много лишнего времени? Из-за происходят сбои?
3. Готовую схему из п.2 можно будет обсуждать с руководством и показывать, где идут проколы. И только после этого стоит менять сам процесс в сторону структурирования и организации.
0. ВСе очень просто, руководство хочет поднять уровень кач-ва тестирования, чтоб критичные баги перестали проникать на продакшн по вине плохо тестирования
1. Забыли :)
2. Очень сложно это описать. Сейчас процесс очень прост. "-Вася надо посмотреть этот модуль. - Окэээй!", соответственно что нашел - заводится на разработчику , и уже тестировщик общается с разработчиком. И посему не самые добросовестные работники пропускают много багов закрывая таски как провенные.
3. Примерно нарисовали совместно схему. Будем пытаться ее внедрять.
С выяснения вопроса: чего им надо от тестирования? Каким определением они вообще пользуются в своих планах?
Ответы выше.
Наш проект ... с постоянно горящими сроками, и с огромным кол-вом хотелок, доработок и т.п.
У вас сроки назначаются руководством или программисты и тестировщики делают оценку трудозатрат?
Есть шансы приоритезировать хотелки и фиксировать scope, скажем, на неделю? Т. е. перейти от code-n-fix к коротким итерациям?
Сроки на реализацию таска, ставят разработчики, мы умножаем этот срок на пи, и остальное время уходит на тестирование и багфиксинг сейчас.
Шансы есть всегда :) вроде бы почти получилось догвоориться об этом.