Показаны сообщения с ярлыком Переводы. Показать все сообщения
Показаны сообщения с ярлыком Переводы. Показать все сообщения

понедельник, 24 августа 2020 г.

 

Доброго утра 35й недели 2020 года!



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


Хорошего настроения и отличной недели!


Альтернативные форматы блога:

Инстаграмм: https://www.instagram.com/russiaqa.ru/

Телеграмм: https://t.me/russiaqa

Russiqa.ru

 

 

 


пятница, 17 июля 2020 г.

4 колонны DevOps


Книга Effective DevOps вводит концепцию четырех колонн, на которых зиждется эффективный DevOps.  

 

“Here are the four pillars of effective devops:

• Collaboration

• Affinity

• Tools

• Scaling“

 


Поговорим о каждой колонне.

 

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

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

Вернёмся к книге Effective DevOps. Много страниц посвящено теме сотрудничества, аспектам, особенностям, сложностям. А так как разговор идёт о девопсе, то есть и примеры:

* асинхронный ревью кода

* документация

* апдейт тикетов

* еженедельные демо

* регулярная актуализация статуса

* парная работа

 

Вторая колонна эффективного DevOps – Affinity. Тяжело переводимое на русский язык понятие. Самый близкий перевод: близость, эмоциональное родство. Книга Effective DevOps определяет Affinity как степень силы взаимоотношений между индивидуальностями, командами, подразделениями и, даже компаниями. А в общем то это все также, как и сотрудничество, про культуру. Кого и как мы нанимаем в компанию, какое поведение поощряется, как оценивается вклад отдельного человека, команды в результат.

 

В основе взаимоотношений должны быть доверие и открытость. В конце дня каждый из нас, каждая команда будем успешны только, если компания будет успешна. Работать вместе, а не вопреки друг другу. Это не всегда просто!

 

Начинайте с себя, со своей команды! Все получится!

 

Третья колона в основании эффективного DevOps – инструменты. Чтобы не было как в том самом месте, когда есть только молоток, все проблемы кажутся гвоздями. Раньше конечно было проще, «тулов» было меньше, выбирать было особо не из чего. Сейчас с этим с одной стороны все веселее, с другой сложнее, т.к. выбор тула больше похож на вкусовщину. «На вкус и цвет все фломастеры разные». И чем больше компания, тем тяжелее будет сделать всех «счастливыми». Не говоря уже о том, что даже очень хороший тул при неправильном использовании будет приносить много боли и мало пользы. Хорошая цитата из книги «Effecctive DevOps»:

While tooling can be interesting, and the right automation can free up people’s time and energy to work on more complex problems, for tools to be effective they need to be chosen for reasons other than being interesting or new.

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

 

Последняя колонна DevOps – масштабирование (scaling). И речь не только про инфраструктурную составляющую. Масштабирование всего и вся, и кроме этого, культуры.

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

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

 

 

Всем продуктивной пятницы и отличных выходных!

 

P.S.:

Книгу можно найти вот тут: https://www.amazon.com/Effective-DevOps-Building-Collaboration-Affinity-ebook-dp-B01GGQKXOE/dp/B01GGQKXOE/ref=mt_other?_encoding=UTF8&me=&qid=

Картинки:

https://www.slideshare.net/aboullaitemohammed/effective-devops

https://smartdraw.com

https://quotefancy.com/quote/1206975/Nikki-Giovanni-Love-is-the-offspring-of-spiritual-affinity-and-unless-that-affinity-is

https://clickup.com/blog/agile-tools/

https://devops.com/five-donts-when-scaling-devops/

 

Альтернативные форматы блога:

Инстаграмм: https://www.instagram.com/russiaqa.ru/

Телеграмм: https://t.me/russiaqa

Russiqa.ru

 

 

 

 

 

понедельник, 29 марта 2010 г.

Бах: Становясь экспертом в области тестирования

Оригинал статьи тут.

Обзор: Стать экспертом в области тестирования – это путь постоянного развития. Наличие концепции развития очень помогает направлять свои усилия. Джеймс Бах, весьма известная личность в области тестирования, делится своим взглядом на «экспертность» и предлагает стремящимся к статусу эксперта решить задачу.


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


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


Я считаю себя хорошим тестировщиком. Я могу ошибаться на этот счет. Спросите меня лет через пятнадцать. Что я знаю точно, так это то, что я работаю в направлении достижения статуса эксперта. Как я себя заставляю двигаться вперед? Мне помогает личная концепция. Всем кто желает получить статус эксперта, нужна концепция «экспертности», это двигает нас, ставит высокие стандарты, однако должно быть достижимым за жизнь.


Личная концепция.

Я могу тестировать все, при любых условиях, за любое время…


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


Давайте добавим:

… в степени относительно…

  • Моего положения в процессе
  • Моих познаний о соответствующей технологии
  • Моего желания преуспеть


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


…Такие как..

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


Теперь концепция в сфере реальности, хотя и является вызовом.


В данном видении экспертизы, «Я могу протестировать» означает «Я могу хорошо выполнять работу тестировщика». Это измеряется человеческим стандартом: поведение лучших экспертов, которых можно найти. С этим стандартом в голове, как эксперты отреагируют на задачу тестирования ядерного реактора за 5 минут? Ответ: люди, которых я уважаю, начнут с использования самого великого инструмента в арсенале тестировщика – «задавания вопросов об ограничениях задачи». Самым лучшим в течение пяти минут будет спросить «Что тут происходит?» или что-то в этом роде. Ну а в данном конкретном случае, «Вы сбрендили?», что хорошо отражает абсурдность ограничения.


В принципе, основной смысл использования концепций в создании привычки при взгляде на каждый продукт задавать вопросы: «Как я буду это тестировать? А что если надо будет тестировать без требований? А что если выделенное время будет вдвое меньше?».


Учитывая выше написанное, вот вам задачка. Шесть лет назад, я написал небольшую виндовую программу как пример для упражнений на занятиях по тестированию. Я использую эту программу и по сей день. Я даю студентам 15 минут на ее тестирование. А если я дам вам всего 3 минуты на ее оценку, что вы будете делать? Мне в голову приходит 4 ответа, которые могут дать эксперты в тестировании…


Подумайте об этом. А тут мой ответ: http://www.satisfice.com/answer1.htm.


Об авторе: Джеймс Бах – основатель компании Satisfice, Inc., занимающейся консалтингом и обучением в области тестирования. Пионер развивающихся дисциплин: Достаточное качество и исследовательское тестирование, Джеймс специализируется на тестировании в хаотических условиях. Джеймс является соавтором (с Кемом Канером и Бретом Петтихордом) книги: Lessons Learned in Software Testing.


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

воскресенье, 22 февраля 2009 г.

Пейсон Хелл: Трудности перевода

Оригинал статьи: Lost in Translation
Об авторе: Пейсон Хэлл системный инженер и консультирующий руководитель проектов в Catalysis Group в Калифорнии. В течении 26 лет он консультировал различные проекты в частном и государственном секторе в Северной Америке и Европе. Связаться с ним можно по адресу: payson@catalysisgroup.com.

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

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

Система еще не была собрана, однако по слухам производительность уже тестировали, мне не хотелось ставить команду в затруднительное положении прямо на проектном собрании. Вместо этого, я решил разобраться в ситуации и дать им шанс ее разъяснить, для этого я спросил «Когда вы думаете провести тестирование производительности, и сколько оно по вашему займет времени?». Ответ архитектора потряс меня. «А мы уже провели тестирование производительности и результаты хорошие».

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

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

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

Я очень резко поинтересовался у моей знакомой, занимающей пост Руководителя команды «Что он нес? Мы оба знаем что никакого тестирования производительности не проводилось!»

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

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

вторник, 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 раза в неделю, а в конце проекта раз в неделю.

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

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

вторник, 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