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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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