Я думаю, что весь QA является многосторонним. Разработчики должны протестировать свой собственный код, чтобы убедиться, что он делает то, что, как он думает, должен делать, и это не сломает сборку. Тестировщики должны проверить соответствие спецификациям, чтобы увидеть, правильно ли разработчик их интерпретировал (тестирование разработчиком почти никогда не обнаруживает этих проблем). Пэры должны делать обзоры кода, чтобы гарантировать, что стандарты соблюдаются и способствуют обучению. Пользователи должны проводить тестирование так же, как они будут пытаться делать то, что никто не ожидал или не определил в требованиях. Часто это глупые вещи, которые заставляют нас качать головами и говорить: «Почему кто-то все так думает?» Но многие другие являются подлинными требованиями, которых не было в спецификации, потому что никто не удосужился спросить пользователей, что им нужно. Приемочное тестирование клиента должно быть сделано, особенно если вы делаете индивидуальные разработки для разных клиентов. Гораздо проще показать, что новый запрос на работу является новой разработкой, а не ошибкой, если клиент подписался на работу до того, как он пошел в производство. Это может сэкономить тонны контрактных сражений за то, кто должен что-то платить.
Кроме того, когда кто-то еще исправляет ваш плохой код, это лучший способ гарантировать, что плохой код будет продолжать создаваться, поэтому я ненавижу организационную структуру, которая существует в некоторых компаниях, когда есть разработчики, которые делают новые вещи и поддерживают людей, которые делают исправления , Кроме того, менеджер, который исправляет плохой код, чтобы сэкономить время, не отправляя его обратно разработчику, вызывает проблемы для организации, не исправляющие их.
Другая важная часть QA, на мой взгляд, занимает время, чтобы реально определить требования и стандарты. (да, они изменятся в любом крупном проекте, но они все еще необходимы). Без требований тестирование в лучшем случае случайное. Без стандартов обслуживание может стать кошмаром и гораздо более дорогостоящим, чем необходимо.
Последняя часть QA учится на наших ошибках. К сожалению, во многих организациях вы не можете честно обсуждать после проекта, что пошло не так и как предотвратить это в следующий раз, не входя в сессию обвинительных обвинений, которая заставляет людей молчать, а не получать плохие оценки за их оценку производительности. , На самом деле оценки производительности в целом вредны для цели улучшения качества по этой причине среди многих других. (Обратитесь к разделу Деминг и Управление общим качеством, чтобы узнать мнение гуру по качеству о вреде, причиненном оценками эффективности.)
Теоретически должны существовать показатели качества, которые можно использовать для измерения ухудшенного качества. Однако на практике, пока в вашей организации проводятся оценки производительности, эти цифры часто будут «массироваться», чтобы улучшить внешний вид или измерить проблему (меньшее количество строк кода не означает лучший код во всех случаях, и больше отчетов об ошибках может Это означает, что мы делаем лучшую работу по нахождению (или, по крайней мере, сообщаем) об ошибках, а не о том, что код хуже, чем в прошлом проекте), и поэтому бесполезны.