При убеждении разработчиков делать правильно можно использовать как козыри такие хайповые слова: Continuous Integration, Docker. Потому что если вы захотите запускать окружение в докере, вы наступите на проблему доступа из тестов к базе, а особенно к SSH. Ещё не лишним будет напомнить разработчикам и себе для чего и кому нужны автотесты. Они нужны не руководству и даже не тестерам, а прежде всего разработчикам, чтоб получать быструю обратную связь. В общем, разворачивайте холивар в правильном направлении :)

При убеждении разработчиков делать правильно можно использовать как козыри такие хайповые слова: Continuous Integration, Docker. Потому что если вы захотите запускать окружение в докере, вы наступите на проблему доступа из тестов к базе, а особенно к SSH. Ещё не лишним будет напомнить разработчикам и себе для чего и кому нужны автотесты. Они нужны не руководству и даже не тестерам, а прежде всего разработчикам, чтоб получать быструю обратную связь. В общем, разворачивайте холивар в правильном направлении :)

Спасибо за развернутый ответ, у нас итак всё в докерах, проблем с доступом нет, сейчас холивар перетёк в другое русло, задают вопрос типа если надо натравить на копию боевого окружения куда нет доступа к базе, отсюда следующий вопрос:

Данные, которые нужны для тестов (предусловия) вы как кладёте?

у меня вариантов в голове много, но в качестве аргументов требуют "общепринятую практику", вот я и спрашиваю кто как делает ))

Опять же, TestAPI. Каждый тест себе создаёт фикстуру и с ней работает. Но ситуации бывают разные, иногда бывает эффективнее иметь заранее подготовленные образы БД с готовыми данными (например, для нагрузочных тестов)

Между написанием АПИ для тестов и выдачей подключения к базе выбрали вариант позволить подключаться к базе :D Но а вообще спасибо за наводку, я приемочными мало занимался и не слышал ранее о такой практике.

ну как бы общей практики тут быть не может: если проект маленький и генерить данных не много - дешевле сначала создать данные 1 раз и на них гонять; если тестов миллион и хочется их параллелить и запускать со десятка источников в раз - то тут без подготовки данных через коннект к базе/апи или в самом ui - будет не обойтись - но нужно понимать что написание такой подготовки увеличивает количество кода тестов, усложняет архитектуру тестов, усложняет поддержку и вообще кушает много ресурсов тех, кто автоматизирует это; Подготовленные данные в этом плане имеют плюс: готовить ничего не надо - просто начинаешь тестировать в тесте и все. Нужно анализировать все возможные аспекты в каждом варианте, с наложением на вашу систему и анализом ваших ресурсов. Может вам нужно простые и легкоподдерживаемые тесты, что бы 1 человек мог их поддерживать ? А может вам нужно что бы прогонялись максимально быстро и вам готовы еще 10 человек нанять и развернуть грид на 1000 браузеров?.. Тут все индивидуально.

Добрый день. Тема для разговора - что должны проверять UI тесты селениумом. Пришел я на проект, котором только начинают писать автотесты для UI части. Люди на проекте считают, что тесты UI должны проверять только наличие элементов на странице, а на значение внутри этих элементов можно забивать, т.к. написаны уже апи тесты. И еще есть у этих людей есть желание написать отдельно тесты на UI, отдельно на API и отдельно для E2E. Насколько вы разделяете мнение этих людей?

Добрый день. Тема для разговора - что должны проверять UI тесты селениумом. Пришел я на проект, котором только начинают писать автотесты для UI части. Люди на проекте считают, что тесты UI должны проверять только наличие элементов на странице, а на значение внутри этих элементов можно забивать, т.к. написаны уже апи тесты. И еще есть у этих людей есть желание написать отдельно тесты на UI, отдельно на API и отдельно для E2E. Насколько вы разделяете мнение этих людей?

Разделяю. UI дорого, поэтому лучше логику проверять более низкоуровневыми тестами, а для UI оставить проверки работоспособности интерфейса. Ну и прикондишны делать для UI тестов лучше через API или запросы к БД. имхо, конечно.

Разделяю. Надо конечно смотреть детали, но общий подход похож на правильный - "пирамиду автотестов", где UI и E2E (зачастую это синонимы) - это очень мало тестов. И их цель - проверить, что "сигнал проходит end-to-end", а весь функционал проверяется на нижележащих уровнях пирамиды UI и E2E могут быть не синонимами, например, UI можно тестировать на уровне JS-кода, юнит тестами, и для этого не нужен Selenium, а используются соответствующие тестовые JS-фреймворки. И здесь можно проверять наличие и функционирование элементов интерфейса, например, что при нажатии на кнопку происходит отправка JSON на ожидаемый backend endpoint

Разделяю. Надо конечно смотреть детали, но общий подход похож на правильный - "пирамиду автотестов", где UI и E2E (зачастую это синонимы) - это очень мало тестов. И их цель - проверить, что "сигнал проходит end-to-end", а весь функционал проверяется на нижележащих уровнях пирамиды UI и E2E могут быть не синонимами, например, UI можно тестировать на уровне JS-кода, юнит тестами, и для этого не нужен Selenium, а используются соответствующие тестовые JS-фреймворки. И здесь можно проверять наличие и функционирование элементов интерфейса, например, что при нажатии на кнопку происходит отправка JSON на ожидаемый backend endpoint

Кстати, про смотреть детали вы верно заметили. Очень зависит от проекта; уверен, что вполне возможны ситуации, в которых пирамида у вас будет вверх ногами )))

Добрый день. Тема для разговора - что должны проверять UI тесты селениумом. Пришел я на проект, котором только начинают писать автотесты для UI части. Люди на проекте считают, что тесты UI должны проверять только наличие элементов на странице, а на значение внутри этих элементов можно забивать, т.к. написаны уже апи тесты. И еще есть у этих людей есть желание написать отдельно тесты на UI, отдельно на API и отдельно для E2E. Насколько вы разделяете мнение этих людей?

А там на странице совсем нет функционала, не связанного с api? Всякие конструкторы (корзина с товарами), валидаторы форм ввода, вот это все? Фронтэнд совсем без бизнес логики?

А там на странице совсем нет функционала, не связанного с api? Всякие конструкторы (корзина с товарами), валидаторы форм ввода, вот это все? Фронтэнд совсем без бизнес логики?

Или используются стандартные компоненты и считается, что они авторами оттестированы?

А там на странице совсем нет функционала, не связанного с api? Всякие конструкторы (корзина с товарами), валидаторы форм ввода, вот это все? Фронтэнд совсем без бизнес логики?

есть отображение елементов на основании ответа апи

Клиентская логика: отображение элементов, контента, состояния клиента - ui тестами. Серверная логика: функциональные и контрактные api тесты, юниты.

Ребята, а кто-нибудь пользуется ACC (attribute component capability) - анализом как в гугле на своих проектах?

я пробовал на 3 проектах

только мне не кажется что в гугле им таки сейчас пользуются

и пробовал я прям с использованием их тулы

в результате мне показалась сама тула неприемлемо сырой и от подхода отказался

в результате мне показалась сама тула неприемлемо сырой и от подхода отказался

Ну их тулой не обязательно пользоваться, как я понял это подход к документированию продукта больше

ребята, подскажите хорошие курсы\школы на тему автоматизации тестирования мобильных приложений и web

На software-testing.ru, вроде, неплохие Базу точно можно получить

Ну их тулой не обязательно пользоваться, как я понял это подход к документированию продукта больше

да, необязательно, но мой опыт был таков, как-то иначе я не пробовал

ребята, подскажите хорошие курсы\школы на тему автоматизации тестирования мобильных приложений и web

guru99.com

но там курс с testNG, не с JUnit, если это важно

Коллеги, всем привет! Я сам родом из Киева, но работаю QA в Торонто, Канада. Пишу автотесты на С# (Selenium, NUnit, SpecFlow). Кто знает - как тестировать Angular JS элементы GUI? Я с трудом их нахожу через Inspect element. Прочитал кучу документации - в основном все тестирование GUI основано на HTML/CSS

скинь пример странички и элемента которых не находится

Коллеги, всем привет! Я сам родом из Киева, но работаю QA в Торонто, Канада. Пишу автотесты на С# (Selenium, NUnit, SpecFlow). Кто знает - как тестировать Angular JS элементы GUI? Я с трудом их нахожу через Inspect element. Прочитал кучу документации - в основном все тестирование GUI основано на HTML/CSS

Насколько знаю, для тестирования ангуляра есть Protractor, но он на JS. Возможно есть какая-то его вариация на C#

Коллеги, всем привет! Я сам родом из Киева, но работаю QA в Торонто, Канада. Пишу автотесты на С# (Selenium, NUnit, SpecFlow). Кто знает - как тестировать Angular JS элементы GUI? Я с трудом их нахожу через Inspect element. Прочитал кучу документации - в основном все тестирование GUI основано на HTML/CSS

погугли что такое Protractor

<button class="bc-keypad__key-button ng-binding" data-tm-fast-click="vm.setNumber(number)" angular-ripple="" aria-role="1"> 1 </button>

даже вот тебе статейка

https://habr.com/post/274413/

даже вот тебе статейка

Спасибо!

не за что )

Всем привет! Вопрос к коллегам автоматизации мобилок, интересует мнение, какой инструмент используйте для тестирования приложений под Андроид, гуглинг отвечает что эспрессо мастхэв, но интересуют альтернативы и подводные камни

Да больше нет ничего

Аппиум?

Ну вот да

Вы немного поздно пишете, все уже домой умотали но может тут могутппомочь @qa_automation

Алексей, процесс обучения продолжается)) Но затык произошел из-за Angular элементов. Вот, например, это скопированный код элемента "Кнопка 1" для ввода номера телефона <button class="bc-keypad__key-button ng-binding" data-tm-fast-click="vm.setNumber(number)" angular-ripple="" aria-role="1"> 1 </button> Это будет неправильно? driver.findelement(By.CssSelector("bc.keypad__key.button")).SendKeys("1");

Это будет неправильно)

?

Неплохо бы почитать тему CSS Selectors (а потом через денёк-другой и XPath). Это не так уж много, но без этих знаний шансов научиться писать ui тесты очень невелики

Чего я понять не могу, так это где находятся вакансии на автоматизацию под такие очень базовые знания. Или это все самообучение?

Неплохо бы почитать тему CSS Selectors (а потом через денёк-другой и XPath). Это не так уж много, но без этих знаний шансов научиться писать ui тесты очень невелики

Спасибо, Алексей!

Доброго времени суток. Ребята кто-то сдавал istqb на русском? Почему рекомендуют на английском?

На английском понятнее как-то.

This is the place — N 55.610563 E 37.547215. Get directions with Yandex.Navigator: https://30488.redirect.appmetrica.yandex.com/show_point_on_map?appmetrica_tracking_id=745803332332869252&lang=en&lat=55.610563&lon=37.547215

Доброго времени суток. Ребята кто-то сдавал istqb на русском? Почему рекомендуют на английском?

Не сдавала, но по опыту друзей вставлю 5 копеек: Если сдавать на русском, нужно переучить весь силабус на русском. Т.к. там есть неочевидные переводы, когда ты будешь думать, что это одно, а на самом деле переводчики подразумевали другое. Чаще всего в работе все пользуются терминами на английском, так зачем страдать и насильно учить русские?

https://github.com/vinogradoff/selenide-junit5-archetype Появилась возможно генерировать рыбу для проектов на Selenide + Maven + JUnit5 одной строкой (Maven Archetype) (edited)

Пример: mvn archetype:generate -B -DarchetypeGroupId=org.selenide -DarchetypeArtifactId=selenide-junit5-archetype -DgroupId=com.example -DartifactId=ui-tests

Спасибо

Ok