понедельник, 15 декабря 2008 г.

Мотивация сотрудников группы тестирования

Если хотите, чтобы ваши подчиненные хорошо работали их нужно хорошо мотивировать. Что же такое мотивация и как можно мотивировать сотрудников группы тестирования?

Корнем слова «мотивация» является «мотив». Обратимся к толковому словарю Ожегова: «МОТИВ: побудительная причина, повод к какому-нибудь действию» (http://www.ozhegov.ru/slovo/23779.html). Отсюда следует, что мотивация – это создание этих самых побудительных причин и поводов.

Рассмотрим существующие теории мотивации. Различают содержательные и процессуальные теории мотивации. Содержательные теории основаны на анализе потребностей личности. Процессуальные – основаны на восприятии и ожиданиях личности.

Пожалуй, самой известной содержательной теорией является пирамида потребностей Маслоу. Пирамида состоит из 5 ступеней человеческих потребностей:
1. Физиологические (голод, жажда, физиологический комфорт и т.д.);
2. Безопасность (вне опасности);
3. Любовь/принадлежность к чему-либо (быть членом сообщества, быть принятым);
4. Уважение (быть компетентным, получать одобрение и признание)
5. Самовыражение:
- Познание (Знать, Понимать, Исследовать);
- Эстетические (симметрия, порядок и красота);
- Самоактуализация (самореализация и реализация своего потенциала).
Маслоу относит первые четыре уровня к низшим потребностям. Каждая потребность должна быть удовлетворена последовательно. Последний уровень относится к потребностям развития. По Маслоу только человек, удовлетворивший все низшие потребности, может перейти к удовлетворению потребностей развития.

Еще одной интересной содержательной теорией является теория удовлетворенности/неудовлетворенности работой Фредерика Герцберга. Герцберг рассматривал «удовлетворенность» и «неудовлетворенность» как отдельные показатели. По его теории отсутствие неудовлетворенности не гарантирует удовлетворенность. Факторы, влияющие на «неудовлетворенность» Герцберг назвал «гигиеническими». К ним относятся: удобство рабочего места, отношения с коллегами, с подчиненными, с руководством, уровень заработной платы и т.д. Факторы, влияющие на «удовлетворенность» - мотивационные. К ним относятся: престижность работы, признание, перспективы. По теории Герцберга, прежде всего руководитель должен
позаботиться об отсутствие неудовлетворенности, а затем приступать к мотивации.

Также хочется упомянуть о теории потребностей Клейтона Альдерфера (ERG-теория). Она имеет много общего с теорией Маслоу, в основе лежит три группы потребностей:
- Потребности существования;
- Потребности в связях и отношениях;
- Потребности развития.
Потребности существования совпадают с физиологическими и потребностями безопасности по Маслоу. Потребности в связях и отношениях соответствуют 3ей ступени по Маслоу. Потребности развития соответствуют потребностям уважения и самовыражения по Маслоу. Основное отличие теории Альдерфа – это отрицание последовательного удовлетворения потребностей, и признание неограниченности удовлетворения потребностей (всегда можно усилить степень удовлетворенности).

Не менее интересной является теория приобретенных потребностей Дэвида Макклелланда.
Макклелланд соглашался с наличием физиологических потребностей, и предложил свои
потребности высокого уровня:
1. Стремление к успеху;
2. Стремление к власти;
3. Стремление к причастности.
Согласно теории Макклелланда эти потребности являются приобретенными. А следовательно каждого человека нужно мотивировать по его потребностям.

Перейдем к процессуальным теориям мотивации: теория трудовой мотивации Д. Аткинсона, теория справедливости С. Адамса, теория мотивации В. Врум.

Джон Аткинсон утверждал, что на поведение сотрудника влияет не только его внутренние
качества, но и ситуация в которой он оказался. Человек хочет добиться успеха и хочет
избежать неудачи. Для каждой задачи работник определяет вероятность успеха и его
привлекательность. Чем выше вероятность успеха, тем ниже его привлекательность. Все эти факторы влияют на силу мотивации стремления к успеху.

Каждый человек определяет справедливость полученного вознаграждение за свои усилия, по отношению к коллегам, выполняющим такую же работу. На этом основывается теория Адамса. Понятие справедливости весьма субъективно. Если, по мнению работника, его вознаграждение не справедливо, скорее всего, он снизит свою активность.

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

Вышеперечисленные теории мотивации не являются исчерпывающими. Обратившись к поисковику, найдете еще «пачку» теорий. Но не будем их сейчас рассматривать. Перейдем к мотивации в реальности.

В свое время я подняла тему мотивации на форуме портала it4business.ru. В общем, все сошлись на мнении, что одним из самых сильных стимулов являются деньги. И действительно, о каких «высоких материях» может идти разговор, если у человека нет крыши над головой и «мышь в холодильнике повесилась». Но все мы разные, и понятие «крыши» и «мыши» у всех разное. И чтобы понять другого человека, что ему нужно, что он ждет, с ним нужно общаться. «Чужая душа - потемки». Это верно, но помните «Невозможное - возможно», при правильном подходе :). К сожалению, универсального рецепта нет, да и быть не может, иначе все было бы очень просто и неинтересно. Общайтесь с подчиненным, анализируйте применимость к ним теорий мотивации. Не
пытайтесь всех подогнать под одну гребенку. Помните, что всегда есть исключения. Создавайте свои подходы. Все в наших руках.

Чем отличается сотрудник группы тестирования от остальных работников? Если не принимать во внимание профессиональные характеристики – ничем. Он такой же человек, как и все остальные работники компании. Тестировщик хочет кушать, хочет хорошо жить :). Я призываю вас подходить индивидуально к мотивации членов команды. Конечно, это не возможно, если команда у вас большая, но тут вы должны выделить лидеров и периодически прорабатывать с ними вопросы мотивации. Когда все в команде довольны, и работа спорится. Возможно ли, чтобы все были довольны? Да, возможно. Просто нужно захотеть. Вышеперечисленная позиция не является истиной в последней инстанции. Это мой подход. Это то, как я хочу работать с людьми, это то, как я хочу, чтобы работали со мной.

Список использованных ресурсов:
http://www.fooder.ru/page2/motivac_11.html
http://www.cfin.ru/encycl/satisfaction.shtml
http://www.pmsh.ru/articles/motiv.php?id_S=78
http://www.socioego.ru/teoriya/istoch/zanc/zan_motiv4.html
http://www.ecsocman.edu.ru/direktor/msg/174890.html
http://chiron.valdosta.edu/whuitt/col/regsys/maslow.html
http://psylist.net/uprav/teomot.htm
http://www.glossary.ru/cgi-bin/gl_sch2.cgi?RPwu.lxxzgr;t:l!yluwoo!suyoig.oo
http://www.dvgups.ru/METDOC/EKMEN/MEN/MOTIV_MEN/METOD/MELNIKOVA/Gl3.htm
http://www.vuzlib.net/spou/7.htm
http://www.cfin.ru/encycl/expectation_theory.shtml

воскресенье, 7 декабря 2008 г.

В помощь блоггеру

Искала как сделать сообщения "под катом" и нашла очень интересный блог On-line помощь при ведении блога на Blogger.com.

Автор пишет доступно и очень подробно. Шаги проиллюстрированы скриншотами. Если что-то не получается, автор всегда поможет советом.

Всем неискушенным в HTML, советую!!!

понедельник, 24 ноября 2008 г.

Каталог блогов на www.it4business.ru

В рамках проекта www.it4business.ru создается каталог блогов на профессиональные темы. Уже опубликованы ссылки на десяток блогов, и это только начало! Найдется блог на любой "цвет и вкус".

Однако, не только каталогом интересен портал. Здесь можно найти статьи на всевозможные IT-тематики. Можно опубликовать свои статьи. Можно и нужно общаться с коллегами на форуме.

Заходите на портал www.it4business.ru, найдете много интересного!!!

пятница, 24 октября 2008 г.

Как ошибка попала в продакшн?

Итак, релиз выпущен «в открытое плавание». Проходит день, другой. Однажды утром вы открываете почту, и находите письмо от клиента, сообщающее о серьёзной ошибке, найденной в процессе эксплуатации новой версии. Что делать? Рвать на себе волосы? Посыпать голову пеплом? Искать виноватого? Нет, нет и ещё раз нет!

Ниже предлагаю вам алгоритм действия в подобной ситуации.


(кликните по картинке для увеличения)

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

Ошибка, найденная клиентом – это сигнал «тревоги». Что-то в процессе, команде не так. Не является самым главным найти виноватого, важно понять причины возникшей ситуации и постараться устранить «проблемы», чтобы ситуация не повторилась снова.

Найти причину пропуска ошибки – это полдела. Нужно выработать стратегию её ликвидацию и поставки исправления клиенту в кратчайшие сроки и с минимальным риском для качества.

вторник, 7 октября 2008 г.

Триаж

Оригинал статьи : Software Triage
Автор: Девид Вален (david.whalen@comcast.net)
Перевод: Галина Галкина (galinaegalkina@yandex.ru)

Триаж. Если вы увлекались сериалом «MASH», тогда вы знаете термин «Триаж». Его также можно применить к тестированию программного обеспечения.

Если обратиться к Википедии, то «triage» является медицинским термином. Означает подход, используемый в медицине, для определения последовательности оказания помощи пострадавшим в условиях нехватки медицинского персонала.

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

Чтобы использовать понятие триаж в тестировании программного обеспечения, давайте немного изменим определение.

«Триаж – это подход, используемый командами разработки программного обеспечения, когда количество ошибок превышает количество доступных ресурсов для их исправления и проверки»

Что-то же – уже лучше.

Если с чем и знакомы тестировщики и руководители групп тестирования, так это с «ограниченными ресурсами». К сожалению, в ограниченное время невозможно протестировать и перепроверить все. Часто мы просим выделить больше времени и больше людей, так? Так!

Так как же лучше использовать ограниченное время и ресурсы? Используйте триаж!

Серьезность и Приоритет
Чтобы триаж был успешен, необходимо использовать две очень близких и все-таки очень разных характеристики ошибки: Серьезность и Приоритет. По подходу Триаж, каждые дефект обладает и Серьезностью и Приоритетом. Многие системы контроля дефектов использует либо одну, либо обе характеристики. Часто они используются взаимозаменяемо. Но все-таки эти характеристики различны. Давайте рассмотрим их подробнее.

Серьезность используется для определения степени влияния ошибки на пользователя или заказчика. «Степень влияния» возможно, было бы лучшим термином. Мы приписываем ошибке Серьезность, чтобы определить важность проблемы.

Сколько же значений серьезности необходимо? Как в сказке «Златовласка и 3 медведя» - 6 слишком много, 3 – слишком мало.

Я предпочитаю использовать четное количество значений. Нечетное количество часто ведет к уклонению от прямого решения (например, для 5 значений, слишком много ошибок бывают с серьезностью = 3). Может быть слишком много значений? Абсолютно! А слишком мало? Конечно. Если значений слишком много, управление дефектами превращается в ночной кошмар. Если слишком мало – тяжело определить степень влияния ошибки. Я работал в проекте, где было около 15 значений Серьезности (3 значения критических, 3 серьезных и т.д.). Со временем показатель Серьезности перестал что-либо означать.

Я пытаюсь не использовать только номер для обозначения серьезности. Обычно я использую номер с описанием (1-Критично, 2-Серьезно, 3-Косметическая проблема, и т.д.). Значения, выражаемые только числом, могут вводить в заблуждение (что более серьезно 1 или 4). Кто-то использует 1 для обозначения самой высокой степени Серьезности, кто-то наоборот. Независимо от того, как использовать обозначения, очень важно определить и задокументировать критерий определения каждого значения Серьезности ошибки. Значения серьезности ошибки изначально определяет тестировщик, который заносит ошибку в систему управления ошибками; тем не менее, занесенные ошибки должны проверяться и исправляться при необходимости. Вернемся к этому позднее.

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

Если исходить от целей Триажа, Приоритет используется для определения очередности исправления ошибок. Например, ошибка имеет Критичную Серьезность, однако в связи с большим объемом ресурсов, необходимых для исправления, может быть непрактичным исправлять ошибку сейчас. Некоторые критичные ошибки могут иметь невысокий приоритет, в то же время менее критичные могут обладать более высоким приоритетом. Например, опечатка не является критической ошибкой, однако наносит урон имиджу вашей компании. Опечатку легко исправить, таким образом, подобной ошибке могут присвоить высокий приоритет.

Уровни Приоритета, как и уровни Серьезности должны быть определены и задокументированы. Мне нравится использовать 3 уровня Приоритета (1-Высокий, 2-Средний, и 3-Низкий), потому что это просто и понятно большинству членов команды. 1-Высокий – ошибки, которые нужно исправлять срочно, 3-Низкий – ошибки, которые не мешают работе. Обычно ошибки с низким приоритетом переносят на следующий релиз.

Приоритет определяет порядок, в котором ошибки должны исправляться. Часто Приоритет определяют исходя из двух факторов: вероятность возникновения и необходимое количество ресурсов (время, доступность разработчиков и тестировщиков, и т.д.). Тест может приводить к падению программы, однако пользователь должен сделать что-то экстраординарное, чтобы повторить это. Если ошибка требует скрупулезного исправления или исправления архитектуры, возможно, не стоит торопиться с исправлением. Критично? Да! Высокий приоритет? Может быть. А может, и нет.

Уровни приоритета полезны в определение готовности релиза или качества (но это уже другая статья).

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

Руководитель проекта. Руководитель проекта – владелец процесса. Обычно именно руководители проекта может лучше всех оценить степень влияния на график работ и на ресурсы. Он также является лучшим посредником в спорах и принимает быстрые решения, если возникает такая необходимость. Руководитель проекта обладает правом наложения вето.

Руководитель группы менеджмента продукта/бизнез анализа. Менеджеры продукта или бизнес аналитики, представляют интересы заказчика. Именно они могут лучше всего оценить степень влияния с точки зрения заказчика.

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

Руководитель группы тестирования. Руководитель группы тестирования оценивает ошибку с позиции Качества. Я, как руководитель группы тестирования или группы обеспечения качества, часто веду Триаж совещания, т.к. являюсь ответственным за качество программного продукта и за управление ошибками.

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

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

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

Цели Триажа
Цель остается одна, вне зависимости от формы проведения триажа: оценить, установить приоритет и адресовать исправление ошибок. Как минимум, необходимо проверить серьезность ошибок, сделать изменения при необходимости, определить очередность исправления ошибок, и распределить ресурсы.

Процедура проведения Триажа
Подход к проведению триажа может меняться, я стараюсь концентрироваться на следующих аспектах.

Обзор ошибок, оценка и распределение. Обычно команда триажа проводит обзор и первичную оценку всех новых и/или отклоненных дефектов. Проводится проверка серьезности ошибки, определяются схожие ошибки, определяется очередность исправления. На совещании в системе управления дефектов устанавливается Приоритет и ошибки распределяются на членов команды либо для решения, либо для исследования. Мне нравится использовать проектор, чтобы все члены собрания могли видеть систему управления дефектами и изменения.

На совещании также просматриваются отклоненные дефекты, проверяется причины отклонения. Иногда дефект назначают на будущий релиз, либо проводят дополнительное исследование.

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

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

Обычно триаж собирается часто в начале проекта. Например, каждый день – вначале, затем 2-3 раза в неделю, а в конце проекта раз в неделю.

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

Как не называй – Обзор ошибок или Триаж, этот процесс, формально или неформально, является необходимой составляющей любого проекта разработки программного обеспечения. В этом процессе вы проверяется ошибки и определяете их приоритет. Успех проекта зависит от управления дефектами и принятия последовательных решений. Триаж – лучший способ, который я нашел. Может и не самый приятный, но необходимый. Почему бы ни сделать его проще? Кстати – я заметил, что пицца или пончики увеличивают посещаемость.

вторник, 9 сентября 2008 г.

Фредерик Брукс "Мифический человеко-месяц"


Как не прискорбно, но мне книга показалась жутко скучной. Основную мысль книги можно было выразить в небольшой статье. Размытые рассуждения делают чтение невыносимым.
Да, все мы ищем пути увеличения производительности своей работы. Да, мы хотим выпускать свою продукцию быстрее. Хотите узнать размышления известного человека на эту тему – читайте.
Если есть свободное время, читайте полностью, все-таки «международный бестселлер». А для общего ознакомления достаточно прочитать главы 18 и 19.

среда, 27 августа 2008 г.

Рекс Блэк "Ключевые процессы тестирования"


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

суббота, 23 августа 2008 г.

Роман Савин "Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах"

Tестирование dot com или пособие по жесткому обращению с багами в интернет-стартапах. Так называется книга Романа Савина. Хочется сразу сказать, что "жесткого обращение с багами" в книге я не увидела. Минусом считаю определение тестирования, данное в книге. Слишком много печатного места посвящено описанию занесения багов в bug tracking систему.

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

А вот "послесловие" советую прочитать всем! Праввильно написано, ППКС, как говорится :)

вторник, 19 августа 2008 г.

Воители обеспечения качества: часть1 – боевые стратегии для высоко-производительных тестировщиков

Автор: Лаура Роуз, руководитель программ Design Partner, IBM Rational Software Group

Перевод: Галина Галкина (выражаю особую благодарность Артему Бабамуратову за помощь и критику)

Лаура Роуз является экспертом в области обеспечения качества, отвечает за инструменты обеспечения качества в IBM Rational. Лаура обладает 13-ти летним опытом программирования и 10-ти летним опытом руководства тестированием. Она была членом Американского Общества Качества (American Society for Quality), Трехстороннего совета по качеству (Triangle Quality Council) и Трехсторонней ассоциации по обеспечению качества информационных систем (Triangle Information Systems Quality Association), имеет публикации, участвовует в различных конференциях по качеству и тестированию. Вы можете связаться с Лаурой по электронной почте: llrose@us.ibm.com.

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

В этой статье я рассмотрю древние стратегии, описанные Сунь Цзы в его книге «Искусство войны», применительно к сфере тестирования программного обеспечения. Эти фундаментальные принципы помогут определить лучшие способы достижения успеха, будь то поле битвы, зал заседаний совета директоров или отдел разработки.

1. Краткое введение в искусство войны

Сунь Цзы (Sun Tsu) был философом-практиком, один из его трудов - «Искусство войны» создан примерно в 500 году до н. э. Веками «Искусством войны» пользовались китайские и японские военные, и политические стратеги. В 2001 году Джеральд Михаэльсон (Gerald Michaelson) изложил «Искусство войны» применительно к бизнесу в своей книге «Искусство войны для менеджеров».

Существует множество книг, проводящих аналогию между бизнесом и жизнью в обществе (например, «100 простых секретов успешных людей», «7 привычек высокоэффективных людей», «Переговоры без поражений. Гарвардский метод»). Однако я думаю, что возвращение к первоисточнику весьма увлекательно и нет ничего лучше фундаментальных принципов, изложенных Сунь Цзы.

Михаэльсон преобразовал стратегии Сунь Цзы в 13 глав книги для бизнесменов. Заимствуя его идеи, я перевела эту работу для инженеров тестирования программного обеспечения. Категории Михаэльсона мне кажутся удачными, и я структурировала свой рассказ в том же ключе:

- Построение планов

- Оценка условий

- Сравнение свойств

- Поиск стратегических решений

- Ведение войны

- Использование разумного количества ресурсов

- Сделайте время союзником

- Каждый должен получить выгоду от победы

- Знайте ваши сильные стороны

- Атака с использование военной хитрости

- Победа без боя

- Сила против слабости – всегда

- Обходите стороной глупцов

- Следуйте фундаментальным принципам

На этом закончится часть 1. Последующие части покроют оставшиеся темы:

- Дислокация военных сил

- Использование энергии

- Слабость и сила

- Маневрирование

- Разновидности тактик

- Марш

- Местность

- 9 переменных расположения

- Атакуем огнем

- Нанимаем секретных агентов

Я планирую покрыть эти темы с разной степенью детализации, так как только некоторые относятся к высокопроизводительному тестированию. Я буду часто использовать в статье местоимение «он», обозначая «лучшего исполнителя». Однако это не означает, что воин-тестировщик может быть только мужского пола.

2. Построение планов

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

- Детальная оценка условий

- Сравнение свойств

- Поиск стратегических решений

2.1. Оценка условий

«Хорошая оценка – фундамент успешной операции»1

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

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

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

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

Кроме того, высокопроизводительный тестировщик отслеживает сообщения от заказчика, чтобы проверить, не пропущена ли какая-нибудь тестовая область. Он рассматривает «ошибку пилота» (см. http://en.wikipedia.org/wiki/Pilot_error) или «ошибку заказчика» как что-то двусмысленное и неопределенное в продукте. Он уменьшает стоимость и скорость обучения клиента с помощью публикаций документации, FAQов и статей. Он избегает будущих проблем, оформляя свои знания о продукте в базу знаний в виде статей, презентаций, аудио и видео файлов.

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

2.2. Сравнение свойств

«Сравните свои сильные и слабые стороны с конкурентами»

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

В то же самое время, он реалистично смотрит на свою ценность и свой вклад. Лучший исполнитель понимает, что ограничивает его полный потенциал. Он реалистично смотрит на свой карьерный путь и своё образование. Он выделяет «гуру» в области тестирования и стремится их превзойти. Он считает сертификацию в сфере качества и тестирования, соответствующей его карьерными целями. Он понимает, что внешняя сертификация даст ему дополнительную узнаваемость. Каждая преодоленная ступень карьерной лестницы открывает новую перспективу на профессию. С каждой новой перспективой, лучший исполнитель ставит для себя новые цели.

2.3. Поиск стратегических решений

«Разрабатывайте стратегии, идущие впереди традиционных правил».

Лучшие исполнители разрабатывают стратегии, идущие впереди традиционных правил. «Хорошие» исполнители работают в пределах своего назначения и ждут, что возможности появятся сами. Лучший исполнитель сам создает возможности и не смешивает людей и проблемы. Он концентрируется на общей позиции. Он видит возможности взаимной выгоды.3

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

2.4. Применение знаний

В этом разделе описаны основные концепции оценки условий, сравнения свойств и создания изобретательных стратегий. Но каково практическое применение этого?

Вот некоторые способы:

- Пишите статьи, создавайте презентации и FAQ’и, основанные на опыте тестирования и использования продукта;

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

- Ездите в командировки к заказчику, чтобы провести тестирование в реальном окружении;

- Проходите сертификацию.

3. Ведение войны

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

3.1. Использование разумного количества ресурсов

«Инвестируйте только столько ресурсов, сколько необходимо для поддержания активности»

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

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

Учитывая написанное выше - что более соответствует развитию вашей карьеры: подготовка к использованию новой технологии или реализации далеко идущих идей?

Так как лучший исполнитель знает свои навыки и карьерные цели, он включает свои планы развития в рабочий процесс. Он понимает, что он полностью контролирует свое время. Он знает, что никто кроме него самого не отвечает за его развитие и благополучие. Лучший исполнитель демонстрирует хорошие навыки в области планирования для любой задачи, которую он выполняет (например, определение необходимых трудозатрат, прогнозирование даты завершения, подготовка отчетов о результате работа). Он подходит творчески к выделению нужного количества ресурсов в нужное время. Он держит в курсе всех заинтересованных лиц о ходе работ.

Первоклассный исполнитель – человек, ориентированный на решение. Он понимает, что жалобами делу не поможешь. Он использует помехи как возможности для применения нововведений. Он играет в игру «сделать незнакомое лицо на знакомую проблему» дабы увидеть новые перспективы решения.

Лучший исполнитель также контролирует время. Он мастер в управлении временем. Мы подошли к следующему пункту.

3.2. Сделайте время союзником

«Ключ в том, чтобы быстро стать эффективным и продуктивным»

Именно быстрая победа особенно ценится в войне. Лучший исполнитель быстро преобразует рабочую идею в измеримый и полезный результат для организации.

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

Он делает время своим союзником. Он согласовывает свои активности со своими целями и желаниями. Время перестает быть проблемой, т.к. он работает с огромным желанием.

3.3. Каждый должен получить выгоду от победы

«Усиливайте человеческие и материальные ресурсы с каждой победой»

В войне успешная команда – это команда, в которой каждый выигрывает. Когда нанесено поражение врагу, вы получаете трофеи; вы комбинируете свои и чужие ресурсы, вы добры к пленникам, вы добавляете их к своим силам.

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

Хорошие исполнители видят задачи и их временные рамки. Они могут работать сверхурочно, чтобы закончить дела. Но они четко выделяют личное время для себя. Лучший исполнитель рассматривают опции расширения ресурсов, порой в ущерб себе.

Ниже приведена пара примеров.

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

Пример 2. Мы обнаружили, что ввести процедуру инспекций кода в текущую культуру разработки достаточно сложно. У разработчиков всегда были готовы отговорки, начиная с «под проверки кода не выделено времени в плане» и заканчивая «мы не готовы к такому уровню зрелости процессов». Мы ввели проверки тест планов и тестовых сценариев и привлекли к ним разработчиков. Это само собой привело к инспекциям кода. Это стало победой для нас, т.к. таким образом, мы значительно улучшили тестовую документацию, и это была победа для разработчиков, т.к. инспекции были введены в процесс без ощущения, что инспектировать хотят самих разработчиков.

3.4. Знайте ваши сильные стороны

«Изучайте то, что необходимо для победы»

Конечно же, вы должны обладать знаниями, необходимыми для победы. Но когда найти время для оттачивания своих сильных сторон? Уже упоминалось множество обязанностей, на которые уходит время тестировщика.

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

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

Другой путь для лучшего исполнителя стать узнаваемым – это атаковать там, где нет соперников (создать свою нишу). Совмещение своих интересов с ежедневными рабочими обязанностями благоприятствует принятию инновационных решений.

3.5. Применение знания

В этом разделе приведены идеи ведения войны Лао Цзы и адаптированы к реальности тестирования программного обеспечения. Вот несколько практических применения этих идей:

- Найдите «гуру» в области и следуйте за ним;

- Записывайтесь докладчиком на конференции по малознакомым вам темам, это создаст сильнейший стимул для изучения;

- Объединяйтесь с коллегами для подготовки к сертификации;

- Стройте и поддерживайте взаимовыгодные отношения;

- Контролируйте ваше время, занимайтесь тем, что помогает достижению ваших целей.

4. Атака с использованием военной хитрости

Для каждой операции нужна стратегия. Стратегия имеет дело с выделением ресурсов на битву. Она устанавливает где, когда и в каком количестве силы будут использованы в битве.

4.1. Победа без боя

«Безоговорочная победа – это победа без конфликта»

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

Один путь избежать конфронтации между вашими нуждами и их желаниями. Например, найти общее между вашими нуждами и их желаниями. Это позволяет лучшему исполнителю видеть возможности улучшения продукта и процесса.

4.2. Сила против слабости – всегда

«Битвы выигрываются концентрацией силы»

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

Ниже несколько примеров:

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

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

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

4.3. Обходите стороной глупцов

«Прежде чем действовать, узнайте все о ситуации»

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

Лучший исполнитель фокусируется на целях компании, чтобы избежать ошибок. Рассмотрим примеры.

В разработке программного обеспечения целью не является следование определенным процедурам или соответствие заданным критериям. Цель – создать качественный продукт. Все остальное – инструменты достижения цели (повторяемые процедуры, метрики, критерии начала и окончания работ). Но иногда мы так увлекаемся инструментами, что забываем цель.

Я знала команду, целью работы которой, было получить «ноль» непроверенных дефектов к определенной дате. В итоге члены команды закрывали «вроде бы исправленные» ошибки не проводя повторное тестирование, лишь бы достичь показателя. Делая это, они показали, что совершенно не понимают значение метрики.

10% изменений влекут за собой новые ошибки.7 Проведение повторного тестирования к определенной дате позволяет обнаружить и исправить эти «добавленные» ошибки. Закрытие ошибок без проверки совсем не соответствует целям качества.

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

4.4. Следуйте фундаментальным принципам

«Шансы на провал будут высоки, если не следовать правилам, обеспечивающим победу»

Лучший исполнитель для любой задачи понимает составляющие «успеха». Он определяет направление, утверждает задачи, постоянно следит за критериями успешного выполнения. Он делает стратегии и отношения простыми и ясными, прямыми и полезными. Он выбирает верный тип коммуникации, для важных вопросов предпочитая личное общение почте. А если коммуникация не принесла пользы, значит, время потратили впустую.

4.5. Применение знаний

В этом разделе описаны основные концепции стратегии. Практическое применение:

- Понимайте цель метрик и процедур;

- Предпочитайте личное общение почте;

- Оценивайте необходимость собраний и задач, посещайте и делайте только то, что принесет пользу;

- Взаимодействуйте с другими командами;

- Проводите анализ возможности ротации для временного увеличения количества ресурсов;

- Цените своё время, используйте его в соответствии с вашими целями.

5. Заключение

Это статья будет продолжена. В части 1 приводятся несколько практических советов, как увеличить производительность тестирования. Как я упоминала во введении, следующие части будут посвящены остальным стратегиям трактата Сунь Цзы применимым к области тестирования. Оставайтесь на связи!

Ссылки

1 Цитаты приведены из книги «Сунь Цзы: Искусство войны для менеджеров» Джеральда Михаэльсона

2 Один из примеров, проверка системы на ошибку «нет свободного места на диске».

3 «Переговоры без поражений. Гарвардский метод» Роджер Фишер, Вилльям Ури.

4 «7 привычек высокоэффективных людей» Стивен Ковей

5 Если обучать команду на будущее будут проблемы. Частая ошибка в компаниях проводить обучении технологиям, которые только планируется использовать в будущем. Команды обучаются, но не практикуются. И когда приходит время использовать новую технологию, обучению приходится повторить.

6 «Искусство войны для менеджеров» Джеральд Михаэльсон

7 Статистика показывает, что если необходимо проверить 100 исправленных ошибок, вы найдете как минимум 10 новых.

Список использованной литературы

The Effective Executive: The Definitive Guide to Getting the Right Things Done (Harperbusiness Essentials) by Peter F. Drucker, HarperCollins Publishers Inc, 2002

Sun Tzu: The Art of War for Managers; 50 Strategic Rules by Sun-tzu and Gerald A. Michaelson, Adams Media Corporation 2001The Top Ten Mistakes Leaders Make by Hans Finzel, Davide C cook Distribution Canada, 2007

A Whack on the Side of the Head: How you can be More Creative by Roger Von Oech, 3rd Edition, Warner, 1998Bookis INc

Smart Moves for People in Charge: 130 Checklists to Help You Be a Better Leader by Sam Deep and Lyle Sussman, Perseus Book Group, 1998

The One Minute Manager Meets the Monkey by Kenneth Bnanchard, Blanchard Family Partnership, 1989

The Seven Spiritual Laws of Success A Practical Guide to the Fulfillment of Your Dreams by Deepak Chopra, Pgw, 1995

The Tao of Leadership by John Heider, Lightning Source Inc, 1984

The 7 Habits of Highly Effective People by Stephen R. Covey, Free Press, 2004

The 100 Simple Secrets of Successful People by David Niven, PH. D, HarperCollins Publications, 2006

Getting to Yes: Negotiating Agreement Without Giving In by Roger Fisher and William Ury, Penguin Group USA, 1991

Managing Your Mouth by Robert L. Genua, Amacom Books, 1993

суббота, 16 августа 2008 г.

Правила тестирования

Не смотря на то, что тестирование процесс творческий - в проектах по производству ПО он ограничен жесткими временными рамками. Для любого тест-менеджера важно правильно рассчитать, спланировать трудозатраты, чтобы «уложиться» в отведенные под тестирование сроки. Как этого достичь?

Первое правило: никогда не «прогибайтесь» под временные рамки проекта. Оценка трудоемкости цикла тестирования должна быть полной. Руководитель проекта и Заказчик должны понимать, что тестировать приложение полностью – «дорого», поэтому важно доносить до них информацию о том, сколько и как можно протестировать за выделенное время. Хороший план – это залог успеха. А хороший план можно составить только на основании реальных оценок.

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

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

Четвертое правило: внимательно читайте требования. Если есть хотя бы малейшая неоднозначность, не стесняйтесь лишний раз спросить. Цена неточности возникшей в начале цикла разработки, с каждым шагом, этапом, раундом - повышается. Лучше задать глупый вопрос и быть уверенным в ожидаемом результате, чем на последних раундах жизненного цикла проекта/релиза судорожно выяснять, как же должна работать программа. Следите, чтобы требования и test case’ы были в актуальном состоянии.

Пятое правило: проводите раунды тестирования «в свободном полете». Другое название – exploratory testing. Штука весьма и весьма полезная. Протестировать все по test case’ам конечно хорошо. Но пользователи не роботы, а живые люди и они могут сделать что-то не так, не по сценарию. Отсюда следует, что иногда полезно пройтись по приложению в отрыве от test case’ов и «копать» в наиболее часто используемых пользователями местах.

Шестое правило: ведите тест-логи (test logs) аккуратно. Тест-лог – это официальный документ. Он подтвердит результаты проверки, и как следствие – общее качество разработанного продукта. Лог должен вестись добросовестно. Самая неприятная ситуация, когда тест помечен как успешно пройденный, а на деле получается, что этот кусок функциональности не работает совсем, и работать ранее не мог. Прививайте культуру ведения тест-логов в вашей команде.

Седьмое правило: все ошибки должны быть зарегистрированы (записаны, занесены в систему управления дефектами). Прививайте культуру фиксации дефекта сразу после его обнаружения. Ошибки должны исправляться, но откладывание занесения ошибки, а, следовательно, её «обнародования» сдвинет момент исправления. В результате риск сорвать сроки увеличивается.

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

среда, 13 августа 2008 г.

И я туда же...

Вот и я решилась присоединиться к многочисленной армии блоггеров. Посмотрим, что из этого выйдет...