Найти в Дзене
Будни тестировщика

Верификация и валидация.

Тестирование также должно гарантировать, что создано программное обеспечение требуемого качества. Представьте себе такой разговор между менеджером проекта и пользователем.

Менеджер проекта: "Я прошелся по всему проекту. Криптографический движок просто пуленепробиваемый, рекордно быстрый и использует 8192-битное кодирование — ваши секреты будут в безопасности триллион лет".

Пользователь: "На самом деле, я всего лишь хотел поиграть в пасьянс..."

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

Это иллюстрирует разницу между верификацией и валидацией. Верификация гарантирует, что вы создаете программу правильно; валидация гарантирует, что вы создаете правильную программу. Другими словами, верификация гарантирует, что система не ломается, она отвечает необходимым требованиям, обрабатывает ошибки корректно и т. д. Валидация обеспечивает соответствие требований реальным ожиданиям потребителя: выполняет ли программа то, что нужно пользователю? Существуют ли какие-то недочеты в требованиях, ведущие к тому, что даже если программа удовлетворяет им всем, пользователь все рано останется недовольным

И верификация, и валидация являются частью процесса тестирования ПО. Хотя большинство тестировщиков тратят бóльшую часть своего времени на верификацию, тестировщик не относится формально к тому, что программа соответствует требованиям. Тестировщиков можно представить как защитников интересов пользователя, даже если это противоречит интересам других заинтересованных лиц — необходимо создавать продукт, который соответствует пожеланиям пользователей, а не просто пытаться выпустить программу.

Интересно, что чем больше времени и ресурсов тратится на исправление дефектов или улучшение качества каким-либо образом, тем больше средств будет сэкономлено в долгосрочной перспективе. Работа с системой, в которой мало дефектов или, по крайней мере, существуют дефекты, о которых вы знаете, окажется значительно более легкой, чем когда вы захотите добавить новые функции в программу, которая периодически перестает работать и делает это как будто случайным образом. Система, проверяемая хорошим набором автоматизированных тестов, позволит вам вносить изменения и быть уверенным, что вы не создали новые дефекты в процессе разработки. Это парадокс качества программного обеспечения — вы можете потратить меньше денег и времени на создание лучшего продукта путем правильного тестирования.