При написании статьи использовались материалы А.Смирновой, подготовленные в рамках конференции тестировщиков «Котэ»
Тестирование – очень динамичная сфера, которая постоянно развивается; каждый день появляются новые инструменты, материалы и подходы. Тестировщик – это «универсальный солдат», зачастую объединяющий в себе различные навыки: написание кода, управление ресурсами, владение основами дизайна и верстки, а также знания в более узких прикладных областях. Руководители проектных команд стараются повышать квалификацию своих ребят, отправляя их на всевозможные курсы и тренинги. Но как быть со стажерами, с «проектными новобранцами»? Как правильно, а главное, чему именно нужно научить стажеров (особенно в распределенной команде), чтобы у них не пропал интерес к профессии, и чтобы это обучение принесло пользу не только «новобранцу», но и всему проекту? Об этом мы и расскажем в нашей статье.
В компанию требуется грамотный QA-инженер. Спектр задач весьма широк - работа будет разнообразной. Кроме непосредственно тестирования мы ожидаем от человека на этой позиции рекомендаций по улучшению UI/UX, т.е. есть возможность непосредственно влиять на выпускаемые продукты
Что нужно делать:
Выполнение функционального тестирования
Анализ технических заданий и требований
Анализ результатов тестирования и принятие
решения о запуске в релиз
Коммуникации с разработчиками
Понимание сути обеспечения качества
Навыки написания тест-кейсов и тест-планов
Участия в проекте на всех стадиях
Что нужно уметь:
Опыт тестирования веб-сайтов: функционал, верстка,
кроссбраузерность
Понимание процесса разработки веб-сайтов
Опыт работы с системами баг-трекинга
Желательно - Опыт использования средств автоматизированного
тестирования веб приложений или желание изучить
Желательно: Умение пользоваться инструментами web-разработчика: работа с cookie,
cache, proxy, анализ сетевого трафика, html валидаторы.
Что предлагаем:
Адекватное начальство, мы сами IT-шники и понимаем, что для нас важно
Достаточно гибкий график
Все условия для роста и развития вместе с компанией
Добрый день, форумчане. Излагаю суть проблемы в надежде получить помощь.
Собственно, не будучи профессионалом я слепил такую архитектуру для прогона автотестов:
на unis-виртуалке вращается docker , в контейнерах которого поднят официальный образ Jenkins и selenium/standalone-chrome:3.8.1-aluminum, связанные между собой (Jenkins стартует тесты, адресует их в контейнер selenium'a, где их прогоняет chromedriver)
Тесты написаны на PHP с помощью Codeception. Файлы с тестами хранятся в проекте, но не для всех из них созданы item'ы в Jenkins'e.
Теперь о проблеме:
я стал замечать, что на selenium server'e появляются сессии тестов, которые не были вызваны Jenkins'ом. Тесты запускаются самые разные, даже те, для которых нет item'a в jenkins'e.
Чтобы решить проблему, я решил понять почему это происходит. И первое, что мне пришло в голову, это посмотреть логи selenium server'a.
И тут возникает другая проблема - я не знаю как в docker-compose.yml файле прописать enviroment , чтобы selenium генерировал лог-файл и не знаю как указать путь к месту хранения лог-файла.
Запуская сервер через консоль я бы дописал в конце -log /home/directory/selenium_server_log , но как это сделать в случае с docker-compose.yml - я не знаю. Возможно, есть какой-то конфиг selenium server'a, в котором всё это указывается - мне не известно.
Подозреваю, что примерно так, поправьте, если ошибаюсь:
Если убрать комментарий с Thread.sleep то все работает. Но sleep как известно - зло. Подскажите пожалуйста что не так с использованием elementToBeClickable. И как сделать нормальное ожидание в данной ситуации?
Друзья, всем привет, я новичок, и на форуме и в QA, пытаюсь освоить Automation Testing,учусь по видео в ютуб. Сделала все один в один как на видео, но почемуто мой код выдает ошибки, и не запускается главная страница Google. Подскажите пожалуйста, как их исправить?