Убираю копипасту и лишний код. Если браузер всегда один, зачем его всегда упоминать? Код выглядит (и что немаловажно, читается) намного лучше, если сравнить "до" и "после".
И не будет обновляться, при этом 4 версия больше про работу с Selenium Server, нежели с Selenium Webdriver. Если хочется чего-то действительно обновляемого, лучше посмотреть в сторону Playwright.
Я правильно понял, что в яндексе предлагают заплатить деньги за обучение, в то время как озон на своем route256 учит бесплатно и в случае хороших результатов предлагает трудоустройство в компанию?
Пока что непонятна цель существования этих курсов, кроме как получение денег яндексом.
Важно. К сожалению ,автоматического удаления бэкапов с s3 мне еще не удалось настроить, пока приходится вручную. Но если дадите совет, буду благодарен.
Автотесты стали гораздо стабильнее, т.к. не завязаны на сервисы или моки, которые могут отваливаться в любой момент. (А этот любой момент обычно самый неподходящий)
Не могу понять, как тесты без моков могут стать стабильнее. Тем более, если отсечь бэк, то автотесты на фронт без моков невозможно сделать.
2 человека это прямо такое драматичное увеличение? Два в основном ради бас фактора. Или у вас двух людей не хватит чтобы тест кейсы писать и проверять за остальными то что они там нашли?
А остальных в команду включать не надо. Пусть только с тестированием и общаются.
Наем дополнительных ручных тестировщиков в ~20 команд — это довольно долгое и затратное мероприятие по уменьшению бас фактора. Быстрее, дешевле и выгоднее для компании вложиться в самотестирование задач разработчиками.
Проверять а точно ли в финальной сборке все подошло друг к другу как ожидалось и точно ли оно ведет себя так как ожидает пользователь тоже не дело разработчика.
Верно, интеграционное (финальное) тестирование лучше оставлять для QA.
Разработчик джейсон правильно переложил, а что там пользователю надо вообще пофиг. Интерфейс приложения разработчик может не открывать месяцами.
Для бэкенда — да, но нынешние приложения это не только бэкенд, есть ещё и фронтенд, который, внезапно, не выйдет сделать с закрытыми глазами.
Юнит тесты с покрытием под 100% нужны для тестирования сложных алгоритмов.
А также для подтверждения того, что бизнес-логика компонента работает корректно, несмотря на внесения изменений разными командами.
Прогноза нет, думаю нужно смотреть за метриками — количеством открытых багов, вызванных ошибками в реализации бизнес-логики из существующих требований (не багов, вызванными недоработкой требований).
Некоторая синхронизация с QA остается в моменте ревью чеклиста командой, этого должно хватать.
По поводу делать продукт быстрее — есть вопросы. Теперь у вас программисты сами тестируют свой код по тест кейсам, сколько на это уходит времени от времени разработки?
…
нет ли жалоб от программистов что им не особо нравится тест кейсы тыкать по 10 раз в день?
По тест-кейсам тестирования не появилось — ранее до передачи в тестирование, разработчики точно также проверяли свои задачи с каким-то набором входных данных. Расширилось количество наборов — стало больше юнит/интеграционных тестов. Времени к выполнению задачи это прибавило совсем немного, гораздо больше времени тратилось на фиксы после переоткрытия задачи и последующее написание этих же тестов.
Не бывает ли такого, что задача условная перекрасить кнопку (со временем разработки полчаса), а тестирование занимает полдня (проверить эту кнопку во всех случаях).
На это должны быть юнит-тесты, которые и проверят кнопку. Если это легаси и тестов нет, то это закладывается в оценку задачи.
Не вырос ли из-за нововведения ФОТ (программисты обычно получают в несколько раз больше чем ручные тестировщики, которые по тест кейсам работают)
В статье не увидел, спрашиваю в комментах — почему используется не образ minio, а некий bitnami/minio, который к minio не имеет отношения?
Структура "статьи":
- реклама
- Юлия Якубеня поменяла работу
- реклама
Осталось добавить следующие пункты (из заголовка, хабов и тегов):
- ios разработку
- опыт и адаптацию
Для развития можно посмотреть, как публикуют материалы о подкастах другие люди (пишут транскрипцию, а не пять раз кидают ссылку на запись).
В заголовке сказано про стабильность, в тексте ни слова о стабильности.
del
Переписал на Playwright — https://github.com/giant-whale/playwright-python-framework
Открыл случайный тест — https://github.com/yashaka/selene/blob/master/examples/run_cross_platform/tests/acceptance_test.py
Нет, по удобству даже не близко к тому что описано в статье — с таким "фреймворком" не удастся посадить manual qa писать тесты.
А потом прокидывать его в параметры везде, где есть обращение к драйверу. Параметр ради параметра.
Не один раз в начале теста, а один раз в начале каждого теста. Зачем?
Selenium 4.* — это про работу с Selenium Grid, который во всём хуже, чем Selenoid
Не понял вопроса. Все операции проводятся с webelement DOM-дерева, пока он жив в дереве, зачем его еще раз искать?
Сделать нормальное ожидание никто не запрещает. Здесь статья про архитектуру, не про ожидание.
Рекомендую к прочтению документацию к Allure — https://allurereport.org/docs/pytest/
Скриншоты легко прикручиваются на teardown, достаточно проверить статус теста, и в случае падения делать скриншот.
Убираю копипасту и лишний код. Если браузер всегда один, зачем его всегда упоминать?
Код выглядит (и что немаловажно, читается) намного лучше, если сравнить "до" и "после".
https://peps.python.org/pep-0008/#package-and-module-names
Чуть ниже про классы, методы.
Код из статьи прекрасно работает на python 3.11.
И не будет обновляться, при этом 4 версия больше про работу с Selenium Server, нежели с Selenium Webdriver. Если хочется чего-то действительно обновляемого, лучше посмотреть в сторону Playwright.
Тут уже как душе угодно, всё возможно и доступно с получившейся архитектурой.
Есть какие-то легаси тесты и на python.
Я правильно понял, что в яндексе предлагают заплатить деньги за обучение, в то время как озон на своем route256 учит бесплатно и в случае хороших результатов предлагает трудоустройство в компанию?
Пока что непонятна цель существования этих курсов, кроме как получение денег яндексом.
Поскольку бакеты у вас не создаются автоматически, то можно один раз руками настроить lifecycle для каждого бакета — Managing your storage lifecycle - Amazon Simple Storage Service
Цель сделать QA из разработчиков не преследовалась, поэтому проблем никаких нет?
Верно, интеграционное (финальное) тестирование лучше оставлять для QA.
Для бэкенда — да, но нынешние приложения это не только бэкенд, есть ещё и фронтенд, который, внезапно, не выйдет сделать с закрытыми глазами.
А также для подтверждения того, что бизнес-логика компонента работает корректно, несмотря на внесения изменений разными командами.
1. Тестирование силами QA;
2. Тестирование силами разработчика, помогает QA;
3. Тестирование силами разработчика.
3 вариант является логичным развитием 2 варианта, потому что со временем разработчик реже обращается к QA для помощи с отдельными задачами.
Некоторая синхронизация с QA остается в моменте ревью чеклиста командой, этого должно хватать.
На это должны быть юнит-тесты, которые и проверят кнопку. Если это легаси и тестов нет, то это закладывается в оценку задачи.
Вырос, ответ есть в статье.