Search
Write a publication
Pull to refresh

Comments 13

На мой взгляд, разделение тестировщиков на автоматизиторов и ручных очень условное. Ручные тестировщики тоже пишут много "кода", только этот код выглядит как текстовые сценарии интерпретируемые человеком. При наличии навыков автоматизации, такие сценарии можно заменить реальным кодом; особенно удобно, если авто-тесты пишут в том числе и разработчики: это позволяет обучать тестировщиков навыкам рефакторинга, или как минимум поддерживать сценарии в актульном состоянии.

Покрытие - сложный вопрос. Лучше меньше покрывать и чаще запускать, чем покрывать всё и запускать только по праздниками или выборочно. Избыточное покрытие приводит к медлительности тестирования, которое приводит к желанию запускать меньше или выборочно, что, в свою очередь, сводит на нет пользу от полного покрытия.

Нельзя просто так сказать, нам в команду нужен крутой автоматизатор и в течение месяца он у вас появился.

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

Во-первых, тогда он должен досконально изучить наш сервис. Что не всегда возможно.

Высокая скорость разработки и короткие итерации позволяют фокусироваться на самых важных для бизнеса вещах. Разработка должна отговаривать тестирование впадать в крайности и тестировать всё, до чего руки дотянутся. Это всё из той же оперы, что и "проектирование наперёд" и "абстрактные фабрики абстрактых фабрик" в разработке: приводит только к увеличению стоимости изменений и рефакторинга, а ощущать "рефакторинг" как что-то болезненное нельзя ни в коем случае.

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

В конце концов, нужно больше общаться и меньше впадать в крайности.

Спасибо огромное за такой развернутый комментарий. Очень много холиварных вопросов затронуто. Последнее утверждение поддерживаю обеими руками.

«А прежде чем выкатывать, ты эту фичу протестировал»?

«Пользователи протестируют!»

(C)

Вакансия на ручное, а требуется автоматизация? Дело в том, что описание вакансии составляется с прицелом на будущее. То есть прямо сейчас, возможно и не требуется писать автоматизированные тесты, но в будущем есть большая вероятность, что такая необходимость появится.

Нужны тестировщики, которые умеют автоматизировать свою работу уже прямо сейчас, пользуетесь готовыми решениями. Там нет задачи автоматизировать все подряд. Чаще это какая-то рутина, связанная с прогоном стабильных регрессионных сценариев, которые они выполняют из раза в раз. Для тестирования Web приложений есть no-code/low-code инструменты, где достаточно понимать программирование буквально на уровне школьной программы.

Согласен на все сто. Глаза боятся, а руки делают.

Вы знакомы с успешным внедрением no-code в Веб automation, о котором вы говорите? Есть примеры?

Ручное тестирование не умрёт точно. А вот что касается курсов по нему, то тут надо хорошенечко подумать=)

Sign up to leave a comment.