Раньше тоже так думал, потом пообщался с коллегами из других компаний, оказалось, что не всем это очевидно. Что уж там, сам я тоже когда-то пользовался исключительно селекторами, созданными разработчиками. Потому решил, что тема все ещё может быть актуальна.
Можно фильтровать кастомные локаторы на этапе сборки, используя переменные окружения. Например, в React-приложении функция для добавления локатора может выглядеть так:
export function locator(name?: string, type?: string, value?: string, state?: string) {
if (process.env.APP_ENV === 'production') {
return {}; // На проде возвращаем пустой объект (локаторы не добавляются)
}
return { 'data-n': name, 'data-t': type, 'data-v': value, 'data-s': state };
}
Однако не всегда есть смысл полностью убирать локаторы. Они могут быть полезны при тестировании даже на продакшене, например, для мониторинга или автоматических сценариев. Если нет строгих требований к безопасности и производительности, их присутствие не должно вызывать проблем.
Привет! Я правильно понимаю, что суть продукта – это библиотека под UI-оберткой, которая генерирует рандомные данные по заданным параметрам и возвращает JSON/XML?
Код может меняться, но логика остается. Если проблема в локаторах, то можно использовать кастомные локаторы, которые тестировщик сам накидывает в нужных местах. А еще пока идет разработка, можно готовить моки согласно контрактам и сценари
если так важно чтобы каждый пиксель был на своем месте, почему не внедрили автоматизированное скриншотное тестирование? В таком случае можно и регресс автоматизировать, и реагировать только в тех случаях, когда тест выявил несоответствие с эталоном(макетом)
О, еще добавлю, что если вашеме приложение не только что вышло в свет, возможно уже прикручена какая-то аналитика, например, Яндекс метрика. Там можно глянуть какими устройствами пользуются люди. В самом Гугле и AppStore тоже есть статистика по устройствам ваших пользователей
Мало смотреть на то, какими устройствами в основном пользуются люди в мире, стоит оценивать вашу целевую аудиторию. Например, если ваша ЦУ - состоятельные люди 25-40 лет, то смысла тестировать на старых версиях Андроид с низким разрешением экрана мало толку.
Автотесты можно начать писать до полной готовности приложения. Мы начинаем писать автотесты примерно в тот же момент, когда разработка начинает писать свой код.
Если есть зависимости от сторонних сервисах, можно использовать моки. Они ускорят ваши тесты и сделают их более стабильными. Большую часть кейсов можно замокать и выделить несколько интеграционных сценариев. Подробнее про использование моков с примерами можно почитать в статье https://habr.com/ru/amp/publications/812163/
Согласен, для человека, незнакомого с проектом это звучит дико. Но в этом и суть подхода - не оценивать по субъективным ощущениям, а по объективным параметрам. А для нас реальность такова, что аудитория, которая проходит авторизацию через почту крайне мала.
Провел больше сотни тех. собесов на позиции QAA, мой список "стрёма":
Когда кандидат не понял вопрос, но пытается на него ответить. Лучше переспросить или попросить сформулировать иначе.
Когда кандидат сочиняет и гонит чушь, вместо того, чтобы явно сказать, что не знает.
Когда кандидат пытается уйти от вопроса, рассуждая на смежные темы, в итоге я все равно попрошу дать ответ на то, что мне интересно.
Когда кандидат на секции с лайв кодингом говорит, что он не будет кодить (HR предупреждает об этой секции на тех. собесе)
имхо, лучше чем рутуб. А с православным ютубом доступ только через впн
Раньше тоже так думал, потом пообщался с коллегами из других компаний, оказалось, что не всем это очевидно. Что уж там, сам я тоже когда-то пользовался исключительно селекторами, созданными разработчиками. Потому решил, что тема все ещё может быть актуальна.
Можно фильтровать кастомные локаторы на этапе сборки, используя переменные окружения. Например, в React-приложении функция для добавления локатора может выглядеть так:
Примеры использования:
В development-среде кнопка получит атрибуты:
В production-среде атрибуты добавляться не будут:
Однако не всегда есть смысл полностью убирать локаторы. Они могут быть полезны при тестировании даже на продакшене, например, для мониторинга или автоматических сценариев. Если нет строгих требований к безопасности и производительности, их присутствие не должно вызывать проблем.
Что закладывается в понятие «QA — сформировал набор тест‑кейсов и ушел заниматься делами не связанными с работой?»
Звучит как «Ушел пить кофе, с собакой погулять, забрать посылочку с маркетплейса»
Привет! Я правильно понимаю, что суть продукта – это библиотека под UI-оберткой, которая генерирует рандомные данные по заданным параметрам и возвращает JSON/XML?
Код может меняться, но логика остается. Если проблема в локаторах, то можно использовать кастомные локаторы, которые тестировщик сам накидывает в нужных местах. А еще пока идет разработка, можно готовить моки согласно контрактам и сценари
если так важно чтобы каждый пиксель был на своем месте, почему не внедрили автоматизированное скриншотное тестирование? В таком случае можно и регресс автоматизировать, и реагировать только в тех случаях, когда тест выявил несоответствие с эталоном(макетом)
О, еще добавлю, что если вашеме приложение не только что вышло в свет, возможно уже прикручена какая-то аналитика, например, Яндекс метрика. Там можно глянуть какими устройствами пользуются люди. В самом Гугле и AppStore тоже есть статистика по устройствам ваших пользователей
могу добавить:
Мало смотреть на то, какими устройствами в основном пользуются люди в мире, стоит оценивать вашу целевую аудиторию. Например, если ваша ЦУ - состоятельные люди 25-40 лет, то смысла тестировать на старых версиях Андроид с низким разрешением экрана мало толку.
Автотесты можно начать писать до полной готовности приложения. Мы начинаем писать автотесты примерно в тот же момент, когда разработка начинает писать свой код.
Если есть зависимости от сторонних сервисах, можно использовать моки. Они ускорят ваши тесты и сделают их более стабильными. Большую часть кейсов можно замокать и выделить несколько интеграционных сценариев. Подробнее про использование моков с примерами можно почитать в статье https://habr.com/ru/amp/publications/812163/
Не смотрел пока сам учебник, но в восторге от содержания. Спасибо за проделанную работу!
Жаль, нельзя прыгать по отдельным темам, чтобы перейти к интересующей теме нужно пройти уже знакомую тему. Правда, для новичков это может быть и плюс
Согласен, для человека, незнакомого с проектом это звучит дико. Но в этом и суть подхода - не оценивать по субъективным ощущениям, а по объективным параметрам. А для нас реальность такова, что аудитория, которая проходит авторизацию через почту крайне мала.
Тут Цена - это стоимость исправления ошибки разработчиком в условных единицах (working days, story points, etc).