January 17, 2012

Re: Testing-by-contract VS defensive testing

Начала писать ответ на статью в комменте, но вышло много буков - пришлось перенести к себе в блог.

Testing-by-contract и Defensive testing - это два разных подхода к тестированию. Как и любую методологию, каждый из этих подходов будет эффективен при соблюдении каких-то условий. Соответственно, и какой подход применять, решается для каждого КОНКРЕТНОГО проекта.

1. Что мы знаем о пользователях?

Пример 1.
Многопользовательская система
Ориентировочное количество пользователей - 1000
Характеристика пользователя:
возраст - от 10 и до 55-60 лет
навык владения компьютером - от базового до продвинутого
Личности целевой аудитории: неизвестны

Какой подход использовать в этом случае?
Конечно, второй - Defensive testing - и никаких сомнений!
Мы не знаем и не можем предположить, что взбредет в голову нашим пользователям - как они будут использовать нашу систему и для каких целей.

Пример 2.
Многопользовательская система
Ориентировочное количество пользователей - 35
Характеристика пользователя:
возраст - от 25 до 45 лет
навык владения компьютером - продвинутый
Личности целевой аудитории: известны - это работники предприятия, которое заказало разработку продукта

Какой подход использовать?
Обговорите с заказчиком,узнайте,чего он хочет. Я бы предлагала ему testing-by-contract, возможно,с некоторыми исключениями. Список исключений можно выяснить при разговоре с представителем будущих пользователей, назовем его бизнес-специалистом. Это человек, который знает о том, для чего предназначена разрабатываемая система и который будет сталкиваться с ней в ежедневной работе.

2. Особенности заказной разработки "для себя"
а) Направленность пользователей на результат
Как правило, когда разработка заказывается "для себя",а не для продажи, то и требования к ней уникальны. Люди бизнеса отлично понимают язык цифр и если им предоставить примерный расчет затрат на тестирование негативных сценариев и их исправление, многие решат сократить их количество. Почему? Потому что некоторые из сценариев не придут в голову тому, кто использует систему не для того,чтобы сломать,а чтобы РАБОТАТЬ с ней и получить от системы то,ЧТО ОНА ДОЛЖНА ВЫПОЛНЯТЬ. Зачем тратить время и умышленно делать разработку продукта дороже, если проверяемые нами сценарии ни разу не будут задействованы при эксплуатации системы? Зачем тратить время на их исправление?
Пример - установка десктопного приложения в папку с максимальным уровнем вложенности для ОС.

Не ставится,выдает непонятное сообщение об ошибке. И что?! Пусть и дальше не ставится, "сам дурак"...

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

в) Прибыль - уже сейчас

Обратите внимание на системы учета чего угодно в государственных учреждениях или маленьких коммерческих структурах. Эти системы тормозят, зависают, могут выдавать некорректные данные или не выдавать вообще, да и выглядят отвратительно,в конце концов. Одним словом - сырые, недоработанные и совсем не user-friendly.
Так почему же их используют? Потому что уже СЕЙЧАС эта система, такая сырая и некрасивая, может приносить прибыль - и ее берут в эксплуатацию, по ходу получаю апдейты и патчи. Заказная разработка стоит дорого, чем раньше она начнет окупаться- тем лучше.

г) Исключения

Безусловно,следует понимать последствия фейлов и специфику системы. Если речь идет о коррапте базы данных при попытке заимпортить в нее файл не того формата,что определен в требованиях - это нужно проверять. Если ранее Вами было выяснено у бизнес специалиста\заказчика,что эта ситуация реальна и узнали у программиста(\из кода\совершенно случайно\...), что это действительно может привести к серьезным последствиям.
Такие исключения никто не запретит добавлять в тест план. Конечно, после обсуждения с заказчиком,если разработка все же заказная и было условлено тестировать систему только позитивными сценариями.


Итог:

Testing-by-contract имеет право на жизнь для заказных систем с известным кругом пользователей. Принятие решения по использованию именно этого подхода должно быть обговорено с заказчиком. Бенефит для заказчика - удешевляет разработку. Бенефит для компании-разработчика - клиент не уходит к другому заказчику, который обещает сделать все тоже самое, но в 3 раза быстрее и дешевле (мы-то знаем,что он просто будет делать только defense testing,иначе эта цель недостижима). В "умелых руках" и при соблюдении должных условий этот подход к тестированию может принести большую пользу. Однако,использовать нужно осторожно, возможно, придется добавить гибкости и все же описать и обработать какие-то негативные сценарии - зависит от контекста (сложность системы, критичность дефектов, пользователи).

Defensive testing рекомендуется использовать во всех остальных случаях.

3 comments:

  1. "клиент не уходит к другому заказчику, который обещает сделать все тоже самое, но в 3 раза быстрее и дешевле (мы-то знаем,что он просто будет делать только defense testing,иначе эта цель недостижима)."

    По-моему вы опечатались насчет того, что "он" будет делать :)

    А вообще любопытно, да, я на практике не сталкивалась еще с системами из второго примера :)
    Вроде и люди работают взрослые, а такие вопросы на хотлайн задают... Поэтому ранний релиз, чтобы "начало приносить доход" - это да, а вот без defense testing было бы плохо. Но это у нас, а если бы мы писали проект под свою компанию, например, то да, там можно было бы особо негатив не проверять - все подскажут, в конце концов, что ты не так ввел.

    ***

    А вообще тормознутые/глюченые/итд гос системы огорчают :(

    ReplyDelete
  2. ай...
    1."возраст - от 10 и до 55-60 лет". Вот из-за таких ошибочных представлений я как-то при переоформлении кредитной карты в банке Райфайзен на пару со старшей менеджершей и пыталась уговорить банковскую систему меня опознать. В конце концов веселились все -- ну да, у кого год рождение выходит за озвученные пределы - тому с точки зрения айтишников кредитка ни к чему.
    Ну а всякая информация про пенсии в инете -- вообще незачем. (три раза хихикс!)
    2. "Пример 2." . Тут вообще элементарно. Начинаем с чтения ГОСТов для АСУ. Уф.... там расписано -- что в ТЗ на АСУ должно быть. В т.ч. и уровень подготовки персонала.))). ТЗ с заказчиком подписываем, а там и уровень подготовки персонала оговариваем))).

    ))) как-то так.

    Фрося

    ReplyDelete
    Replies
    1. Банковские системы - это особый вид ПО, разработка которого должна быть особенно тщательной - цена ошибки очень велика.
      В моем первом примере я пыталась описать систему из примера okiseleva, где она описывала систему регистрации пользователей - мне подумалось о регистрации в интернет-магазине. Это всего лишь пример,не более. На самом деле, целевую аудиторию нужно не с потолка придумывать, а исследовать. И никогда не браться за разработку "не пойми для кого".
      В описанном Вами случае глупо было вообще ограничивать верхний порог возраста - возможность оформить кредитку должен иметь человек любого возраста, превышающего нижний порог. А нижний порог в данном случае регулируется законодательством.
      Хотя если совсем уж задуматься, то целевая аудитория могла быть рассчитана верно (это сотрудники банка), а вот вариации данных, с которыми они могут работать - неверно.
      Насчет второго примера - не всегда заказчиками таких систем являются государственные учреждения. Я никогда не участвовала в разработке проекта для государства, но встречалась с заказной разработкой для небольшой коммерческой иностранной компании. Конечно, этому заказчику плевать на наши ГОСТы - у него есть свой список того, что конкретно система должна делать.

      Delete