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

9

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

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

Джадер Диас
источник
Просто начинайте называть их «разработчиками в тесте», и неоднозначность разрешается.
Эдвард Стрендж,
@Crazy Но не дороже ли иметь 2 команды разработчиков?
Джадер Диас
5
Дороже чем? Продавать плохо проверенный продукт? Узкое место в процессе разработки, потому что разработчики пишут тесты вместо продукта?
Эдвард Стрендж,

Ответы:

12

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

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

Джеймс Лав
источник
Но разве они не могли просто попросить разработчиков написать этот тест?
Джадер Диас
1
По причинам, которые я сказал выше, разработчики будут знать гораздо больше о внутренней реализации и будут подходить к программному обеспечению не так, как извне.
Джеймс Лав
Я не вижу, как реализация тестового примера может отличаться от одного человека к другому.
Джадер Диас
5
@Jader, вы хотите, чтобы разные люди писали автоматические тесты, а не исходный код. В противном случае тесты будут смещены для работы с кодом, как он был написан.
Марси
3
В последние пару недель у меня был разработчик, который помогал мне с написанием приспособлений для его кода. Он очень хороший разработчик, но он определенно пропускает некоторые нюансы освещения своего кода только потому, что не задумывается о глубоком освещении на регулярной основе. Если разработчики помогают с тестированием, попросите тестировщика проверить их работу.
Этель Эванс
11

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

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

CaffGeek
источник
Но почему они должны и не только разработчики?
Джадер Диас
@JaderDias, как уже упоминалось, у тестировщиков не должно быть предвзятых предубеждений относительно кода, который они пытаются протестировать
CaffGeek
3

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

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

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

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

Тейлор Прайс
источник
Вам интересно ваше последнее предложение - вы не думаете, что разработчики могут участвовать в функциональных тестах? Что, если тестировщики обрисовывают в общих чертах структуру теста и идентифицируют тестовые случаи, а разработчики только помогают в реализации?
Мисс Селлани
1
Я думаю, что представляю себе тестировщиков, которые сами по себе являются разработчиками и могут писать свои собственные тесты. Их работа будет состоять в том, чтобы пройти через требования и поговорить с пользователем, чтобы идентифицировать тестовые примеры, а затем написать их. Это позволяет разработчикам логики быть ближе к логике во время ее написания. Это также оставляет тестеров достаточно далеко от «владения» логикой, что они могут попытаться сломать ее объективно и без угрызений совести.
Тейлор Прайс
2

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

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

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

Этель Эванс
источник
0

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

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

glenatron
источник
Visual Studio 2010 (Premium или Ultimate, не могу вспомнить, в каком) есть что-то, что записывает действия на экране для автоматизации тестирования пользовательского интерфейса. Я видел демонстрацию этого Эндрю Вудворда, MVP, когда делал шоу UI Testing SharePoint, невероятные вещи.
Джеймс Лав
Запись и игра по праву имеет довольно плохую репутацию. Это имеет тенденцию быть довольно хрупким, и трудно поддерживать. Да, как быстрое и грязное «Я должен запустить это в 4 разных центрах обработки данных, я не хочу оставлять его для будущего использования», это хорошо, но поддерживать это ужасно, потому что вы в конечном итоге получаете множество повторений. Меняется один маленький элемент - и вдруг вам нужно обновить 100 тестов. Болезненные. Он также никоим образом не заменяет ручной тест, который, как правило, разработан с допущением, что человек заметит все те вещи, которые вы явно не проверяли.
testerab
То, что было бы довольно мило, было бы чем-то, что могло бы поднять вещи на несколько более низкий уровень, чем перемещение указателя и щелчок мышью, так что вы фактически записываете, какая кнопка была нажата, а не где произошел щелчок. Это сделало бы этот тип тестирования более устойчивым и практичным. Когда вам нужно запустить каждый скрипт, например, на девяти различных версиях окон, это кошмар, когда приходится делать это вручную на всех из них.
Гленатрон
Кнопка Идентификация по идентификатору , а не место это вполне возможно с некоторыми инструментами. Записывать и воспроизводить сценарии, выполненные подобным образом, К сожалению, ужасно сложно поддерживать - это не решает проблему повторения. Я не думаю, что есть какая-то необходимость избавиться от необходимости тщательно проектировать автоматизацию тестирования, если вы действительно хотите сохранить какие-либо сценарии или создать более дюжины из них. Задумывались ли вы об использовании чего-то, основанного на ключевых словах, как Robot Framework вместе с Auto-It?
testerab
0

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

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

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

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

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

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

testerab
источник