На работе у нас довольно сложная система. Давайте назовем эту систему System_A. Наша команда QA создала другую систему, назвав эту систему System_B, чтобы протестировать System_A.
Способ использования System_B заключается в следующем. Мы генерируем входные данные (используя саму System_B), IN, обрабатываем такие входные данные обратно через System_B и генерируем выходные данные, O_B. Итак, процесс выглядит следующим образом:
System_B(IN) -> O_B
,
Затем мы делаем то же самое для System_A, чтобы генерировать свои собственные выходные данные, O_A:
System_A(IN) -> O_A
,
В любое время предполагается, что O_B является ожидаемым выходным сигналом, а O_A является наблюдаемым / фактическим выходным сигналом. Подразумевается, что O_B является «золотым» источником (правда). Однако мы столкнулись с рядом проблем.
- О_А не прав, О_Б прав
- О_А прав, О_Б прав
- О_А не так, О_Б не так
- О_А прав, О_Б не прав
Кто определяет, что правильно, если предполагается, что O_B всегда прав (или что ожидается)? Что ж, получается, что O_B иногда (или часто) не прав с человеческим осмотром и анализом. Вещи пройдут QA, используя этот процесс, и реальные пользователи будут жаловаться, и мы вернемся к тому, что O_B все-таки был неправ.
Вопрос в следующем: является ли плохой практикой создание «тестовой системы» для тестирования реальной системы?
- Как насчет скользкого склона? Тогда разве мы не можем утверждать, что нам нужна еще одна система для тестирования «тестовой системы»?
- Стоимость определенно непомерно высока, поскольку разработчикам теперь нужно изучить как минимум 2 базы кода, возможно, сложность System_B больше, чем System_A. Как мы можем количественно оценить, насколько хорошо или плохо иметь System_B для организации?
- Одной из первоначальных «убедительных» причин создания System_B была «автоматизация» тестирования. Теперь мы очень гордимся тем, что мы полностью автоматизированы (потому что System_B генерирует входные данные для начальной загрузки процесса использования себя для генерации выходных данных). Но я думаю, что мы причинили больше вреда и усложнили, не поддающимся количественной оценке. Является ли работа по обеспечению качества полностью автоматизированной? Достаточно ли этой причины для создания параллельной системы?
- Я действительно обеспокоен этим, хотя мы все знаем, что System_B неверна (довольно часто). Если System_B так хорошо обрабатывает входные данные, а их вывод является источником золота, почему бы не заменить System_A на System_B? На это никто на работе не способен дать удовлетворительный ответ.
Любое руководство по этому вопросу приветствуется.