О верификации и валидации

«Ты суслика видишь?
— Нет.
— И я нет. А он есть!»
("ДМБ")

В теории управления качеством есть два , казалось бы похожих , но все-таки разных понятия Верификация и Валидация.

Не всякий сходу сможет объяснить , в чем различие. Но оно есть и оно довольно существенно.

Неофициально эти термины можно расшифровать так:

Верификация - это проверка того, соответствует ли продукт (ПО, например) неким требованиям , которые считаются эталоном.

Валидация - это проверка применимости продукта в конкретных условиях, соответствует ли он им, может ли использоваться в этих условиях.

Довольно часто приходится сталкиваться с ситуациями, когда один и тот же казалось бы успешно протестированный софт спокойно функционирует у одного заказчика , но неприятно сбоит у другого. И тот и тот вроде как "типовой" для данной предметной области.  Но на поверку оказывается так, что небольшая разница в бизнес-процессах вроде бы универсальному софту оказывается не совсем по зубам.

Анализ причины пропуска , как правило, не занимает много времени:

• недорабатывают  с заказчиком менеджеры , не вытягивая из него максимум информации о будущих условиях и бизнес-процессах
• не до конца вникают аналитики (если они вообще есть)
• разработчикам не досуг - скомпилилось бы и прошли бы юнит-тесты (если он вообще есть)
• тестировщики с замыленными глазами тестовыми данными
• приемочные тесты поверхностны (заказчики часто довольно безответственно подходят к составлению таких тестов и их согласованию)

- все это может привести к неожиданностям при реальном использовании.

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

Специфика использования open-source проектов

  Как принято считать, стоимость исправления дефектов в ПО тем ниже, чем раньше стадия, на которой этот дефект был выявлен.Эта теорема не раз доказана практикой тысяч конкретных программных проектов. Тестирование идей и требований пока еще звучит как экзотика. Но стимуляция разработчиков к более тщательному выходному контролю кода уже стала нормой. Программисты клепают unit-тесты ( и теперь уже кто-то даже до написания логики ), многие обзаводятся своими собственными тестовыми стендами, и даже прогоняют на них основные по их мнению варианты. Этому нельзя ни радоваться и это нельзя не приветствовать. Но мышление разработчика остается мышлением разработчика. О многих вариантах использования, вариациях входных данных ему думать не досуг. И это правильно. Там, где за разработчиками стоят грамотные тестировщики, можно не беспокоиться - они позаботятся о проверке всех нужных вариантов, в том числе и довольно редких, но все-таки нужных.
  Но не все программные проекты подвергаются экзекуции тестировщиками, не все проекты проходят стадию "тестирования" перед выпуском в свет.. Особенно это касается многих open-source решений. Среди них много таких, которые кроме unit-тестирования никакого более тестирования не проходят. Баги ловят реальные пользователи, кто-то постит их в открытые багтреккеры и, если проект продолжает поддерживаться, он постепенно становится лучше. Бывает так, что баг висит годами без фиксов и пользователям этого открытого софта, библиотеки приходится патчить самим. Все бы ничего, схема работает. Да здравствует open source и GPL в руки! Но когда речь идет о создании коммерческого софта с использованием открытых библиотек, то не все удосуживаются анализировать используемый сторонний (3rd party) софт на наличие ошибок. Вот и вылезают потом неожиданности в виде багов, которые непонятно кому исправлять - то ли ждать фиксов от авторов сторонней софтины, то ли самим патчить. Если самим , то как это сделать так, чтобы не сломать - а для этого надо разобораться с внутренней архитектурой стороннего решения...
   В общем, не так гладко может все сложиться. А ведь даже поверхностный анализ баг-треккера той или ной открытой либы может помочь понять , стоит ее использовать в коммерческой разработке или нет.

• Покрыта ли библиотека unit-тестами, если да , то на сколько ? 
• Проходят ли unit-тесты в окружении, в котором планируется использовать будущий коммерческий софт? 
• Даже если внешне все гладко, то не стоит ли поручить тестировщикам помучать с помошью заглушек эту библиотеку и дать свою экспертную оценку о ее качестве?  

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

  Одно ясно точно - использовать open-source разработки в коммерческих проектах надо обязательно ( чтобы не изобретать велосипедов) , но чтобы потом не переписывать половину кода, из-за того, что "либа оказалась Г..", все сторонние решения надо тщательно анализировать.

Тестирование требований

Перечитываю старую добрую кингу Альфреда Дастина (Elfreide Dusting) "Автоматизированное тестирование программного обеспечения" (Automated Software Testing). Читал ее когда-то очень давно, не имея реального шанса проверить на практике советы и предположения, которые делает автор в своей книге. Сейчас, став чуть более опытным, многое из прочитанного становится более понятным, подтверждающим полученный опыт и "набитые шишки". Особенно понравилась следуюшая мысль (которая для кого-то может показаться банальной):
Программа, в основе которой лежат неточные требования, не будет удовлетворять заказчика или конечного пользователя независимо от качества описания архитектуры или программного кода, составляющего модули приложения (выделил жирным , по-моему , главную фразу предложения:)
Тысячу раз СОГЛАСЕН - так оно зачастую и происходит...
В качестве мер по предотвращению дефектов и проблем с конечным пользователем автор предлагает привлекать тестировщиков (высокой квалификации) с самых ранних стадий разработки ПО. В частности, со стадии составления спецификаций требований. Это мне также кажется верной стратегией, но ее соблюдение требует дополнительных трудозатрат со стороны тестирования. Кроме того, есть и психологический момент - не все разработчики, сисарки, менеджеры видят в тестировщиках людей, способных влиять на архитектурные решения до начала кодирования.
Интересно было бы узнать, насколько распространена практика привлечения сотрудников группы(сектора,отдела) тестирования к фазе составления требований к программному продукту и , соответственно, насколько она эффективна?
Если у кого есть желание поделиться своим опытом и мнением на этот счет, то буду признателен за соответствующие комментарии.