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