Должны ли тестеры автоматизировать свою работу?

Мы пытаемся настроить наш процесс тестирования. Интересно, должны ли наши тестеры разрабатывать автоматизированные регрессионные тесты или разработчики должны это делать?

А как насчет других типов автоматизированных тестов? Должны ли тестеры разрабатывать их?

Я говорю, что тестировщики должны разработать автоматизированные тесты - у них подход к коду "пара глаз" и они будут (или должны быть просто "могут") обнаруживать ошибки, о которых вы даже не думали, не говоря уже о том, чтобы их обрабатывать. ,

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

Если вы можете автоматизировать это, автоматизируйте это.

Оставьте тестеров свободными, чтобы найти то, что вы не можете автоматизировать. И когда они обнаружат новую ошибку, если ее можно автоматизировать и добавить в автоматизированные тесты, добавьте ее.

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

При написании логики разработчик должен также писать модульные и интеграционные тесты. Это позволит разработчику убедиться, что написанное им до сих пор работает как задумано. Кроме того, эти тесты все еще будут доступны для разработки, когда они внесут будущие изменения. Когда логика завершена, разработчик может быть уверен, что написанное работает, поскольку оно понимает спецификации и может передаваться тестеру.

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

Учитывая, что разработчики часто слишком привязаны к коду, тестировщики должны быть в состоянии помочь очистить тесты разработчика, но не наоборот.

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

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

Отредактировано, чтобы добавить: я SDET с 5-летним опытом. Я работаю с отличными разработчиками с опытом работы более 10 лет каждый, и в последнее время работаю с ними, чтобы преодолеть узкое место тестирования.

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

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

Здесь действительно важно одно важное различие: ваши тестеры просто проверяют , или они тестируют ?

Этот пост в блоге Майкла Болтона объясняет это лучше, но по сути: они хотят просто подтвердить поведение или ищут проблемы с системой?

Я думаю, что также полезно рассмотреть квадранты Agile Testing (Брайан Марик первоначально описал их, но я встречал их в книге Лизы Криспин и Джанет Грегори «Agile Testing»: даже если вы не следуете методологии Agile-разработки, я думаю, что Различие между тестами, которые критикуют продукт, и тестами, которые поддерживают команду, действительно имеет смысл при рассмотрении вопросов автоматизации и попыток разработать план того, кто что делает и почему.

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

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

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