Доброго утра 35й недели 2020 года!
Хорошего настроения и отличной недели!
Альтернативные форматы блога:
Инстаграмм: https://www.instagram.com/russiaqa.ru/
Телеграмм: https://t.me/russiaqa
Хорошего настроения и отличной недели!
Альтернативные форматы блога:
Инстаграмм: https://www.instagram.com/russiaqa.ru/
Телеграмм: https://t.me/russiaqa
Книга 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://clickup.com/blog/agile-tools/
https://devops.com/five-donts-when-scaling-devops/
Альтернативные форматы блога:
Инстаграмм: https://www.instagram.com/russiaqa.ru/
Телеграмм: https://t.me/russiaqa
Оригинал статьи тут.Обзор: Стать экспертом в области тестирования – это путь постоянного развития. Наличие концепции развития очень помогает направлять свои усилия. Джеймс Бах, весьма известная личность в области тестирования, делится своим взглядом на «экспертность» и предлагает стремящимся к статусу эксперта решить задачу.
Один из парадоксов найма людей со способностями к тестированию: люди, которые хороши в нахождении ошибок, находят очень много ошибок в себе и считают себя неквалифицированными для позиции тестировщика. Мы никогда не видим их резюме.
И достаются нам, в большинстве случаев, кандидаты, которые переоценивают свои способности в нахождении хороших ошибок. Та же ситуации с докладчиками на конференциях. Я встречал десятки интересных людей на конференциях, которые могли дать полезный совет и имели интересный опыт. Но когда я предлагал им встать и сделать доклад или написать статью, большинство говорили: «Я не эксперт. Я не знаю правильных ответов. Я не прочитал всех книг». Таким образом, ценный взгляд изнутри остается закупоренным внутри скептического разума многих отличных тестировщиков, когда многим, говорящим и пишущим, можно было бы чуть больше свои идеи тестировать.
Я считаю себя хорошим тестировщиком. Я могу ошибаться на этот счет. Спросите меня лет через пятнадцать. Что я знаю точно, так это то, что я работаю в направлении достижения статуса эксперта. Как я себя заставляю двигаться вперед? Мне помогает личная концепция. Всем кто желает получить статус эксперта, нужна концепция «экспертности», это двигает нас, ставит высокие стандарты, однако должно быть достижимым за жизнь.
Личная концепция.
Я могу тестировать все, при любых условиях, за любое время…
Это может быть хорошим началом. Проблема в том, что это нереально воплотить в жизнь. Например, если я не нравлюсь людям, или имею иной взгляд на хорошее тестирование, я не смогу хорошо выступить в данном проекте. Если я не понимаю тестируемую технологию, мой тест дизайн будет слабым. Если я не приложу достаточных усилий, я сделаю весьма посредственную работу. Итак, концепция требует несколько уточнений.
Давайте добавим:
… в степени относительно…
Это позволяет сделать концепцию более реалистичной, но все еще выходящей за пределы. Где же тут стандарт качества? Конечно же, я могу сделать все что угодно, если дозволено делать это плохо. Можно ли следовать данной установке и тестировать хорошо, если кто-то спросит вас протестировать атомный реактор за 5 минут? Чтобы решить эту проблему, добавим еще несколько утверждений:
…Такие как..
Теперь концепция в сфере реальности, хотя и является вызовом.
В данном видении экспертизы, «Я могу протестировать» означает «Я могу хорошо выполнять работу тестировщика». Это измеряется человеческим стандартом: поведение лучших экспертов, которых можно найти. С этим стандартом в голове, как эксперты отреагируют на задачу тестирования ядерного реактора за 5 минут? Ответ: люди, которых я уважаю, начнут с использования самого великого инструмента в арсенале тестировщика – «задавания вопросов об ограничениях задачи». Самым лучшим в течение пяти минут будет спросить «Что тут происходит?» или что-то в этом роде. Ну а в данном конкретном случае, «Вы сбрендили?», что хорошо отражает абсурдность ограничения.
В принципе, основной смысл использования концепций в создании привычки при взгляде на каждый продукт задавать вопросы: «Как я буду это тестировать? А что если надо будет тестировать без требований? А что если выделенное время будет вдвое меньше?».
Учитывая выше написанное, вот вам задачка. Шесть лет назад, я написал небольшую виндовую программу как пример для упражнений на занятиях по тестированию. Я использую эту программу и по сей день. Я даю студентам 15 минут на ее тестирование. А если я дам вам всего 3 минуты на ее оценку, что вы будете делать? Мне в голову приходит 4 ответа, которые могут дать эксперты в тестировании…
Подумайте об этом. А тут мой ответ: http://www.satisfice.com/answer1.htm.
Об авторе: Джеймс Бах – основатель компании Satisfice, Inc., занимающейся консалтингом и обучением в области тестирования. Пионер развивающихся дисциплин: Достаточное качество и исследовательское тестирование, Джеймс специализируется на тестировании в хаотических условиях. Джеймс является соавтором (с Кемом Канером и Бретом Петтихордом) книги: Lessons Learned in Software Testing.
Отсебятина: В принципе, по жизни очень полезно знать «Что я хочу? Как выглядит это? Как я буду этого добиваться?». Сложные вопросы, кто-то их задает себе и не знает ответа, кто-то знает ответ, а кто-то и не мучает себя такими вопросами. Желаю Вам задавать вопросы, знать ответы или хотеть их найти :)
Перевод: Галина Галкина (выражаю особую благодарность Артему Бабамуратову за помощь и критику)
Лаура Роуз является экспертом в области обеспечения качества, отвечает за инструменты обеспечения качества в IBM Rational. Лаура обладает 13-ти летним опытом программирования и 10-ти летним опытом руководства тестированием. Она была членом Американского Общества Качества (American Society for Quality), Трехстороннего совета по качеству (Triangle Quality Council) и Трехсторонней ассоциации по обеспечению качества информационных систем (Triangle Information Systems Quality Association), имеет публикации, участвовует в различных конференциях по качеству и тестированию. Вы можете связаться с Лаурой по электронной почте: llrose@us.ibm.com.
Давайте признаем – специалисты по тестированию программного обеспечения постоянно находятся в состоянии войны. Есть определенное количество ресурсов, и есть работа, которую нужно сделать. Мы боремся со временем. Мы мечемся между нахождением дефектов и проверкой исправлений. Мы – воины, и лучшим является тот, кто успешен в бою.
В этой статье я рассмотрю древние стратегии, описанные Сунь Цзы в его книге «Искусство войны», применительно к сфере тестирования программного обеспечения. Эти фундаментальные принципы помогут определить лучшие способы достижения успеха, будь то поле битвы, зал заседаний совета директоров или отдел разработки.
Сунь Цзы (Sun Tsu) был философом-практиком, один из его трудов - «Искусство войны» создан примерно в 500 году до н. э. Веками «Искусством войны» пользовались китайские и японские военные, и политические стратеги. В 2001 году Джеральд Михаэльсон (Gerald Michaelson) изложил «Искусство войны» применительно к бизнесу в своей книге «Искусство войны для менеджеров».
Существует множество книг, проводящих аналогию между бизнесом и жизнью в обществе (например, «100 простых секретов успешных людей», «7 привычек высокоэффективных людей», «Переговоры без поражений. Гарвардский метод»). Однако я думаю, что возвращение к первоисточнику весьма увлекательно и нет ничего лучше фундаментальных принципов, изложенных Сунь Цзы.
Михаэльсон преобразовал стратегии Сунь Цзы в 13 глав книги для бизнесменов. Заимствуя его идеи, я перевела эту работу для инженеров тестирования программного обеспечения. Категории Михаэльсона мне кажутся удачными, и я структурировала свой рассказ в том же ключе:
- Построение планов
- Оценка условий
- Сравнение свойств
- Поиск стратегических решений
- Ведение войны
- Использование разумного количества ресурсов
- Сделайте время союзником
- Каждый должен получить выгоду от победы
- Знайте ваши сильные стороны
- Атака с использование военной хитрости
- Победа без боя
- Сила против слабости – всегда
- Обходите стороной глупцов
- Следуйте фундаментальным принципам
На этом закончится часть 1. Последующие части покроют оставшиеся темы:
- Дислокация военных сил
- Использование энергии
- Слабость и сила
- Маневрирование
- Разновидности тактик
- Марш
- Местность
- 9 переменных расположения
- Атакуем огнем
- Нанимаем секретных агентов
Я планирую покрыть эти темы с разной степенью детализации, так как только некоторые относятся к высокопроизводительному тестированию. Я буду часто использовать в статье местоимение «он», обозначая «лучшего исполнителя». Однако это не означает, что воин-тестировщик может быть только мужского пола.
Чтобы действие было успешным, оно должно быть заранее подготовлено. Иногда в разработке программного обеспечения это достаточно сложно. Несмотря на то, что фундаментальные принципы одинаковы для всех проектов, тактика исполнения специфична. Поэтому нельзя слепо пользоваться предыдущими планами. В данном разделе будут обсуждаться:
- Детальная оценка условий
- Сравнение свойств
- Поиск стратегических решений
«Хорошая оценка – фундамент успешной операции»1
Оценка – это сущность тестирования. Независимые и надежные тестировщики должны оценивать качество программных продуктов эффективно, аккуратно и объективно. Это первостепенная роль хорошего тестировщика.
Высокопроизводительный тестировщик не останавливается на типичной оценке качества продукта. Он не ограничивается тестированием по требованиям или дизайну. Он копает глубже, понимая, что требования – это только исходный материал, описывающий использование продукта. Он видит, что использование продукта за пределами дизайна, дает больше результатов. Исследуя ожидания заказчика от использования продукта, стараясь понять задачи заказчика, он делает вывод о соответствии продукта целям заказчика.
Таким образом, он может связать свою работу напрямую с бизнес целями клиента, и легко показать, как его работа дает прибыль для клиентов его заказчика.
Как только проблема обнаружена, хорошие тестировщики регистрируют дефект и отслеживают его. Высокопроизводительный тестировщик идет дальше. Он анализирует причины проблемы и выясняет, почему ушло столько времени на её обнаружение, ищет способы уменьшения времени обнаружения. Он ищет новые, лучшие пути тестирования, автоматизации и ведения отчетности. Он умышленно вносит ошибки в код, чтобы научиться выявлять дефекты быстрее и эффективнее. Понимая, что всегда в программе дефектов будет больше, чем времени на их обнаружении, он концентрирует время и энергию на областях, которые заказчик более часто использует. Он также убеждает заказчика создавать лучшие диагностические и аттестационные инструменты для программного обеспечения. Инструменты могут предсказать ухудшение продукта, прежде чем проблема начнут влиять на работу заказчика. Специальные инструменты позволяют быстро вносить проблемы в код, тем самым, сохраняя время в перспективе.2
Кроме того, высокопроизводительный тестировщик отслеживает сообщения от заказчика, чтобы проверить, не пропущена ли какая-нибудь тестовая область. Он рассматривает «ошибку пилота» (см. http://en.wikipedia.org/wiki/Pilot_error) или «ошибку заказчика» как что-то двусмысленное и неопределенное в продукте. Он уменьшает стоимость и скорость обучения клиента с помощью публикаций документации, FAQов и статей. Он избегает будущих проблем, оформляя свои знания о продукте в базу знаний в виде статей, презентаций, аудио и видео файлов.
Он берет эту документацию на профессиональные конференции и семинары. Это помогает ему показывать с лучшей стороны свою компанию, что в свою очередь увеличивает его ценность для компании.
«Сравните свои сильные и слабые стороны с конкурентами»
Лучший исполнитель понимает, как его личный вклад соотносится с вкладом его коллег по команде, он дополняет команду. Он понимает, что сильная и успешная команда обладает различными талантами. Каждый ценит вклад остальных. Лучший исполнитель знает, что нет предела его достижениям. Он знает, что способности и таланты его коллег не ограничивают его, а расширяют его возможности. Лучший исполнитель понимает, что в команде он обладает неограниченным количеством таланта, опыта и ресурсов.
В то же самое время, он реалистично смотрит на свою ценность и свой вклад. Лучший исполнитель понимает, что ограничивает его полный потенциал. Он реалистично смотрит на свой карьерный путь и своё образование. Он выделяет «гуру» в области тестирования и стремится их превзойти. Он считает сертификацию в сфере качества и тестирования, соответствующей его карьерными целями. Он понимает, что внешняя сертификация даст ему дополнительную узнаваемость. Каждая преодоленная ступень карьерной лестницы открывает новую перспективу на профессию. С каждой новой перспективой, лучший исполнитель ставит для себя новые цели.
«Разрабатывайте стратегии, идущие впереди традиционных правил».
Лучшие исполнители разрабатывают стратегии, идущие впереди традиционных правил. «Хорошие» исполнители работают в пределах своего назначения и ждут, что возможности появятся сами. Лучший исполнитель сам создает возможности и не смешивает людей и проблемы. Он концентрируется на общей позиции. Он видит возможности взаимной выгоды.3
После выявления проблемы, лучший исполнитель концентрируется на поиске решения. Он понимает, что результат следует за процессом решения, а не за продолжительными обсуждениями проблемы.
В этом разделе описаны основные концепции оценки условий, сравнения свойств и создания изобретательных стратегий. Но каково практическое применение этого?
Вот некоторые способы:
- Пишите статьи, создавайте презентации и FAQ’и, основанные на опыте тестирования и использования продукта;
- Общайтесь с заказчиком, чтобы собрать информацию о бизнес моделях, приложениях, а также, чтобы собрать тестовые данные и данные о рабочем окружении;
- Ездите в командировки к заказчику, чтобы провести тестирование в реальном окружении;
- Проходите сертификацию.
Идеальная стратегия – та, которая лучше работает. Технологии программного обеспечения меняются очень быстро и то, что работает сегодня, может не работать завтра, а хорошая стратегия успешна только при должном исполнении. Отделение планирования от исполнения, ослабляет эффективность и того и другого.
«Инвестируйте только столько ресурсов, сколько необходимо для поддержания активности»
Использование разумного количества ресурсов - всегда вызов для организации, занимающейся тестированием. Мы обладаем большим количеством ресурсов, ресурсами надо управлять, их надо координировать. Т.к. командам надо тестировать на разных платформах и конфигурациях, на них падает ответственность за установку и поддержку. Даже если другие используют эти машины, часто именно тестировщики становятся «местными экспертами», когда что-нибудь падает. Каждая машина также нуждается в постоянном обновлении и контроле безопасности, что требует много усилий и времени. И все это ложится на плечи тестировщиков.
Вопрос использования разумного количества ресурсов особенно критичен, когда несколько активностей идут параллельно. Общеизвестно, что правильное распределение ресурсов между текущим и будущим программными продуктами и услугами составляет основу успеха. Многие организации делят ресурсы между поддерживаемыми версиями, исследованием будущих релизов и текущими разработками.
Учитывая написанное выше - что более соответствует развитию вашей карьеры: подготовка к использованию новой технологии или реализации далеко идущих идей?
Так как лучший исполнитель знает свои навыки и карьерные цели, он включает свои планы развития в рабочий процесс. Он понимает, что он полностью контролирует свое время. Он знает, что никто кроме него самого не отвечает за его развитие и благополучие. Лучший исполнитель демонстрирует хорошие навыки в области планирования для любой задачи, которую он выполняет (например, определение необходимых трудозатрат, прогнозирование даты завершения, подготовка отчетов о результате работа). Он подходит творчески к выделению нужного количества ресурсов в нужное время. Он держит в курсе всех заинтересованных лиц о ходе работ.
Первоклассный исполнитель – человек, ориентированный на решение. Он понимает, что жалобами делу не поможешь. Он использует помехи как возможности для применения нововведений. Он играет в игру «сделать незнакомое лицо на знакомую проблему» дабы увидеть новые перспективы решения.
Лучший исполнитель также контролирует время. Он мастер в управлении временем. Мы подошли к следующему пункту.
«Ключ в том, чтобы быстро стать эффективным и продуктивным»
Именно быстрая победа особенно ценится в войне. Лучший исполнитель быстро преобразует рабочую идею в измеримый и полезный результат для организации.
Прежде чем посетить семинар, конференцию или принять участие в обсуждениях экспертной группы, он определяет полезный продукт, который произведет для команды и организации. Прежде чем принять приглашение на ежедневные или еженедельные собрания, он анализирует повестку и цели собрания, анализирует, как это соотносится с его целями. Он тратит время только на нужные вещи. Это не значит, что эти собрания – пустая трата времени. Эти собрания могут быть очень интересными и занимательными. Просто он оценил ценность этих активностей для себя, и понял, что другие активности более значимы в данный момент.
Он делает время своим союзником. Он согласовывает свои активности со своими целями и желаниями. Время перестает быть проблемой, т.к. он работает с огромным желанием.
«Усиливайте человеческие и материальные ресурсы с каждой победой»
В войне успешная команда – это команда, в которой каждый выигрывает. Когда нанесено поражение врагу, вы получаете трофеи; вы комбинируете свои и чужие ресурсы, вы добры к пленникам, вы добавляете их к своим силам.
То же самое в бизнесе. Лучший исполнитель преобразует большинство рабочих активностей во взаимовыгодные. Если он прочитал книгу, посетил тренинг и т.п., он делится «трофеями», либо создавая артефакт, хранящий это знание, либо внедряя перенятые процедуры.
Хорошие исполнители видят задачи и их временные рамки. Они могут работать сверхурочно, чтобы закончить дела. Но они четко выделяют личное время для себя. Лучший исполнитель рассматривают опции расширения ресурсов, порой в ущерб себе.
Ниже приведена пара примеров.
Пример 1. В одном проекте нам нужна была помощь в системном тестировании. Команде технической поддержки и команде тренеров заказчика нужно было изучить продукт, чтобы выполнить свою работу. Мы могли бы работать дополнительное время, чтобы закончить тестирование вовремя, но мы попросили эти команды помочь нам. В результате мы получили дополнительные ресурсы на тестирование, а они изучили продукт. На основе впечатлений группы поддержки и группы тренеров, мы улучшили системные тестовые сценарии.
Пример 2. Мы обнаружили, что ввести процедуру инспекций кода в текущую культуру разработки достаточно сложно. У разработчиков всегда были готовы отговорки, начиная с «под проверки кода не выделено времени в плане» и заканчивая «мы не готовы к такому уровню зрелости процессов». Мы ввели проверки тест планов и тестовых сценариев и привлекли к ним разработчиков. Это само собой привело к инспекциям кода. Это стало победой для нас, т.к. таким образом, мы значительно улучшили тестовую документацию, и это была победа для разработчиков, т.к. инспекции были введены в процесс без ощущения, что инспектировать хотят самих разработчиков.
«Изучайте то, что необходимо для победы»
Конечно же, вы должны обладать знаниями, необходимыми для победы. Но когда найти время для оттачивания своих сильных сторон? Уже упоминалось множество обязанностей, на которые уходит время тестировщика.
Т.к. лучший исполнитель знает свои навыки и карьерные цели, он определяет области для улучшения своих знаний. Он озвучивает свои нужды начальству заранее. Он знает, что ресурсы должны быть доступны прежде, чем начнется атака (а не после начала проекта). Обучение должно быть в нужное время.5
Лучший исполнитель обладает отличными знаниями об индустрии. Он позиционирует себя как узнаваемого эксперта в выбранной области, он посещает события как местные, так и дальние. Он может даже подать заявку на посещение конференции до оглашения тематики. Когда тематика точно определена, он анализирует свои знания по теме. Тематика не всегда соответствует его интересам. Однако в представлении материала для аудитории, будь то коллеги по команде или высшее руководство, всегда есть плюсы.
Другой путь для лучшего исполнителя стать узнаваемым – это атаковать там, где нет соперников (создать свою нишу). Совмещение своих интересов с ежедневными рабочими обязанностями благоприятствует принятию инновационных решений.
В этом разделе приведены идеи ведения войны Лао Цзы и адаптированы к реальности тестирования программного обеспечения. Вот несколько практических применения этих идей:
- Найдите «гуру» в области и следуйте за ним;
- Записывайтесь докладчиком на конференции по малознакомым вам темам, это создаст сильнейший стимул для изучения;
- Объединяйтесь с коллегами для подготовки к сертификации;
- Стройте и поддерживайте взаимовыгодные отношения;
- Контролируйте ваше время, занимайтесь тем, что помогает достижению ваших целей.
Для каждой операции нужна стратегия. Стратегия имеет дело с выделением ресурсов на битву. Она устанавливает где, когда и в каком количестве силы будут использованы в битве.
«Безоговорочная победа – это победа без конфликта»
В разработке программного обеспечения часто случается, что о клиентах тестировщики и разработчики слышат только когда возникает критическая проблема. Иногда проблема уже прошла процесс эскалации по цепи руководства клиента, затем к нашему руководству, и затем до нас. В этой ситуации, естественно мы чувствуем себя под атакой. Первое правило в стратегии – это уделять особое внимание нуждам и желаниям клиента и возможностям организации удовлетворять им.6 Концепция быть победителем без боя является фундаментальной в трактате Сунь Цзы. Но как можно применить эту концепцию в тестировании?
Один путь избежать конфронтации между вашими нуждами и их желаниями. Например, найти общее между вашими нуждами и их желаниями. Это позволяет лучшему исполнителю видеть возможности улучшения продукта и процесса.
«Битвы выигрываются концентрацией силы»
Лучший исполнитель знает свои сильные и слабые стороны. Он строит взаимовыгодные отношения, это не только позволяет ликвидировать пробелы в знаниях, но и может пригодиться в будущем.
Ниже несколько примеров:
- 80% ошибок программного обеспечения закладываются на этапе формирования требований и на этапе архитектурного дизайна, поэтому легче исправлять проблемы на ранних этапах проекта. Лучший исполнитель уделяет особое вниманием требованиям и дизайну. Для этого вводятся экспертные обзоры, проверки кода, требований и документации на ранних этапах. Некоторые клиенты также могут быть вовлечены в анализ требований и дизайна, до начала фазы кодирования.
- Сотрудникам технической поддержки и техническим писателям нужно знать, как продукт работает, лучший исполнитель взаимодействует с этими командами. Они лучше узнают продукт, участвуя в тестирования.
- Лучший исполнитель старается получить для тестирования более ранние версии продукта. Многие организации проводят бета-тестирование, чтобы проверить приложение перед основным релизом, однако ошибки обнаруженные на этой стадии вряд ли будут исправлены в первой версии. Проблемы, обнаруженные на этапе бета тестирования, обычно планируют исправить в релизе поддержки. Только критичные «стопперы» правятся в авральном режиме, часто в суматохе. Внутренние ранние установки версий дают преимущество перед бета тестированием, также как и неофициальные установки наиболее дружественным клиентам. Это дает шанс понять качество продукта и исправить большинство проблем.
«Прежде чем действовать, узнайте все о ситуации»
Лучший исполнитель понимает, что может не видеть всю картину. Он знает, что его взгляд – это всего лишь взгляд одного человека. Ему нужно быть уверенным в том, что его руководитель проекта понимает текущий статус работ, он готовит статусные отчеты, часто обновляет их, анализирует и готовит прогнозы.
Лучший исполнитель фокусируется на целях компании, чтобы избежать ошибок. Рассмотрим примеры.
В разработке программного обеспечения целью не является следование определенным процедурам или соответствие заданным критериям. Цель – создать качественный продукт. Все остальное – инструменты достижения цели (повторяемые процедуры, метрики, критерии начала и окончания работ). Но иногда мы так увлекаемся инструментами, что забываем цель.
Я знала команду, целью работы которой, было получить «ноль» непроверенных дефектов к определенной дате. В итоге члены команды закрывали «вроде бы исправленные» ошибки не проводя повторное тестирование, лишь бы достичь показателя. Делая это, они показали, что совершенно не понимают значение метрики.
10% изменений влекут за собой новые ошибки.7 Проведение повторного тестирования к определенной дате позволяет обнаружить и исправить эти «добавленные» ошибки. Закрытие ошибок без проверки совсем не соответствует целям качества.
В любом начинании можно достичь успеха концентрацией ресурсов на наиболее важных задачах. Нельзя успеть везде. Если вы приложите все усилия к одной задаче, другая задача не будет выполнена так же качественно. Лучший исполнитель понимает значение метрик и процедур, он работает на качество. Критерии и метрики для него лишь инструменты оценки качества.
«Шансы на провал будут высоки, если не следовать правилам, обеспечивающим победу»
Лучший исполнитель для любой задачи понимает составляющие «успеха». Он определяет направление, утверждает задачи, постоянно следит за критериями успешного выполнения. Он делает стратегии и отношения простыми и ясными, прямыми и полезными. Он выбирает верный тип коммуникации, для важных вопросов предпочитая личное общение почте. А если коммуникация не принесла пользы, значит, время потратили впустую.
В этом разделе описаны основные концепции стратегии. Практическое применение:
- Понимайте цель метрик и процедур;
- Предпочитайте личное общение почте;
- Оценивайте необходимость собраний и задач, посещайте и делайте только то, что принесет пользу;
- Взаимодействуйте с другими командами;
- Проводите анализ возможности ротации для временного увеличения количества ресурсов;
- Цените своё время, используйте его в соответствии с вашими целями.
Это статья будет продолжена. В части 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