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

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

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

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

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

Мысли о workaround'ах

Второй день голова занята мыслями о workaround'ах и позволительности иметь их в программе независимо от их критичности.
Дело в том, что вчера я ехала на работу в маршрутном такси, в котором снаружи не было...ручки :). Изнутри мне открыл водитель, как и всем, кто садился после меня.

Проводя аналогию, я бы назвала отсуствие ручки проблемой в запуске программы традиционным способом, и приоритет был бы как минимум Critical и подпись "ASAP!!!", а то и Release Blocker. Однако, в реальной жизни был обнаружен (предложен) воркэраунд, позволяющий-таки ее запустить и использовать, хоть и...не вполне удобным способом. Преимущества на лицо:
1. Бизнес-пользователь (водитель) не потерял ни копейки своей ожидаемой прибыли.
2. Пользователи (люди) достигли цели, то есть вовремя добрались туда, куда хотели.
В общем-то, кроме некоего удивления UI'ем "программы", никто из пользователей и не заметил сбоя в работе!
Конечно, я не призываю не чинить такое вовсе. Я задалась вопросом - так ли критичны те баги, которые мы считаем критичными? Не тестируем ли мы программу в совершенно тепличных условиях и не смотрим ли мы на нее, как на то,чему суждено быть тепличным? Часто бывает, что наши юзкейсы отличаются от тех юзкейсов, которые нам потом дает бизнес, а иногда и от тех, которые потом приходят от пользователей в суппорт. Насколько наши испытания программы попадают в цель и сколько процентов от всех написанных нами тестов будут выполнять пользователи в реальной жизни, просто работая с программой, а не тестируя ее. Правильно говорят, что для успешного тестирования программы нужно научиться с ней жить.
Я часто встречала утверждение, что тестировщик должен смотреть на программу с точки зрения пользователей. Но мне кажется, нужно учиться смотреть еще и с точки зрения бизнеса.
Практика разделения Severity и Priority (о внедрении которой я как-то писала) получает еще один плюс в разрезе этой ситуации. Особенно, если выставлением приоритетов занимается представитель бизнеса, который чуть шире видит проблему и чей взгляд не зашорен мыслями о "страдающих пользователях" :)

Exploratory testing: плюсы и минусы

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

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

Минусы\риски

1. Отсутствие внятной статистики. Учитывая, что тест плана как такового нет - единственный способ понять состояние продукта - это открытые баги в багтрекере. Возможности просчитать статистику изменения состояния продукта мининмальны. К тому же, можно ли будет верить статистике, основанной на количестве открытых\закрытых багов, если невозможно понять, какие именно тесты проводил тестировщик над продуктом? Все ли необходимые тесты были выполнены? Были ли результаты всех тестов интерпретированы верно, или есть шанс, что часть багов были приняты за нормальное поведение системы?
2. Из первого пункта выходит вывод - исследовательское тестирование следует поручать людям, у которых уже есть опыт тестирования подобных приложений, да и вообще, есть опыт нахождения заковыристых багов. Как правило, тестировщик анализирует найденные когда-либо баги и далее, встречая подобные ситуации и части программы, может предположить, где ему искать баги в новой программе, учитывая старый опыт. То же самое с программистами - некоторые из них делают похожие ошибки довольно часто, и, зная программиста, можно сразу начинать искать в его "зонах невнимательности и безответственности". Так что, по причине разного опыта в случае, если дать двум экспертам тестирование одного и того же модуля, они найдут разные ошибки. То есть мы снова рискуем пропустить какие-то ошибки в программе.
3. Высокие уровень субъективизма при оценке результатов. Все вышесказанное ведет к тому, что нельзя вполне верить отчету тестировщиков, основанному на результатах исследовательского тестирования. :) Такой отчет значит лишь "Мы выполнили все тесты, которые пришли нам в голову, и нашли вот это. Анализируя то, что мы нашли (или не нашли?), мы полагаем, что билд хороший для текущей стадии разработки". Конечно, это мало отличается от тестирования по тест плану - там тоже результаты основаны на наборе тестов, только этот набор может быть дополнен более опытными сотрудниками, к примеру.

У меня вышло одинаковое количество плюсов и минусов, что означает "хорошая практика, если применять в меру".
Иногда я думаю, что в тестирование можно представить в виде равностороннего треугольника со сторонами 1 - время, 2 - количество найденных ошибок, 3 - достоверность и возможность использования результатов. Если пытаешься сделать одну из сторон короче - неизменно уменьшатся и остальные стороны. Пытаешься сэкономить время - теряешь в количестве найденных ошибок и результатах. Хочешь больше статистики - нужно увеличивать время на тестирование, что (возможно) повысит количество найденных ошибок.
Следуя этой, пока не вполне обдуманной, теории, исследовательское тестирование может занять следующее место в тестировании программы вцелом:

Этим рисунком я все же хочу подчеркнуть, что не все области могут быть протестированы с помощью этого метода и не всегда плюсы будут значить для нас больше,чем минусы.