Воскресный потрындец.
О тестировании.
Вот тут мне сказали:
.. в процессе тестирования найдутся баги, которые
а) тянут за собой время на исправление и перепроверку
б) могут заблокировать проверку какой-то фичи
в) создают при фиксинге новые баги
<...>
и так может повториться и еще раз, и еще раз..
Соответственно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"
На что я ответил, не претендуя при этом на какую-то вселенскую истину, а просто рассказывая как есть:
... побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлемые.
А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.
И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.
Перечитал я свой ответ и мне аж блин самому понравилось.
Взгуглил. Пояндексил. 84 и 24 ссылки. Нифига себе. Подумал и взгуглил на мунспике. 800 миллионов ссылок. Черт, так и знал, страна ориджинал контента, чтоб ее. Даже книжку написали, супостаты.
Ну, что поделаешь, тогда я расскажу, как это работает у нас. Ну или как мне бы хотелось, чтоб оно работало. Мою версию.
Waterfall нам говорит, что тестирование это этап. До своего этапа тестировщики пишут сценарии и прочие автотесты, а после - пьют горькую и проводят ретроспективы по кабакам. Как то так:
Альбом: bug
Продвинутый ватерфалл предлагает чуть допилить схему:
Альбом: bug
Мы реально нормальные и понимаем, что люди эту схему выстрадали, потому и мы ее применяем. То есть имеется тестирование на всех этапах - тестирование требований, юниты, персональный тестер программиста, дейли, предрелиз - все честь по чести. Это в масштабах продукта.
А в масштабе групп разработки нормальный такой скрам - с планированием, итерациями, митингами и демо:
Альбом: bug
Это - дано. А потом Реальность донесла свое видение ситуации:
1. Интеграционное автоматизированное тестирование ну никак не вписывалось в скрам программистов, а потому работало на викли и дейли версии и релизы.
2. Полное(и не очень) ручное тестирование релиза - не укладывалось в ежедневный и еженедельный ритм жизни и требовало себе несколько дней, несколько людей и отдельную очередь, прием по записи, крупным провайдерам, пенсионерам и сотовым операторам - без очереди и скидки
3. Тестирование требований оказалось очень мощной практикой(хитрожопые аналитики моментально прочухали, что тут есть люди, которые могут делать их работу), поэтому стало отдельной от полного сопровождения фичи опцией
горжусь и хвастаюсь: слева от меня сидит девочка, ПМы подкрадываются к начальству и шепотом просят - а можно Наташу на эту задачку? Быть может, будут предлагать денег, цветы и коньяк в виде взятки
Теперь умножаем это на количество клиентов и получаем достаточно интересную реальность, в которой вполне жизнеспособен например такой сценарий:
ПМ желает клиенту пару фич и фиксов. И организует заявку, с блоком "задание на тестирование", который ПМ составляет как из кубиков.
Альбом: bug
Эта фича требует полного сопровождения, от постановки до релиза, двум фиксам хватит ретеста в рамках скрама и дейли автотестов, этот фикс - нужно ручками проверить перед релизом. Полного тестирования релиза не надо, хватит интеграционных.
Заявка - пакет работ - попадает на ответственного тестировщика,
Альбом: bug
который выбирает незанятый народ(выгрызает время у занятого), узнает ссылки, явки и пароли, просит натравить на стенд боевые скрипты, потом суммирует результаты и высылает инфу ПМу. Который и ведет заявку дальше...
То есть получается этакий тестировщик микроПМ, клиентом которого становятся ПМы.
Альбом: bug
Ну а равномерность загрузки обеспечивается большим количеством клиентов, ПМов, собственно тестировщиков (9 штук, это целое отделение), а так же здоровым пофигизмом последних.
Пока что мы еще не полностью перешли на принцип TaaS - хотя бы потому, что а) не планировали этого делать б) вообще не знали, что этим занимаемся, просто работали.
Плюсы - удовлетворенность клиентов - ПМов. Они вроде как вовлечены в процесс и сами собирают конструктор тестирования. А значит и претензий меньше.
Еще - постоянная ротация задач и клиентов тестировщика. Возможность поруководить другими, заняться организацией и планированием.
Выводы: надо почитать, что народ пишет по ссылкам, что я нагуглил. Ну и всегда интересны ваши версии на все эти счета.
P.S. Близким манером вроде бы в Иннове работают тестировщики. У Юли Нечаевой. Вот тут она рассказывает. Ну, у нее конечное все связней и по пунктам написано. Зато у меня хендмейд картинки.
P.P.S. Это не я такой прям заебись молодец, все так красиво (или не очень) настроил. Это создавалось до меня, вместе со мной, помимо меня и кое-что против моей воли :). Ну я в том смысле что у меня замечательные коллеги, да.
P.P.P.S. Я сейчас отнюдь не занимался описанием процесса тестирования в отдельно взятом воображении отделе. Я развивал мысль о том, как мы идем в сторону Testing as a Service.
Вот тут мне сказали:
.. в процессе тестирования найдутся баги, которые
а) тянут за собой время на исправление и перепроверку
б) могут заблокировать проверку какой-то фичи
в) создают при фиксинге новые баги
<...>
и так может повториться и еще раз, и еще раз..
Соответственно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"
На что я ответил, не претендуя при этом на какую-то вселенскую истину, а просто рассказывая как есть:
... побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлемые.
А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.
И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.
Перечитал я свой ответ и мне аж блин самому понравилось.
Взгуглил. Пояндексил. 84 и 24 ссылки. Нифига себе. Подумал и взгуглил на мунспике. 800 миллионов ссылок. Черт, так и знал, страна ориджинал контента, чтоб ее. Даже книжку написали, супостаты.
Ну, что поделаешь, тогда я расскажу, как это работает у нас. Ну или как мне бы хотелось, чтоб оно работало. Мою версию.
Waterfall нам говорит, что тестирование это этап. До своего этапа тестировщики пишут сценарии и прочие автотесты, а после - пьют горькую и проводят ретроспективы по кабакам. Как то так:
Альбом: bug
Продвинутый ватерфалл предлагает чуть допилить схему:
Альбом: bug
Мы реально нормальные и понимаем, что люди эту схему выстрадали, потому и мы ее применяем. То есть имеется тестирование на всех этапах - тестирование требований, юниты, персональный тестер программиста, дейли, предрелиз - все честь по чести. Это в масштабах продукта.
А в масштабе групп разработки нормальный такой скрам - с планированием, итерациями, митингами и демо:
Альбом: bug
Это - дано. А потом Реальность донесла свое видение ситуации:
1. Интеграционное автоматизированное тестирование ну никак не вписывалось в скрам программистов, а потому работало на викли и дейли версии и релизы.
2. Полное(и не очень) ручное тестирование релиза - не укладывалось в ежедневный и еженедельный ритм жизни и требовало себе несколько дней, несколько людей и отдельную очередь, прием по записи, крупным провайдерам, пенсионерам и сотовым операторам - без очереди и скидки
3. Тестирование требований оказалось очень мощной практикой(хитрожопые аналитики моментально прочухали, что тут есть люди, которые могут делать их работу), поэтому стало отдельной от полного сопровождения фичи опцией
горжусь и хвастаюсь: слева от меня сидит девочка, ПМы подкрадываются к начальству и шепотом просят - а можно Наташу на эту задачку? Быть может, будут предлагать денег, цветы и коньяк в виде взятки
Теперь умножаем это на количество клиентов и получаем достаточно интересную реальность, в которой вполне жизнеспособен например такой сценарий:
ПМ желает клиенту пару фич и фиксов. И организует заявку, с блоком "задание на тестирование", который ПМ составляет как из кубиков.
Альбом: bug
Эта фича требует полного сопровождения, от постановки до релиза, двум фиксам хватит ретеста в рамках скрама и дейли автотестов, этот фикс - нужно ручками проверить перед релизом. Полного тестирования релиза не надо, хватит интеграционных.
Заявка - пакет работ - попадает на ответственного тестировщика,
Альбом: bug
который выбирает незанятый народ(выгрызает время у занятого), узнает ссылки, явки и пароли, просит натравить на стенд боевые скрипты, потом суммирует результаты и высылает инфу ПМу. Который и ведет заявку дальше...
То есть получается этакий тестировщик микроПМ, клиентом которого становятся ПМы.
Альбом: bug
Ну а равномерность загрузки обеспечивается большим количеством клиентов, ПМов, собственно тестировщиков (9 штук, это целое отделение), а так же здоровым пофигизмом последних.
Пока что мы еще не полностью перешли на принцип TaaS - хотя бы потому, что а) не планировали этого делать б) вообще не знали, что этим занимаемся, просто работали.
Плюсы - удовлетворенность клиентов - ПМов. Они вроде как вовлечены в процесс и сами собирают конструктор тестирования. А значит и претензий меньше.
Еще - постоянная ротация задач и клиентов тестировщика. Возможность поруководить другими, заняться организацией и планированием.
Выводы: надо почитать, что народ пишет по ссылкам, что я нагуглил. Ну и всегда интересны ваши версии на все эти счета.
P.S. Близким манером вроде бы в Иннове работают тестировщики. У Юли Нечаевой. Вот тут она рассказывает. Ну, у нее конечное все связней и по пунктам написано. Зато у меня хендмейд картинки.
P.P.S. Это не я такой прям заебись молодец, все так красиво (или не очень) настроил. Это создавалось до меня, вместе со мной, помимо меня и кое-что против моей воли :). Ну я в том смысле что у меня замечательные коллеги, да.
P.P.P.S. Я сейчас отнюдь не занимался описанием процесса тестирования в отдельно взятом воображении отделе. Я развивал мысль о том, как мы идем в сторону Testing as a Service.