Комментарии 7
Спасибо за статью.
У меня есть пара вопросов по статье и по организации работы:
1. Подскажите пожалуйста в статье не упоминания о unit тестах, как и в каком объеме они у вас используются, и влияют ли на конечное количество сценариев UI и API тестов?
2. Очень интересно какие вы используете среды запуска тестов, например тестирование в облаке, тестирование в докер контейнерах. Как при этом выглядит кроссплатформенное и кроссбраузерное тестирование?
3. Вы писали «Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом» — можете подсказать, на основе чего идет выбор сценариев для автоматизации, берутся частые баги из трекера, берутся строгие сценарии из документации, либо происходит еще какое-то внутреннее согласование с аналитиками проекта/ручными тестировщиками?
У меня есть пара вопросов по статье и по организации работы:
1. Подскажите пожалуйста в статье не упоминания о unit тестах, как и в каком объеме они у вас используются, и влияют ли на конечное количество сценариев UI и API тестов?
2. Очень интересно какие вы используете среды запуска тестов, например тестирование в облаке, тестирование в докер контейнерах. Как при этом выглядит кроссплатформенное и кроссбраузерное тестирование?
3. Вы писали «Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом» — можете подсказать, на основе чего идет выбор сценариев для автоматизации, берутся частые баги из трекера, берутся строгие сценарии из документации, либо происходит еще какое-то внутреннее согласование с аналитиками проекта/ручными тестировщиками?
Спасибо!
1. Чаще всего unit-тесты пишут и сопровождают разработчики. Специалисты направления SDET не разрабатывают и не используют в процессах автоматизации тестирования unit-тесты, реализуя независимое тестирование.
2. Для запуска тестов мы используем и различные тестовые окружения-стенды, и докер-контейнеры. Кроссплатформенность можно реализовать через разведение по различным окружениям, а кроссбраузерность — на уровне кода автотестов с использованием параметризации, либо с использованием контейнеров.
3. В первую очередь выбираем самые часто используемые сценарии использования со стороны пользователей (например — авторизация, добавление товара в корзину), затем идут сложные (для воспроизведения) или длительные (по времени выполнения) сценарии, и так далее. Приоритеты выставляем по согласованию со специалистами QA, тимлидом, product owner.
1. Чаще всего unit-тесты пишут и сопровождают разработчики. Специалисты направления SDET не разрабатывают и не используют в процессах автоматизации тестирования unit-тесты, реализуя независимое тестирование.
2. Для запуска тестов мы используем и различные тестовые окружения-стенды, и докер-контейнеры. Кроссплатформенность можно реализовать через разведение по различным окружениям, а кроссбраузерность — на уровне кода автотестов с использованием параметризации, либо с использованием контейнеров.
3. В первую очередь выбираем самые часто используемые сценарии использования со стороны пользователей (например — авторизация, добавление товара в корзину), затем идут сложные (для воспроизведения) или длительные (по времени выполнения) сценарии, и так далее. Приоритеты выставляем по согласованию со специалистами QA, тимлидом, product owner.
Да, до этих штучек мастер этот самый Джеймс Ланкастер.
Да, действительно автотесты существенно повышают качество продукта, при этом трудозатраты на проверку в перспективе снижаются. В случае ночных тестов экономится ещё и время. А с формальной верификацией не разбирались?
В ваших подсчетах сэкономленного времени не учитывается время на разработку и поддержку (актуализацию) автотестов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что дает автоматизация тестирования