Привет, это Эрик Бурыгин, я техлид курса «Автоматизатор тестирования на Java» в Яндекс.Практикуме и лид в Яндексе. Каждый ручной тестировщик считает, что автоматизация — это круто и её непременно нужно втащить в проект. Что может быть лучше, чем полное покрытие автотестами продукта, когда тесты гоняются 24/7 и отлавливают баги? Вот прочитал я эти строки, и захотелось ещё раз всё заавтоматизировать!



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

Привет! Есть старый холивар на тему, кто же должен писать тесты: разработчики или тестировщики. Вроде как если в команде есть тестировщики, то логично, что тесты пишут они, правда? С другой стороны, ребята из разработки (помимо самой разработки) точно знают, как работает их код и как будет вести себя в тех или иных ситуациях. Как минимум предполагают.

Дисклеймер: меня зовут Эрик Бурыгин, я давно работаю тестировщиком, веду студентов на курсе «Инженер по тестированию», поэтому может показаться, что тестировщик просто хочет перекинуть кусок работы на разработчиков. На самом деле у описываемого подхода есть как плюсы, так и минусы, поэтому статья носит в том числе и дискуссионный характер. Буду рад увидеть в комментах мнения как разработчиков, так и тестировщиков.

Если тесты пишет разработка, можно решить сразу несколько проблем, например:

• Ощутимо ускорить релизный цикл.
• Снять нагрузку с тестирования.

В большинстве команд процесс выглядит примерно так:

1. Разработчик создаёт новые фичи и допиливает существующие.
2. Тестировщик всё это тестирует и пишет различные тест-кейсы.
3. Автоматизатор, оправдывая название должности, автоматизирует всё по написанным тест-кейсам из п.2.

Вроде бы всё выглядит просто.

Но в этой парадигме есть слабые места.