Разработка тестового примера и ответственность тестировщиков, разработчиков, Заказчиков [закрыто]

Question

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

Известные:

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

Продукт выпущен тогда и только тогда, когда пройдет X% тестовых случаев от команды тестирования.

После доставки клиент проводит приемочные тесты -> Команда реагирования на запросы клиентов получает ошибки с места и сообщает команде тестирования об этих проблемах.

Вопрос:

Если клиент в конечном итоге заявляет о множестве дефектов, кто виноват?Это из-за того, что команда тестирования не освещает их?Или это команда по разработке требований за то, что она не написала лучшие требования?И как можно улучшить эту систему?

Answer 1

Утверждение "Продукт выпущен тогда и только тогда, когда пройдет X% тестовых заданий от команды тестирования" действительно беспокоит меня.Команда, возможно, захочет рассмотреть возможность использования лучших критериев выпуска, которые зависят не только от количества пройденных тестов.Например, известны ли, поняты ли, учтены (и протестированы) сценарии?Конечно, не все ошибки будут исправлены, но правильно ли были отсортированы те из них, которые были отложены или не исправлены?Достигли ли вы своих целей в области стресс-тестирования и производительности?Смоделировали ли вы угрозу и учли ли меры по смягчению последствий потенциальных угроз?Иметь x количество клиентов (внутренних / внешних), развернувших сборки и предоставивших отзывы до выпуска (т.е."корм для собак")?Понимают ли разработчики ошибки, возникающие на местах, и тестировщики, создающие регрессионные модульные тесты?Понимает ли команда по разработке требований эти возникающие ошибки, чтобы понять, почему сценарии не были учтены?Существуют ли ключевые точки интеграции между функциями, которые не были учтены в спецификациях, разработке или тестировании?

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

Answer 2

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

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

Answer 3

Первым вопросом, который приходит мне в голову, был бы: "как дефекты соотносятся с требованиями?"

Если требование гласит: "Кнопка OK должна быть синей", а дефект - "Кнопка OK зеленого цвета", я бы обвинил разработку и тестирование - очевидно, что ни те, ни другие не читали требований.С другой стороны, если жалоба звучит так: "Кнопка OK не желтая", очевидно, возникла проблема со сбором требований или вашим процессом контроля изменений.

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

Answer 4

"Продукт выпущен тогда и только тогда, когда пройдет X% тестовых случаев от команды тестирования" - это один из критериев для выпуска.В этом случае "Охват тестов" в письменных TCs очень важен.Необходим хороший обзор TCs на предмет того, упущена ли какая-либо функциональность или сценарий или нет.Если что-то упущено в TCs, может возникнуть возможность обнаружить ошибки, поскольку некоторые требования не охвачены в тестовых примерах.

Он также нуждается в некотором специальном тестировании, а также в ознакомительном тестировании, чтобы обнаружить ошибки в TCs.И ему также необходимо определить "Критерии выхода" для тестирования.

Если клиент обнаруживает какую-либо ошибку/дефект, необходимо провести расследование, поскольку:i) Какой тип обнаруженной ошибки?ii) Есть ли какой-либо тестовый пример, написанный по этому поводу?iii) Есть ли тестовый пример (ы), касающийся того, что выполнено должным образом?iv) Если оно отсутствует в TCs, почему оно было пропущено?и так далее

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