Comments 15
Поддержка автотестов занимает просто колоссальное количество времени
Позвольте предположить, что вы пишете хрупкие автотесты с дублированием кода.
Почему же ручные тестировщики не могут быть в полном объеме заменены автотестами?
По той же причине почему шуруповерт не вытеснил из продажи отвертки. У них разные задачи.
вряд ли заменят, но на дуде игрец требуется уже в двух вакансиях из трех, мануал а требования знания языка лови, и в тестовом задании автотест или скрипт напиши
Вы посмотрели на автотесты с позиции конкретно вашего проекта, вашей инфраструктуры.
Теперь берем другой момент. Крупное приложение, множество зависимостей, которые сложно уже описать. Изменение какой-либо мелочи может аукнуться в старых проверенных местах, надо все перетестить.
100 разработчиков, каждый делает хотя бы парочку коммитов в день, в идеале хочет хотя бы раз в день прогнать интеграционные тесты на своем пулл реквесте, а то и на двух-трех-пяти.
Сколько нужно ручных тестировщиков, чтобы прогнать все тесты для 100 разработчиков в день?
А ПРАВИЛЬНО сделанные автотесты могут это делать без проблем.
Да, их надо поддерживать. Да, для прогона автотестов нужны ресурсы и время. И грамотно все это настроить для минимизации и ресурсов и времени.
Нужно четко понимать, что автотесты - это не автоматически прогнанные ручные тесты. Нужно и архитектуру ПО иногда подправить для упрощения автотестирования, и инфраструктуру, и сам подход к тестированию. И разграничить что проходится автотестами, что остается на ручное тестирование.
Уже отсюда и исходить как и где покрывать, как их писать.
В принципе именно поэтому и считется, что писать автотесты (то есть генерировать идею что покрывать, как оно будет работать) - должен опытный человек, который создает правильный подход.
А поддерживать, подправляя мелочи, удаляя ненужные - может в принципе и джун, особенно если есть с кем посоветоваться.
Вы сейчас все автотесты в одну кучу свалили, а они бывают разные и у них разные задачи.
Есть такое понятие как пирамида тестирования - больше всего должно быть unit-тестов (в идеале на каждый метод/функцию кода), потом идут интеграционные тесты о которых говорите вы (в идеале на каждый вызов API) и уже потом идут GUI автотесты, про которые говорит автор. Именно они наиболее нестабильны и подвержены случайным падениям, а тестовые фреймворки сами изобилуют багами.
В современном же мире идёт тенденция не на «пирамиду», а на «мороженку», когда все пытаются покрыть GUI автотестами, но забывают про интеграционные и unit тесты.
За час рабочего времени могут дернуть все — ПМ, разработчик, аналитик и прочие
Возможно, проблема обретается где-то здесь, а автотесты не виноваты. Но это не точно.
Будет не лишним упомянуть "проблему оракулов". Если кратко, ее суть в том, что в тестах тоже бывают ошибки, и абсолютно корректный тест может быть сложнее тестируемого кода. Перефразируя древнеримское изречение, кто будет тестировать сами тесты?
Написать автотест гораздо проще и быстрее, чем искать неточность в уже написанном
Смотря, как написаны автотесты. Если по коду теста сложно понять, что пошло не так, то следует «посмотреть в глаза» автору такого автотеста.
Переключаться с автотестов на другие задачи приходилось очень часто. За час рабочего времени могут дернуть все — ПМ, разработчик, аналитик и прочие. После консультаций приходилось заново вливаться в разработку автотеста, что так же крадет ценное время.
Позволить отвлекать себя может только Senior, который может легко переключаться между контекстами. В любом случае — это не проблема автотестов.
автотест способен проверить только конкретные значения
Почему вы так решили? Автотест может проверить все возможные значения, заданные или случайные. Ровно также себя ведёт и ручной тестировщик.
Почему же ручные тестировщики не могут быть в полном объеме заменены автотестами?
По одной простой причине. Это разные сущности. Суть автоматизатора автоматизировать регулярно воспроизводимый сценарий. Ручной тестировщик при этом должен уметь исследовать причину появления ошибок / падения приложения.
Автотест делает POST /users. Ожидает 200, получает 500. Его задача отрапортовать об этом и не более того.
Когда у ручного тестировщика получается поймать пятисотую, то он должен пройтись по всем логам, посмотреть в код, если умеет, найти и понять причину ошибку, предложить варианты её исправления и завести задачу в Jira.
Он (или она) в свою очередь правят автотест или подписывают его ошибкой
А какое ПО для этого используете? Что у вас за отчеты, которые линкуются с ошибками?
Мне кажется, тут ключевая проблема в некорректном менеджменте: а давайте уберем автоматизатора, а ручных тестировщиков оставим как есть, по сути - нагрузим работу автоматизатора на тестера не увеличивая количество тестеров. Гениальная идея, денег сэкономим.
То что смена контекста сжирает до 70% продуктивности - это мелочи.
Добавили бы в команду джуна сперва, разгрузив мануала, потом жестко зафиксировали время на автоматизацию - вот с 10 до 12 ты занимаешься только автотестами, а потом только ручными вопросами может бы и взлетело.
"Скорость написания самих автотестов оставляла желать лучшего. Круг замкнулся — Из-за поддержки автотестов не хватало времени на прямые обязанности"
Не хватило скилла. Бывает. Train hard - go pro. No pain - no gain. Пилякать автоматизацию ради автоматизации вообще тупая идея. Автотесты - это такой же инструмент тестировщика как постман или джира. Просто инструменты использовать надо по назначению и по инструкции. Можно ли топором копать яму? - можно. Можно ли лопатой рубить деревья? Можно. Можно даже научится очень круто рубить лопатой, но может все-таки посмотреть что и в какой ситуации удобнее?
"ручных" тестировщиков не существует, и делить инженеров на тех кто использует автоматизацию или нет весьма глупая затея.
Называть "ручными" - в целом пренебрежительно, и это какое-то клеймо, ограничение, придуманное руководством компании.
Заменят ли автоматизаторы ручных тестировщиков