Дизайн тест-кейсов и ответственность тестировщиков, разработчиков, заказчиков
Похоже, что многие люди играют в игру по обвинению, где я работаю, и это поднимает интересный вопрос.
Knowns:
Команда требований пишет требования к продукту. Разработчики создают свои собственные модульные тесты в соответствии с требованиями. Команда тестирования создает Условия тестирования, Дизайн теста и Тестовые случаи в соответствии с требованиями.
Продукт выпущен в том и только в том случае, если пройдено X% тестов из команды тестирования.
После доставки клиент проходит приемочные тесты -> Группа реагирования клиентов получает ошибки с поля и сообщает группе тестирования об этих проблемах.
Вопрос:
Если клиент заканчивает подачей большого количества дефектов, кто виноват? Это команда тестирования, которая не освещает эти вопросы? Или это команда требований для того, чтобы не писать лучшие требования? И как можно улучшить систему?
4 ответа
Утверждение "Продукт выпущен тогда и только тогда, когда пройдено X% тестов из команды тестирования", действительно беспокоит меня. Команда, возможно, захочет рассмотреть вопрос о лучших критериях выпуска, основанных не только на показателях прохождения теста. Например, сценарии известны, поняты, учтены (и проверены)? Конечно, не все ошибки будут исправлены, но правильно ли были отложены те, которые были отложены или не исправлены? Вы достигли своих целей стресс-тестирования и производительности? Смоделировали ли вы угрозы и учитывали ли они потенциальные угрозы? Имеет ли x количество клиентов (внутренних / внешних) развернутых сборок и предоставивших обратную связь перед выпуском (то есть "собачья еда")? Понимают ли разработчики ошибки, возникающие в полевых условиях, и тестировщиков для создания модульных тестов регрессии? Понимает ли команда требований эти ошибки, чтобы понять, почему сценарии не были учтены? Существуют ли ключевые точки интеграции между функциями, которые не были учтены в спецификациях, разработке или тестировании?
Несколько предложений для группы: сначала сделать посмертный анализ по найденным проблемам, понять, где она возникла, и постараться максимально повысить качество восходящего потока. Убедитесь, что команда разработчиков требований, разработчики и тестировщики часто и хорошо общаются на протяжении всего цикла планирования, разработки и тестирования, чтобы все были на одной странице и знали, кто что делает. Вы будете удивлены, насколько качественно можно получить продукт, когда люди на самом деле общаются друг с другом во время разработки!
Ошибки могут попадать в систему как на требованиях, так и на этапах разработки. Команда по разработке требований могла допустить некоторые ошибки или чрезмерно упрощенные предположения при создании требований, а разработчики могли неправильно истолковать требования или сделать свои собственные предположения.
Чтобы улучшить ситуацию, заказчик должен подписать требования до начала разработки и должен быть вовлечен, по крайней мере, до некоторой степени, в мониторинг разработки, чтобы убедиться, что все идет в правильном направлении.
"Продукт выпущен в том и только в том случае, если пройдено Х% тестовых случаев от команды тестирования" - это один из критериев выпуска. В этом случае "Охват тестов" в письменных ТК очень важен. Требуется хороший пересмотр ТК независимо от того, пропущены ли какие-либо функции или сценарии. Если что-то пропущено в TC, может быть возможность найти ошибки, поскольку некоторые требования не рассматриваются в тестовых примерах.
Также требуется некоторое специальное тестирование, а также поисковое тестирование, чтобы найти обнаруженные ошибки в TC. И также необходимо определить "критерии выхода" для тестирования.
Если клиент / клиент обнаруживает какую-либо ошибку / дефект, необходимо изучить следующее: i) Какой тип ошибки обнаружен? II) Есть ли какой-либо тестовый сценарий, написанный по этому поводу? iii) Если есть тестовые сценарии (ы) относительно того, что выполнено должным образом? iv) Если он отсутствует в ТК, почему его пропустили? и так далее
После расследования может быть принято решение, кого следует обвинить. Если это очень простая и открытая ошибка / дефект, определенно следует обвинять тестировщиков.
Первый вопрос, на мой взгляд, будет: "Как дефекты складываются в соответствии с требованиями?"
Если требование гласит: "Кнопка ОК должна быть синего цвета", а дефект - "Кнопка ОК зеленого цвета", я буду винить разработку и тестирование - ясно, что ни один из них не прочитал требования. С другой стороны, если жалоба гласит: "Кнопка ОК не желтая", очевидно, возникла проблема со сбором требований или процессом контроля изменений.
Там нет простого ответа на этот вопрос. Система может иметь большое количество дефектов с распределением ответственности между всеми участниками процесса - в конце концов, "дефект" - это просто еще один способ сказать "неудовлетворенное ожидание клиента". Ожидания сами по себе не всегда верны.