Примерно за год мы пришли к практически полному покрытию регрессов на обе платформы. И это с учетом того, что мы продолжали тестировать функционал руками и проводить ручные регрессы, а на андроид дважды переезжали на новый фреймворк.
Подскажите, а как часто осуществлялись релизы/какой объём задач ежедневно падал на плечи тестировщиков, что команда смогла написать автотесты на регресс за достаточно небольшой промежуток времени?
И второе:
Понимаем, что автотесты в недалеком будущем принесут нам максимум пользы и выделяем каждому тестировщику, например, один день в неделю под автоматизацию
Команда тестировщиков состояла из людей, которые имеют достаточно большой опыт в написании автоматизированных тестов?
Почему меня заинтересовали эти два момента: допустим, мы имеем достаточно крупную команию с достаточно частым циклом непрерывной интеграции. В команде есть один тестировщик и, допустим, 7 разработчиков, пишущих код. Задачи, поступающие на тестировщика могут быть разноплановыми: от тривиальной (орфографические правки) до сложных бизнесовых с неявными требованиями и сложной логикой. При таком темпе работ, ИМХО, шансы заавтоматизировать регресс, а в идеале ещё и покрыть автотестами выпущенный функционал, стремятся к нулю. А если у тестировщика недостаточно навыков в автоматизации (читай джун), то вероятность написания автоматизированных тестов ещё больше уменьшается. Как тогда качественно покрыть кодом регресс?
Согласен, что, чтобы перевести регресс в от ручных проверок в автоматизированные, не нужно нанимать целую команду автоматизаторов. Тут нужно взвешенное решение, основанное на том, справляе(ю)тся ли тестировщик(и) с потоком разработки и хватает ли у него(них) времени на написание кода.
У меня возникло пару вопросов:
Подскажите, а как часто осуществлялись релизы/какой объём задач ежедневно падал на плечи тестировщиков, что команда смогла написать автотесты на регресс за достаточно небольшой промежуток времени?
И второе:
Команда тестировщиков состояла из людей, которые имеют достаточно большой опыт в написании автоматизированных тестов?
Почему меня заинтересовали эти два момента: допустим, мы имеем достаточно крупную команию с достаточно частым циклом непрерывной интеграции. В команде есть один тестировщик и, допустим, 7 разработчиков, пишущих код. Задачи, поступающие на тестировщика могут быть разноплановыми: от тривиальной (орфографические правки) до сложных бизнесовых с неявными требованиями и сложной логикой. При таком темпе работ, ИМХО, шансы заавтоматизировать регресс, а в идеале ещё и покрыть автотестами выпущенный функционал, стремятся к нулю. А если у тестировщика недостаточно навыков в автоматизации (читай джун), то вероятность написания автоматизированных тестов ещё больше уменьшается. Как тогда качественно покрыть кодом регресс?
Согласен, что, чтобы перевести регресс в от ручных проверок в автоматизированные, не нужно нанимать целую команду автоматизаторов. Тут нужно взвешенное решение, основанное на том, справляе(ю)тся ли тестировщик(и) с потоком разработки и хватает ли у него(них) времени на написание кода.