Убираю копипасту и лишний код. Если браузер всегда один, зачем его всегда упоминать? Код выглядит (и что немаловажно, читается) намного лучше, если сравнить "до" и "после".
И не будет обновляться, при этом 4 версия больше про работу с Selenium Server, нежели с Selenium Webdriver. Если хочется чего-то действительно обновляемого, лучше посмотреть в сторону Playwright.
Я правильно понял, что в яндексе предлагают заплатить деньги за обучение, в то время как озон на своем route256 учит бесплатно и в случае хороших результатов предлагает трудоустройство в компанию?
Пока что непонятна цель существования этих курсов, кроме как получение денег яндексом.
Автотесты стали гораздо стабильнее, т.к. не завязаны на сервисы или моки, которые могут отваливаться в любой момент. (А этот любой момент обычно самый неподходящий)
Не могу понять, как тесты без моков могут стать стабильнее. Тем более, если отсечь бэк, то автотесты на фронт без моков невозможно сделать.
2 человека это прямо такое драматичное увеличение? Два в основном ради бас фактора. Или у вас двух людей не хватит чтобы тест кейсы писать и проверять за остальными то что они там нашли?
А остальных в команду включать не надо. Пусть только с тестированием и общаются.
Наем дополнительных ручных тестировщиков в ~20 команд — это довольно долгое и затратное мероприятие по уменьшению бас фактора. Быстрее, дешевле и выгоднее для компании вложиться в самотестирование задач разработчиками.
Проверять а точно ли в финальной сборке все подошло друг к другу как ожидалось и точно ли оно ведет себя так как ожидает пользователь тоже не дело разработчика.
Верно, интеграционное (финальное) тестирование лучше оставлять для QA.
Разработчик джейсон правильно переложил, а что там пользователю надо вообще пофиг. Интерфейс приложения разработчик может не открывать месяцами.
Для бэкенда — да, но нынешние приложения это не только бэкенд, есть ещё и фронтенд, который, внезапно, не выйдет сделать с закрытыми глазами.
Юнит тесты с покрытием под 100% нужны для тестирования сложных алгоритмов.
А также для подтверждения того, что бизнес-логика компонента работает корректно, несмотря на внесения изменений разными командами.
Прогноза нет, думаю нужно смотреть за метриками — количеством открытых багов, вызванных ошибками в реализации бизнес-логики из существующих требований (не багов, вызванными недоработкой требований).
Некоторая синхронизация с QA остается в моменте ревью чеклиста командой, этого должно хватать.
По поводу делать продукт быстрее — есть вопросы. Теперь у вас программисты сами тестируют свой код по тест кейсам, сколько на это уходит времени от времени разработки?
…
нет ли жалоб от программистов что им не особо нравится тест кейсы тыкать по 10 раз в день?
По тест-кейсам тестирования не появилось — ранее до передачи в тестирование, разработчики точно также проверяли свои задачи с каким-то набором входных данных. Расширилось количество наборов — стало больше юнит/интеграционных тестов. Времени к выполнению задачи это прибавило совсем немного, гораздо больше времени тратилось на фиксы после переоткрытия задачи и последующее написание этих же тестов.
Не бывает ли такого, что задача условная перекрасить кнопку (со временем разработки полчаса), а тестирование занимает полдня (проверить эту кнопку во всех случаях).
На это должны быть юнит-тесты, которые и проверят кнопку. Если это легаси и тестов нет, то это закладывается в оценку задачи.
Не вырос ли из-за нововведения ФОТ (программисты обычно получают в несколько раз больше чем ручные тестировщики, которые по тест кейсам работают)
Большую часть времени — да.
Какие-то взаимодействия теперь в основном на этапах ревью требований, декомпозиции проекта, ревью чеклиста командой и интеграционном тестировании.
Ручной тестировщик или точнее человек пишущий сценарии для ручных тестировщиков (их можно нанимать по пять копеек за пучок)…
Раздувание количества людей в команде не идет на пользу — рабочие встречи на большее количество участников начинают идти медленнее, появляются роли модераторов встреч.
Дешевле обучить разработчиков тестированию, нежели увеличивать бюрократию.
… это часто единственный человек на проекте знающий как на самом деле должны работать и взаимодействовать друг с другом все фичи. Со стороны пользователя.
Разработчики таким знанием как правило не обладают. Да и зачем оно нам?
Расширяет широту мысления, прокачивает разработчика — помимо навыков QA, будет более полная декомпозиция будущих проектов, более точные временные оценки задач. Разработчики пользуются спросом на рынке труда, чего не сказать о верстальщиках — можно посмотреть количество вакансий.
Джейсон переложен качественно. Интеграционные тесты написаны прилично и потверждают что джейсон переложен качественно, а все падения правильные и предусмотренные.
По опыту, когда тебе приходит ~3 пулл-реквеста в день, не сильно тратишь время, чтобы разобраться с покрытием тестами — для этого надо чуть-чуть, но погрузиться в бизнес-логику решаемой задачи (зачастую это из другой команды).
Анализатор в отчете показал покрытие кода близкое к 100%, и ладно, поэтому подтвердить полноту тестов никто не может, кроме автора пулл-реквеста.
Убираю копипасту и лишний код. Если браузер всегда один, зачем его всегда упоминать?
Код выглядит (и что немаловажно, читается) намного лучше, если сравнить "до" и "после".
https://peps.python.org/pep-0008/#package-and-module-names
Чуть ниже про классы, методы.
Код из статьи прекрасно работает на python 3.11.
И не будет обновляться, при этом 4 версия больше про работу с Selenium Server, нежели с Selenium Webdriver. Если хочется чего-то действительно обновляемого, лучше посмотреть в сторону Playwright.
Тут уже как душе угодно, всё возможно и доступно с получившейся архитектурой.
Есть какие-то легаси тесты и на python.
Я правильно понял, что в яндексе предлагают заплатить деньги за обучение, в то время как озон на своем route256 учит бесплатно и в случае хороших результатов предлагает трудоустройство в компанию?
Пока что непонятна цель существования этих курсов, кроме как получение денег яндексом.
Цель сделать QA из разработчиков не преследовалась, поэтому проблем никаких нет?
Верно, интеграционное (финальное) тестирование лучше оставлять для QA.
Для бэкенда — да, но нынешние приложения это не только бэкенд, есть ещё и фронтенд, который, внезапно, не выйдет сделать с закрытыми глазами.
А также для подтверждения того, что бизнес-логика компонента работает корректно, несмотря на внесения изменений разными командами.
1. Тестирование силами QA;
2. Тестирование силами разработчика, помогает QA;
3. Тестирование силами разработчика.
3 вариант является логичным развитием 2 варианта, потому что со временем разработчик реже обращается к QA для помощи с отдельными задачами.
Некоторая синхронизация с QA остается в моменте ревью чеклиста командой, этого должно хватать.
На это должны быть юнит-тесты, которые и проверят кнопку. Если это легаси и тестов нет, то это закладывается в оценку задачи.
Вырос, ответ есть в статье.
Какие-то взаимодействия теперь в основном на этапах ревью требований, декомпозиции проекта, ревью чеклиста командой и интеграционном тестировании.
Дешевле обучить разработчиков тестированию, нежели увеличивать бюрократию.
Расширяет широту мысления, прокачивает разработчика — помимо навыков QA, будет более полная декомпозиция будущих проектов, более точные временные оценки задач. Разработчики пользуются спросом на рынке труда, чего не сказать о верстальщиках — можно посмотреть количество вакансий.
По опыту, когда тебе приходит ~3 пулл-реквеста в день, не сильно тратишь время, чтобы разобраться с покрытием тестами — для этого надо чуть-чуть, но погрузиться в бизнес-логику решаемой задачи (зачастую это из другой команды).
Анализатор в отчете показал покрытие кода близкое к 100%, и ладно, поэтому подтвердить полноту тестов никто не может, кроме автора пулл-реквеста.