Комментарии 11
Возможно в вашей ситуации это и работает, но в целом есть два замечания: 1. О том что автотесты не проходят и их надо править вы узнаете только после выпуска версии. 2. Проверять только исправленные места приведёт к тому что просто пропустите серьёзный релиз блокер из-за того, что разработчик что-то поменял в общем классе, который используется в разных частях приложения.
Доброго дня! :)
По замечаниям отвечу:
1. Мы запускаем лаунч для регресса релизной сборки в котором ручные тесты + автотесты. Пока проходим руками, прогоняется сборка с автотестами. После завершения прогона автотесты в статусе Failed мы просматриваем вручную. Так как мы постарались сделать их проще, то таких кейсов небольшое количество.
2. Для того чтобы не пропустить баг в важном функционале у нас есть обязательные кейсы, которые входят в каждый тест план. Мы их отметили тэгом Regress_everytime
По замечаниям отвечу:
1. Мы запускаем лаунч для регресса релизной сборки в котором ручные тесты + автотесты. Пока проходим руками, прогоняется сборка с автотестами. После завершения прогона автотесты в статусе Failed мы просматриваем вручную. Так как мы постарались сделать их проще, то таких кейсов небольшое количество.
2. Для того чтобы не пропустить баг в важном функционале у нас есть обязательные кейсы, которые входят в каждый тест план. Мы их отметили тэгом Regress_everytime
Это был не камень в ваш огород, а просто наболевшее. Что
1. чем больше автотестов, тем больше времени и сил уходит на их поддержку и нужно очень внимательно следить за их состоянием. Плюс есть гадкие изменения, когда автотесты работают неправильно после изменения, но не фейлятся. В любом случае автоматизация ускоряет процесс регрессионного тестирования, но увеличивает время на поддержку этой автоматизации.
2. Это наверное самое сложное и ответственное — решить тестирование какого функционала важное, а какое не очень. Но при этом все равно необходимо как минимум на мажорных версиях прогонять полную регрессию.
В любом случае достаточно полная и полезная статься, на мой взгляд.
1. чем больше автотестов, тем больше времени и сил уходит на их поддержку и нужно очень внимательно следить за их состоянием. Плюс есть гадкие изменения, когда автотесты работают неправильно после изменения, но не фейлятся. В любом случае автоматизация ускоряет процесс регрессионного тестирования, но увеличивает время на поддержку этой автоматизации.
2. Это наверное самое сложное и ответственное — решить тестирование какого функционала важное, а какое не очень. Но при этом все равно необходимо как минимум на мажорных версиях прогонять полную регрессию.
В любом случае достаточно полная и полезная статься, на мой взгляд.
Автотесты стали гораздо стабильнее, т.к. не завязаны на сервисы или моки, которые могут отваливаться в любой момент. (А этот любой момент обычно самый неподходящий)Не могу понять, как тесты без моков могут стать стабильнее. Тем более, если отсечь бэк, то автотесты на фронт без моков невозможно сделать.
Хорошая статья! Все разложено по полочкам и читается очень легко.
1 «Практически все позитивные сценарии проверки покрыты тест кейсами». Это почему так? Ведь и отрицательные тоже прекрасно покрываются автотестами.
2 Чисто профессионально. Как быстро пробегают у вас эти 200 тестов на телефонах?
2 Чисто профессионально. Как быстро пробегают у вас эти 200 тестов на телефонах?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как сохранить нервы тестировщика или ускорить регресс с 8 до 2 часов