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 рекомендуется использовать во всех остальных случаях.

Гремучая смесь - толковый технический специалист и слабый командный игрок

Принято считать,что ИТ-шники довольно замкнутые люди с низким уровнем социализации, и что открытые общительные люди в нашей отрасли скорее исключение из правил. На самом деле, речь идет о профессиональном искажении,присущем каждой из профессий в том или ином виде, но этот пост не о том. И даже не в том, как с ним борются или пытаются минимизировать в рамках компании.
Представим ситуацию, что есть очень толковый технический специалист, но с небольшим (?) минусом - он слабый командный игрок. Я встречала два типа такой гремучей смеси:

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

2. Альфа-самец
Может быть как "душой компании", так и просто уважаемым человеком. Имеет авторитет в технических вопросах. Однако использует его не всегда во благо компании - свой авторитет ревностно оберегает и подавляет "инакомыслящих", что приводит к тому,что мнение команды является мнением одного человека. Возникают проблемы и вопросы - поставить его на руководящую должность значит официально дать разрешение на авторитарность в принятии решений. Не поставить на руководящую должность - значит все время заставлять соперничать формального (менеджера) и неформального (альфа-самца) лидеров.

А в Вашей практике встречались еще какие-то виды такой гремучей смеси?

"Гремучей" такая смесь является потому, что и отпускать сильного технического специалиста не хочется, и танцевать с бубном, пытаясь сделать его работу и работу с ним эффективной, не каждому по силам и "по нервам".

January 10, 2012

Интересный факт - Эффект Даннинга-Крюгера

Некоторые вещи ставит на свои места, о других заставляет задуматься:

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

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


Описание взято с вики.