Вот этот вопрос меня тоже периодически беспокоит. Например, я знаю, что один цикл тестирования займет 3 недели. Но ведь в процессе тестирования найдутся баги, которые а) тянут за собой время на исправление и перепроверку б) могут заблокировать проверку какой-то фичи в) создают при фиксинге новые баги и через три недели оказывается, что продукт сырой, багов много исправили, но еще больше внесли при исправлениях, состояние продукта неизвестно, надо тестить все снова. "Надо ускориться!" Ускоряемся, часть тестов с низким приоритетом не выполняем, укладываемся в 2 недели. и так может повториться и еще раз, и еще раз..
Соответсвенно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"
Наверное, стоит постоянно уточнять формулировки. Не "два месяца на тестирование", а "две сессии тестов по 2 недели" (тоже невкусно, но полегче, и мы уже говорим о чистом времени).
Или побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлимые. А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.
И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.
А то поди-ка складывается ощущение, что тестировщики и только тестровщики что то свое варят два месяца подряд.
Например, я знаю, что один цикл тестирования займет 3 недели.
Но ведь в процессе тестирования найдутся баги, которые
а) тянут за собой время на исправление и перепроверку
б) могут заблокировать проверку какой-то фичи
в) создают при фиксинге новые баги
и через три недели оказывается, что продукт сырой, багов много исправили, но еще больше внесли при исправлениях, состояние продукта неизвестно, надо тестить все снова.
"Надо ускориться!" Ускоряемся, часть тестов с низким приоритетом не выполняем, укладываемся в 2 недели.
и так может повториться и еще раз, и еще раз..
Соответсвенно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"
Reply
Наверное, стоит постоянно уточнять формулировки. Не "два месяца на тестирование", а "две сессии тестов по 2 недели" (тоже невкусно, но полегче, и мы уже говорим о чистом времени).
Или побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлимые.
А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.
И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.
А то поди-ка складывается ощущение, что тестировщики и только тестровщики что то свое варят два месяца подряд.
Reply
Leave a comment