Тестовый корпус Дизайн и ответственность тестировщиков, разработчиков, заказчиков

Question

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

Knowns:

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

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

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

Вопрос:

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

Answer 1

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

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

Answer 2

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

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

Answer 3

Первый вопрос, на мой взгляд, будет: «Как дефекты складываются против требований?»

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

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

Answer 4

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

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

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

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