Код может меняться, но логика остается. Если проблема в локаторах, то можно использовать кастомные локаторы, которые тестировщик сам накидывает в нужных местах. А еще пока идет разработка, можно готовить моки согласно контрактам и сценари
если так важно чтобы каждый пиксель был на своем месте, почему не внедрили автоматизированное скриншотное тестирование? В таком случае можно и регресс автоматизировать, и реагировать только в тех случаях, когда тест выявил несоответствие с эталоном(макетом)
О, еще добавлю, что если вашеме приложение не только что вышло в свет, возможно уже прикручена какая-то аналитика, например, Яндекс метрика. Там можно глянуть какими устройствами пользуются люди. В самом Гугле и AppStore тоже есть статистика по устройствам ваших пользователей
Мало смотреть на то, какими устройствами в основном пользуются люди в мире, стоит оценивать вашу целевую аудиторию. Например, если ваша ЦУ - состоятельные люди 25-40 лет, то смысла тестировать на старых версиях Андроид с низким разрешением экрана мало толку.
Автотесты можно начать писать до полной готовности приложения. Мы начинаем писать автотесты примерно в тот же момент, когда разработка начинает писать свой код.
Если есть зависимости от сторонних сервисах, можно использовать моки. Они ускорят ваши тесты и сделают их более стабильными. Большую часть кейсов можно замокать и выделить несколько интеграционных сценариев. Подробнее про использование моков с примерами можно почитать в статье https://habr.com/ru/amp/publications/812163/
Согласен, для человека, незнакомого с проектом это звучит дико. Но в этом и суть подхода - не оценивать по субъективным ощущениям, а по объективным параметрам. А для нас реальность такова, что аудитория, которая проходит авторизацию через почту крайне мала.
Код может меняться, но логика остается. Если проблема в локаторах, то можно использовать кастомные локаторы, которые тестировщик сам накидывает в нужных местах. А еще пока идет разработка, можно готовить моки согласно контрактам и сценари
если так важно чтобы каждый пиксель был на своем месте, почему не внедрили автоматизированное скриншотное тестирование? В таком случае можно и регресс автоматизировать, и реагировать только в тех случаях, когда тест выявил несоответствие с эталоном(макетом)
О, еще добавлю, что если вашеме приложение не только что вышло в свет, возможно уже прикручена какая-то аналитика, например, Яндекс метрика. Там можно глянуть какими устройствами пользуются люди. В самом Гугле и AppStore тоже есть статистика по устройствам ваших пользователей
могу добавить:
Мало смотреть на то, какими устройствами в основном пользуются люди в мире, стоит оценивать вашу целевую аудиторию. Например, если ваша ЦУ - состоятельные люди 25-40 лет, то смысла тестировать на старых версиях Андроид с низким разрешением экрана мало толку.
Автотесты можно начать писать до полной готовности приложения. Мы начинаем писать автотесты примерно в тот же момент, когда разработка начинает писать свой код.
Если есть зависимости от сторонних сервисах, можно использовать моки. Они ускорят ваши тесты и сделают их более стабильными. Большую часть кейсов можно замокать и выделить несколько интеграционных сценариев. Подробнее про использование моков с примерами можно почитать в статье https://habr.com/ru/amp/publications/812163/
Не смотрел пока сам учебник, но в восторге от содержания. Спасибо за проделанную работу!
Жаль, нельзя прыгать по отдельным темам, чтобы перейти к интересующей теме нужно пройти уже знакомую тему. Правда, для новичков это может быть и плюс
Согласен, для человека, незнакомого с проектом это звучит дико. Но в этом и суть подхода - не оценивать по субъективным ощущениям, а по объективным параметрам. А для нас реальность такова, что аудитория, которая проходит авторизацию через почту крайне мала.
Тут Цена - это стоимость исправления ошибки разработчиком в условных единицах (working days, story points, etc).