Pull to refresh

Comments 15

По-моему в тестировании достаточно следовать всего одному принципу — "Все, что может быть автоматизировано, должно быть автоматизировано"… тогда и другие подходы придумывать не придется… некогда будет.


Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.

Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.


Тестирование это чуть сложнее, чем клики. Всё еще не автоматизируется «думать» и «оценка рисков». Плохо поддается автоматизации стандартная проблема тестовых фреймворков — эффективность тестового набора.

Проектов по тотальной автоматизации с не отрицательным ROI всё еще меньше, чем один на десять.

Я допускаю, что «тотальная» автоматизация возможна в заказной разработке, где клиенту продаются часы, а не качество, но если вы автоматизируете тестирование своего продукта за свои деньги, то заявления будут намного менее безапелляционными.

"Думать" да, не автоматизируется, а "оценка рисков" автоматизируется вполне успешно сплошь и рядом.


Где вы увидели у меня призыв к немедленной тотальной автоматизации? Я написал "ВСЕ, что МОЖЕТ быть автоматизировано".


Насчет сопоставления стоимости ручного и автоматизированного тестирования я не понял. Вы предполагаете что автоматизированный сценарий тестирования интерфейса, написанный с использованием какого-нибудь Selenium-а, будет в долгосрочной перспективе в эксплуатации обходиться дороже, нежели ручной тестировщик?

Я не предполагаю, я точно знаю, что в 4 случаях из 5 автоматизированный сценарий дороже, чем ручной тестировщик. Потому как к этому сценарию прилагается «автоматизатор», который, как правило, умеет писать сценарии, а пользу — не умеет.

Какой такой "автоматизатор"? Я как разработчик пишу сначала тесты, потом код. Когда начинается проект, я настраиваю новое задание в CI сервисе (Jenkins), которое загружает мой код из GIT репозитория после каждого его обновления, и автоматически собирает приложение, запускает тесты, загружает данные и снова запускает тесты. При этом мне не нужен никакой специальный дополнительный автоматизатор. Один раз настроил и оно работает. Один раз написал тест, и он при каждом прогоне будет гарантированно выполняться и проверять продолжает ли приложение работать как ожидается.


Когда мы обнаруживаем какой-то новый сценарий использования приложения, для которого у нас еще нет теста, мы просто добавляем новый тест к существующим наборам.


У меня сейчас в бэкенде, в проекте, который стартовал два месяца назад, только модульных тестов 1100. Больше сотни тестов REST API, которые ежедневно выполняются по нескольку десятков раз. Какая тут мне может быть польза от ручного тестировщика?


Когда я занимался фронтендами, у меня в небольшом относительно проекте было порядка 50 e2e сценариев (Selenium), которые проверяли основную функциональность SPA Web приложения. При разработке, в течение дня я иногда запускал эти сценарии по нескольку десятков раз. Если бы я делал это руками, у меня бы дня рабочего не хватало чтобы только тесты прогнать. Вы правда думаете что ручной тестировщик сможет адекватно протестировать 50 сценариев, 10 раз за день?

Какая тут мне может быть польза от ручного тестировщика?


Для тестирования апи, как правило, выделенный тестер не нужен. Но область знаний того самого «ручного» тестировщика помогла бы тратить меньше времени на тесты бесполезные и больше — на полезные.

Для такого небольшого приложения, где можно быстро написать 50 e2e кейсов и запускать их настолько регулярно в режиме отладки тестировщик мог бы спросить, а нужны ли тесты вообще…

Кстати, на текущем уровне развития автоматизации 50 тестов через браузер вручную прогнать быстрее живым человеком.

Вы поменяли предмет спора. Я не говорил, что автоматизация не нужна. Я говорил, что сейчас закодированные тесты тестирование заменить не способны в большинстве случаев.
Кстати, на текущем уровне развития автоматизации 50 тестов через браузер вручную прогнать быстрее живым человеком.

Вы это серьезно? Продемонстрировать можете? У меня вот есть видео с куском из 22-ух e2e тестов, выполняемых на почти старинном ноутбуке, записанное год назад. Selenium год назад делал это за 34 секунды. Можете показать что-нибудь подобное, что делает ручной тестировщик быстрее?

Легко.
*Видео, где я 20 секунд смотрю дифф кода, потом прогоняю руками 1 кейс, который действительно нужно прогнать*

Я не собираюсь соревноваться с машиной в том, в чем она явно лучше.

Еще раз, в чем предмет спора?

Вы считаете, что автоматизировать уже можно всё? Как долго вы будете писать скриншотные тесты, которые не пропустят все ошибки верстки, которые пропустит тест с видео? Еще примеров того, что автоматизировать нельзя? Сколько человеко-тысячелетий потрачено на код, который разработчики писали, забыв спросить «а зачем?»…

Ошибки верстки для проектов, в которых я принимал участие, составляли не более 3% от общего объема проблем. Причем часть из них отлично обнаруживается в процессе функционального тестирования тем же Selenium-ом (наложение-перекрытие элементов управления). Ну а "Pixel Perfect" для меня неактуален. Я в таких проектах участия не принимаю

Тем не менее позволяете себе заявления:
Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.


Я бы согласился с «нужно пытаться» или «стоит прикладывать усилия». Но «уже можно».

Поэтому я и написал "уже наверное можно", а не "уже точно можно". Я считаю что в задачах, которые относительно недорого формализуются нет смысла полагаться на ручной труд. Это заведомо проигрышная стратегия.

Почему-то всё еще бытует заблуждение, что автотесты находят баги. Хотя на самом деле автотесты находят небаги.
Баги только люди могут найти.

Тесты, не для того, чтобы находить ошибки, а для того, чтобы быть уверенным в том, что код ведет себя так, как предполагается. Особенно это актуально в случаях, когда требования заказчика часто меняются, и код приходится дорабатывать и рефакторить.


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

Ну, зачем нужна автомагическая регрессия знают уже почти все. И continuous testing тоже уже худо-бедно приживается.

Но расследовать все равно же руками приходится. Ибо павший тест не обязательно может быть багом. Test fragility тоже никто не отменял.
Sign up to leave a comment.