На работе у нас довольно сложная система. Давайте назовем эту систему 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? На это никто на работе не способен дать удовлетворительный ответ.
Любое руководство по этому вопросу приветствуется.
Ответы:
Исправить A
Исправить B
Надеюсь, они тоже согласны.
Надеюсь, они не согласны, так что вы будете знать, что-то с этим делать.
Ни один процесс не ловит все. Конечно, вы удвоили свой код, но воспринимайте его как 2 в O (2n). Автоматизированный контроль качества вплоть до интеграционных тестов - замечательная вещь. Ручное тестирование - это затягивание инноваций. Особенно на сквозные изменения, которые потребуют полного тестирования. Кроме того, так как разные программисты будут реализовывать одно и то же, вы можете заставить их участвовать в гонке.
Это должны быть разные люди, чтобы увеличить шансы получения разных ошибок. Я не советую создавать систему B, справляясь с системой A. Все, что вам дает, это тест регрессии. Вы можете получить то же самое, просто сохранив старые копии O_A для сравнения с новыми.
Если это так, то все тесты плохие.
Да, мы можем утверждать это. Мы назовем эту 3-ю систему system_A. :П
По количеству счастливых клиентов, которые платят нам, чтобы играть с нерф пистолетами. Вы освободили себя от стоимости ручного тестирования. Вы создали что-то, чья полезность будет доказываться каждый раз, когда обнаруживается ошибка. Ранние ошибки обнаруживаются гораздо дешевле, чем сообщалось ранее.
Сложность System_B прекрасно изолирована от System_A. Нет ничего сложнее добавить функции в System_A, потому что System_B существует. Это проще, потому что System_B дает им уверенность, чтобы идти быстро.
Это опечатка? System_B довольно часто ошибается, так что это золотой стандарт, который вы хотите использовать для замены System_A?
Я предполагаю, что вы имели в виду, что System_A часто ошибается. Неважно, какой из них ошибается чаще всего. Кто бы ни был неправ, тот, кто нуждается в работе. Эти системы не принимают правильных и неправильных решений, как разработчики. Тестирование вызывает разногласия, которые означают, что что-то не так. Разработчики выясняют, что это такое. Помните, что здесь не производится золотой стандарт. Есть только согласие или несогласие. Разногласия требуют, чтобы работа была выполнена. Часть этой работы выясняет, где.
источник
Если у вас есть производственная система, которая фактически используется клиентами, наличие системы QA для проверки исправлений ошибок и новых функций абсолютно необходимо. С точки зрения качества, она должна быть как можно точнее точной копией производственной системы. Таким образом, если вы убедитесь, что производственная система и ее система обеспечения качества идентичны, то, что работает на одном, должно работать на другом. Если это не так, то системы не идентичны, входные данные не были идентичными и / или выходные данные были неверно истолкованы.
Это происходит вдвойне, так что если ваша система критически важна и должна быть доступна 24/7. Тогда вы не можете позволить себе роскошь не иметь систему обеспечения качества, потому что вы должны абсолютно минимизировать время простоя в производственной системе. И если это система 24/7, то точная копия производственной системы - очень и очень сильная рекомендация.
Теперь очевидным недостатком этого подхода является стоимость. Это удваивает затраты на оборудование и увеличивает затраты на развертывание и обслуживание. Кроме того, необходимо будет осуществлять непрерывную репликацию данных из производственной системы в QA, чтобы мы могли минимизировать возможность различных результатов из-за различий в данных, с которыми работают системы.
Некоторый баланс обычно можно найти, уменьшив некоторые компоненты системы обеспечения качества по сравнению с производственной системой, чтобы можно было надлежащим образом протестировать большую часть функциональных возможностей. Обычно это избыточные серверы, размер серверов или количество рабочих станций. Однако, по моему опыту, некоторая ошибка всегда обнаруживается именно в той части, которая была уменьшена, и тогда это кошмар, чтобы воспроизвести проблему и внедрить исправление, сохраняя при этом минимально допустимое время простоя в производственной системе.
источник
Каждый раз, когда вы тестируете систему, вы должны знать ожидаемый результат.
Проблема с тем, что система генерирует этот ожидаемый результат, очевидно, «как я могу протестировать эту систему»
Даже в этом случае не принято видеть, как люди используют электронные таблицы, например, для получения ожидаемых результатов.
В конце концов, хотя вам действительно нужен человек, чтобы интерпретировать требования системы и вручную получить ожидаемый результат. Если у вас есть система, которая делает это и проверяет различия, вы пропускаете тестирование.
источник