Должны ли разработчики, тестировщики и бизнес-пользователи иметь единый сценарий тестирования?

11

В процессе разработки у меня обычно были свои собственные тестовые сценарии, которые документировали бы данные, сценарии и этапы выполнения, которые я планирую протестировать; это мой план тестирования разработчика. Когда функциональность была развернута в Test, тестеры тестируют ее, используя собственный сценарий тестирования, который они написали. В UAT бизнес-пользователь затем проводит тестирование, используя свой собственный план тестирования.

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

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

Карлос Хайме К. Де Леон
источник

Ответы:

19

Во-первых, QA - это не тест. Если ваш отдел контроля качества не участвует во всем процессе разработки, это тест, а не контроль качества. QA, выполняя свою работу, обеспечивает гарантию качества, в лучшем случае Test показывает отсутствие качества, но не может доказать, что качество существует - т. Е. Test показывает, что QA провалился, но не может показать, что он преуспел, поэтому Test и QA не должны быть одним и тем же отделом.

Я полагаю, что лучший способ состоит в том, чтобы каждая группа управляла своими собственными тестами, поскольку это обеспечивает лучший охват. Однако каждая команда должна начать тестирование как можно скорее. Это означает, что UAT запускается, как только есть что-то, что пользователи могут использовать, тестирование запускается, как только часть, для которой у них есть тест, готова и т. Д. Это предотвращает позднее обнаружение отдельных тестовых случаев. Это может означать некоторую перенастройку ваших рабочих моделей, так как часто UAT и Test ожидают, что они будут работать над полным продуктом и нуждаются в обучении тестированию частично завершенных выходных данных. Это может быть дороже, если рабочий процесс не отменен, а разработчик "Завершить" означает Завершить.

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

Изменить: Исходная ссылка на вопрос QA была удалена, следовательно, этот ответ теперь появляется OT.

mattnz
источник
2
+1 - превосходный ответ. Действия, которые происходят во время различных типов тестирования, достаточно различны, так что один унифицированный скрипт не имеет смысла. Кроме того, разработчикам обычно требуется полностью автоматизированный тестовый сценарий, чтобы они могли быстро его запускать как в своих песочницах, так и на сервере CI; это не совсем соответствует тому, что люди QA и UAT захотят делать.
Дауд ибн Карим
«QA - это не тест». Я не могу проголосовать за это достаточно.
Бернхард Хофманн
2

Мы используем UAT с самого начала.

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

Выполнение UAT с самого начала также имеет дополнительное преимущество. Это действительно устраняет любую неопределенность между ожиданиями клиентов и вашими собственными.

Permas
источник
Когда вы говорите, что используете тестовый скрипт UAT с самого начала, значит ли это, что он должен исходить от бизнес-пользователя? Я имею в виду, что на этом этапе пользователь уже создал план тестирования на ранней стадии, и что этот план доступен разработчику для использования в рамках его тестирования dev?
Карлос Хайме К. Де Леон
@ CarlosJaimeC.DeLeon, да, это исходит от бизнес-пользователя. Мы находим, что это работает хорошо, потому что большинство клиентов, как правило, имеют смутное представление о том, что они хотят, и это помогает уточнить это, а также предоставляет руководство для разработчиков и тестеров. Кроме того, когда мы, как в UAT, они заявили, они больше понимают, когда мы спрашиваем время, хотят ли они изменений: P
Permas
1

Им не нужен унифицированный тестовый сценарий, поскольку тестируемые объекты и методы их выполнения часто должны различаться, и им нужно единое требование, над которым работают все стороны. Если UAT и QA тестируют то, о чем разработчик никогда не задумывался, то пришло время взглянуть на требования.

HLGEM
источник
1

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

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

k3b
источник
1

В идеальном мире разработчики должны иметь модульные тесты (xUnit), тестеры - автоматизированные интеграционные тесты (Selenium) и бизнес-пользователи - приемочные тесты (FIT). Они могут иметь доступ к тестам друг друга.

Николай Фоминых
источник
1

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

ASG
источник