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

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

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

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

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

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

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

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

Помните о своей команде

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

И пришел Аврал...

Ситуация часто встречающаяся и всем известная - "восемь девок, один я" - много разработчиков и мало тестировщиков. Что делать, куда бежать?

Вариант 1. Самый простой, очевидный, никого не напрягающий.
- "Останусь-ка я подольше".
Но потом зачастую выясняется, что и это не спасает.

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

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

Вариант 4. Почти сказочный.
Договариваемся о переносе сроков в связи с тем, что функционал не будет как следует протестирован к назначенному сроку.

Мини-памятка:
Когда происходит частое изменение условий работы (например, на тестирование в процессе работы над уже оговоренным скоупом в него добавляются новые таски) - следует не забывать
- каждый день мониторить изменения
- заново оценивать необходимое на тестирование время, исходя из изменений
- не стесняться просить о помощи
- пытаться подключать к работе всех, кого только можно (безусловно, если таска достаточно важная).

Элияху М. Голдрат, Джефф Кокс: Цель. Процесс непрерывного совершенствования

Замечательная книга "Цель. Процесс непрерывного совершенствования" написана в форме новеллы, что само по себе является необычным для подобного рода литературы. Однако, это делает ее более увлекательной и быстро читаемой.
Главный герой - Алекс Рого - руководитель убыточного завода, которому руководство дает 3 месяца на изменение ситуации, после чего, в случае недостаточных изменений, обещает закрыть завод. Книга описывает трехмесячный период непрерывной работы над улучшением процесса производства. В итоге Алекс и его помощники-коллеги приходят к выводу, что цель компании - зарабатывать деньги, а также определяют алгоритм работы на заводах объединения:
Шаг 1. Найти узкие звенья системы.
Узкое звено в реалиях завода - это это все то, что не позволяет компании производить столько продукции, сколько ей требуется. Это может быть не только материалы, оборудование или люди, это также может быть продажи, например.
Шаг 2. Решить, как использовать узкое звено.
Узкое звено должно задавать ритм работы всей системы.Оно используется для контроля, чтобы избежать перегрузки системы или создания нежелательных запасов (например, горы материалов перед узким звеном или большое количество материалов\готовое продукции на складе, которые никому не нужны).
Шаг 3. Согласовать все остальные действия с этим решением.
Нет смысла производить много больше,чем может обработать узкое звено - продукция либо будет создавать завалы перед узким звеном в ожидании обработки, либо будет пылиться на складе.
Шаг 4. Повысить пропускную способность узкого звена.
Создание "буфера" перед узким звеном для обеспечения его непрерывной работы (при этом в буфере должно храниться разумное количество материала, чтобы буфер не превратился в склад). Также можно "разгрузить" звено и выдавать ему на обработку только качественные детали, тем самым экономя время работы звена.
Шаг 5. Если на предыдущем этапе узкое звено было устранено, то перейти к шагу 1.

Итого, что полезного можно вынести для управления разработкой ПО:

1. Цель компании - зарабатывать деньги.
Качество продукта само по себе не может быть целью. Как и выпуск продукта. Целью должна быть именно прибыль. Если наш продукт никто не покупает - зачем его писать? И уж тем более зачем тщательно тестировать, заставляя исправлять сценарии "с подвыподвертом", тем самым увеличивая конечную стоимость продукта. Тестирование ни в коем случае нельзя рассматривать отдельно от процесса производства продукта.

2. Алгоритм не меняется!
Шаг 1. Найти узкими звенья - почему нет? Например, на стадии жестокого багфикса с ежедневными билдами программисты исправляют по 100 багов в день, а отдел тестирования в день проверяет только 60.
Шаг 2. Тогда тестировщики будут узким звеном, под которое и нужно будет подстраивать всю работу.
Шаг 3. Голдрат на заводе в таких случаях рекомендует позволять людям ничего не делать, чтобы не собирать тонны работы перед узкими звеньями. В разработке ПО же все будет проще - достаточно занять людей, производящих "на склад" другой работой - например, переключить на другой проект или другую задачку, которая пока не будет проходить через тестировщиков. Это не требует перехода в другой цех и не требует знаний другого производственного оборудования, поэтому мы более везучие, чем рабочие завода :)
Шаг 4. Временно снимем с тестировщиков другие задачи, отложим их или передадим другому отделу. Сделаем небольшой буфер в определенное разумное количество тикетов для любителей поработать ночью и на случай задержки утреннего билда. Введем обязательную проверку разработчиками своих исправлений. Ну и автоматизированное тестирование сборки программистами.
Шаг 5. Ищем новое узкое звено.

3. Производство ПО практически ничем не отличается от любого другого производства.

4. Другие более мелкие выводы.

Рекомендую книгу к прочтению всеми работниками, вовлеченными в разработку ПО.

Размер бонуса

В своей пока еще короткой профессиональной жизни я встречалась с бонусной системой, и пока ни в одной компании она не была совершенной. :) Можно выделить несколько типов квартальных бонусов:

1. Отсутствие бонуса.
Плюсы:
+ Человек работает "за идею" и зарплату. В большинстве случаев он выносит на рассмотрение уже хорошо обдуманные идеи, которе реально могут пригодиться.
+ Избавлен от переживаний о том, дадут ли бонус вообще.

Минусы:
- Нужно найти идейных людей.
- Нужно хорошо продумывать политику поддержания уровня мотивации.
- Нужна прозрачная система повышения зарплаты.

2. "Слишком маленький бонус"
Плюсы:
+ Минимальные затраты со стороны предприятия.
+ Возможность написать "бонусная система" в описании вакансии.
+ Возможность небольшой мотивации материально-ориентированных сотрудников.

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

3. "Слишком большой бонус"
Плюсы:
+ Сотрудники крепко держатся за свое место на работе, соответсвенно, состав команд часто не меняется длительное время, что приводит к более сплоченой работе.
+ Материально-ориентированные сотрудники высоко мотивированы.
+ Придумывается много идей для улучшения процесса и повышения эффективности работы.

Минусы:
- Желание получить большой бонус заставляет некоторых людей генерировать по сто идей в неделю, большинство из которых очень сырые и непродуманные. Много не самых лучших идей внедряется очень быстро, без детального и основательного обдумывания - генераторы идей просто "продавливают" их для получения прибыли. Конечно, часть таких нововведений в скором времени сама собой перестает использоваться, но не стоит забывать,что внедрение и отказ от использования того или иного подхода-метода-инструмента стоит времени, а значит, денег.
- Нужна хорошо проработанная система оценивания персонала (либо менеджер, близко и внимательно наблюдающий за работой команды) - нужно успеть вовремя определить момент, когда человек начинает работать только за деньги, отсиживая оговоренные в трудовом договоре 8 часов в день.

4. Нормальный бонус
Плюсы:
+ Полная гармония.

Нормальный бонус вызывает у работников желание побороться за него, но не становится основной целью. Получение такого бонуса приятно, а неполучение не очень-то влияет на самооценку и\или материальное благосостояние.
После раздумий о размере "нормального" бонуса, я пришла к цифре 15%. Сначала я думала о 10 процентах, но это не подходит для компаний, где работает много джуниор сотрудников с низкой зарплатой. Во всяком случае, если бы в моей первой компании, где я стала работать тестировщиком, был бонус в 10% - вряд ли я бы стала пытаться его получить - слишком маленькая сумма получалась.