"Санта Барбара" в тестировании

Я лично убежден в том, что люди - это костяк любого бизнеса. Каким бы хорошим не был Ваш план, но без желания людей его выполнять, любой блицкриг может обернуться провалом. Чтобы привести проект к успешному завершению, руководителю, прежде всего, нужно найти подход к управлению своей команды. Большие проекты можно сравнить с сериалом «Санта Барбара», когда серий больше, чем дней в календарном году, не понятно кто с кем будет в следующей серии и постоянно кто-то с кем-то скандалит, решает какие-то проблемы, а кто-то кому-то обмывает кости =). Это также справедливо для команды тестирования, как и собственно для разработчиков, дизайнеров, или команды менеджеров. Одной из задач, которую приходится решать тест менеджеру или лидеру команды тестирования, являются «внешние» и «внутренние» конфликты,  возникающие у подчиненных. Конфликт — ситуация, в которой каждая из сторон стремится занять позицию, несовместимую и противоположную по отношению к интересам � [...]

Катализатор для мечты

В этот воскресный, предновогодний день, хочется написать,  что-то неформальное, не касающееся тестирования и обеспечения качества. Сегодня утром, дочитав последние страницы замечательной книги Тома ДеМарко «Deadline: Роман об управлении проектами»,  я задумался о том, что я хочу получить и достичь в наступающем 2011 году. Вспомнил уходящий 2010й, с его огромным количеством событий, которые, иногда, просто переворачивали мое мировоззрение и заставляли делать, такие вещи, о которых буквально год назад я только иногда мечтал. Интересная мысль «А почему так происходит? Почему бывают ситуации, в которых человек может сделать что либо, о чем он год назад только мечтал,  а иногда человек так и остается мечтать и не может сделать даже шага на встречу к своей мечте.» Мне кажется, что человек должен найти какой-то свой катализатор, что-то такое  что «пнет его» и движение вперед начнется. Мне это напоминает  первое движение снега, из-за которого начинается лавина, или первую карт [...]

Перевод интервью с Семом Канером(«Большинство образовательных курсов по тестированию обычно проваливаются»). Часть 3я

uTest: Даже в далеко неидеальных экономических условиях, в которых мы сейчас живем, тестирование ПО, как профессия, находится на гребне волны. Как Вы думаете, почему так происходит,  какой бы Вы дали совет  человеку, решившему связать  свою профессиональную карьеру с тестированием. Kaner: Вырабатывать в себе навыки, которые будут важны вашему (нынешнему или будущему) работодателю и начать использовать их как только вы получите желаемую работу. Быть готовым продемонстрировать компетентному интервьюеру,  что Вы знаете как сделать, что-то сложное, это ценится намного дороже, чем просто рассуждать о чем-то или давать чему-то определения. uTest: Джеймс Бах (James Bach), учувствовавший в одной из предыдущих серий наших интервью, отзывался довольно резко, о обучении тестированию в ВУЗах. Тем не менее, когда мы последний раз брали у него интервью, он упомянул Вас как, великолепное исключение из правил. Что же так отличает Ваши ме [...]

Тест дизайны, что? где? когда? зачем?

Напомню, что в прошлых двух частях я писал о характерных чертах safety critical проектов, а также о роли статического тестирования в таких проектах В этой части я опишу свой опыт работы с тест дизайнами. Не хочется долго распространяться о том, что такое тест дизайны и для чего они предназначены. Остановлюсь на этой теме буквально в двух словах. Тест дизайн это документ описывающий стратегию и методы составления тест кейсов.  В соответствии со стандартом IEEE 829, этот документ должен содержать следующие пункты:

• Идентификатор тест дизайна
• Функции, подлежащие тестированию (Список функции, которые будут протестированы с помощью данного тест дизайна. Этот список должен браться из полного списка функции, подлежащих тестированию из Тест Плана.). Также это могут быть конкретные требо� [...]
  
  

Статическое тестирование, ведь это, то чем занимается и бизнес аналитик, да?

Недавно проводил вебинар для сотрудников HR отдела компании, в которой работаю. Рассказывал о тестировании вообще, из каких, базовых, процессов, практик и активностей оно состоит. Рассматривая понятия статического тестирования и сопутствующие активности в виде различных типов инспекций и ревью, у слушателей возник вопрос-комментарий «Ведь это то чем еще занимается и аналитик, да?». Этот вопрос навел меня на мысли, которыми я хочу поделиться. Инженерия требований - это довольно сложный и тяжеловесный процесс, который требует плотного взаимодействия всех заинтересованных сторон, включая заказчика. И бизнес аналитик и инженер по обеспечению качества, несомненно, должны принимать участие в разработке требований. Разница в том, под каким углом смотрят на требования BA и QA специалисты. Одна из задач бизнес аналитика - это превращение пожеланий заказчика в реализуемые технические требования.

Горизонтальный парадокс

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

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

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

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

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

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

IMHO правильной стратегией является введение нескольких  видов карьерных путей в компании: горизонтального и вертикального.

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

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

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

Перевод интервью с Семом Канером(«Качество это то, что делает клиентов счастливыми»). Часть 2я

Jerry Weinberg определяет качество как «ценность для индивидуума». Это субъективно, как например и чувство сладости. Термин «Качество» не является производным от термина «Количество», но это ни в коем случае не делает «качество» менее реальным и ценным.

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

Позвольте мне рассказать о другой моей профессии – я начал работать в Силиконовой долине в 1983 году. Я был свидетелем многих взлетов и падений огромных компаний. Общая тенденция была в том, что компании давали ложные обещания потребителям, выпу [...]

Перевод интервью с Семом Канером("Получайте удовольствие, используя ваши метрики"). Часть 1я

Существует замечательнй портал uTest , который взял серию обширнейших интервью у мирового гуру в области тестирования Программного Обеспечения - Сема Канера(Cem Kaner).  
Я не смог обойти стороной такой кладезь знаний и решил что переведу серию этих статей на русский язык. Так как информации очень много, то переводить я буду частями. Итак первая часть интервью перед Вами.

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

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

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

Поэтому я не вижу «других областей знаний» или еще чего то.

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

Особенности тестирования Safety Critical систем. Part 2

В этой части хочу поговорить  статическом тестировании, которое, как правило, играет очень важную роль в процессе тестирования Safety Critical проектов. Собственно, что такое статическое тестирование. В двух словах это тестирование, которое не подразумевает выполнение кода программного продукта. В основном это различного вида инспекции и анализ кода. Стоит упомянуть, что Safety Critical  системы характеризуются различным уровнем критичности и в зависимости от этого уровня глубина тестирования может варьироваться. Хорошим примером различных уровней критичности может выступать американский стандарт DO178B (его европейский аналог ED-12B).

Инспекции

Основываясь на различной степени критичности проектов, практикуют следующие виды инспекций:

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

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

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

Неформальная инспекция – не документированный или мало документированный процесс,  в рамках которого происходит так называемые peer to peer reviews(один сотрудник просматривает документ или код разработанный другим сотрудником)

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

Самые распространенные техники это техническая инспекция и Walkthrought. Причины в том, что этот микс наиболее оптимален с точки зрения усилий затраченных на внедрение использование на проекте.

Статический анализ кода

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

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

Покрытие переходов между состояниями – третья разновидность, используемая для анализа программного кода, проводит проверку на покрытие всех переходов между состояниями. Можно сказать что в каком то роде, эта техника объединяет в себе 2 предыдущие. Так же автоматизируется.
Существует большое количество техник, которые родились в результате миксования основополагающих. Об этом стоит писать серию отдельных статей.
Дополнительные техники
Хорошей практикой длинных и долгоиграющих проектов, коими, несомненно, являются Safety Critical проекты, можно назвать написание Тест Дизайнов.
О тест дизайнах мы поговорим в следующей части[...]

Требования к организации требований

Вступление
Начиная с середины 20го века технический прогресс набирает обороты с неимоверной скоростью. В 21 веке человек живет в мире изменений все постоянно меняется, возникают инновационные продукты, системы, структуры, мир давно перешел в так называемую информационную эру. Нашу жизнь в информационной эре можно сравнить с шумной и быстрой горной рекой, казалось бы, как среди этих бурлящих и сносящих все на своем пути, потоках информации, можно говорить о каких либо требованиях к проектам, продуктам, процессам. На самом деле все немного сложнее, чем кажется на первый взгляд. С одной стороны типичный потребитель любых услуг 21го века довольно привередлив и скептичен при выборе. Это понятно и объясняется конкуренцией на рынках, уровнем качества предоставляемых услуг, рекламными мероприятиями, способами реализации и т.д. С другой стороны в мире постоянных изменений очень сложно поддерживать актуальными требования к чему либо. Есть лишь одна аксиома – «Требования должны быть» в остальном, говоря о виде и качестве требований, ситуация довольно не однозначна и естественно вариантов ответов и развитий событий очень много.

Framework для требований
Существует множество разновидностей требований, как то бизнес требования, пользовательские требования, технические требования к продукту, технические требования к проекту, требования к процессам, маркетинговые требования и т.д., естественно, что эти требования в свою очередь подразделяются на более мелкие подгруппы. Думаю понятен тот факт, что не каждый проект на планете Земля обязательно должен иметь все виды, под виды и подвиды подвидов требований, для того чтобы выйти в свет и успешно продаваться.
Человеку или организации решающейся на выпуск нового продукта (как hardware так и software) при формировании требований на помощь приходят стандарты, методологии, frameworks, best practices, workshops, lessons learned etc.
Есть несколько базовых требований к требованиям, которые должны быть соблюдены в самом начале формирования спецификаций[...]

Fun: Нестандартные automatic email replies.

 Вот недавно задумался как же быстро может распространяться информация по "сарафанному радио" с помощью всемирной сети Интернет.
Результаты такого распространения Вы можете лицезреть ниже ))

1. I am currently out of the office at a job interview and will reply to you if I fail to get the position. Please be prepared for my mood.
2. You are receiving this automatic notification because I am out of the office. If I was in, chances are you wouldn't have received anything at all.
3. Sorry to have missed you, but I'm at the doctor's having my brain and heart removed so I can be promoted to our top management team.
4. I will be unable to delete all the emails you send me until I return from vacation. Please be patient, and your mail will be deleted in the order it was received.
5. Thank you for your email. Your credit card has been charged $5.99 for the first 10 words and $1.99 for each additional word in your message.
6. The email server is unable to verify your server connection. Your message has not been delivered. Please restart your computer and try sending again. (The beauty of this is that when you return, you can see who did this over and over and over...)
7. Thank you for your message, which has been added to a queuing system. You are currently in 352nd place, and can expect to receive a reply in approximately 19 weeks.
8. Hi, I'm thinking about what you've just sent me. Please wait by your PC for my response.
9. I've run away to join a different circus.
10. I will be out of the office for the next two weeks for medical reasons. When I return, please refer to me as 'Lucille' instead of Steve.

Вебинар Six Lessons in Software Quality by Rex Black

Рекс Блек продолжает раздавать плюшки подписчикам своего сайта 15 го декабря пройдет его вебинар под названием "Six Lessons in Software Quality". Собираюсь поучавствовать и обязательно напишу отчет по этому вебинару.
Кто не знает кто такой товарищ Рекс, то вам сюда "Блог Рекса Блека"
В двух словах...Этот человек основал одну из крупнейших консалтинговых компаний в Америке, они специализируются на бизнес консультациях в сфере обеспечения качества. Рекс автор многих книг по тестированию, так же он входит в орг. комитет ASTQB, и является автором пособий при подготовке к сдаче ISTQB и ASTQB сертификаций.

Непоколебимая вера в Capture & Playback

Читаю книгу "Advanced Software Testing - Vol. 2: Guide to the Istqb Advanced Certification as an Advanced Test Manager" написанную товарищем, которого я уважаю больше всех среди гуру QA,  Рексом Блеком. Дочитывая главу о инструментах автоматизированного тестирования мне запомнилась одна цитата:

Unrealistic expectations for the tool. This is extremely common, especially in organizations with limited previous experience with test automation. Because software engineering is so hard—including the testing part of the software process—people are always looking for silver bullets, magic solutions to make it simple. This desire for some simple answer makes people easily deluded—or self-deluded—into thinking that some new process methodology, new programming language, new management technique, or, yes, new tool will magically transform the hard problem of testing into one that is easy. Test tools do not do that. So make sure that people have proper expectations, including functionality and ease of use.

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

Мне вспомнилась история из моего опыта работы на одном небольшом веб проекте. Я был ответственным за организацию тестирования веб портала для внутреннего использования в медицинских учреждениях. Дев Лид проекта - дядька умудренный не одним 10ком лет опыта продавливал свою политику что нам нужна тулза для покрытия функционала всего веб портала автоматизированными тестами. При этом компания не выделяла деньги на покупку того что хотел я (Test Complete enterprise). Политика партии двигалась в сторону бесплатных инструментов с лозунгом "Нам всего лишь нужно записать основные use cases а потом проигрывать их после каждого релиза с помощью инструмента автоматизации. Я имел время на анализ бесплатных инструментов. Естественно не один инструмент нам полностью не подходил, везде были свои нюансы, проведя полный анализ, я сделал презентацию для представителя клиента (тест менеджера со стороны клиента), в которой заставил его задуматься о целесообразности использования Capture&Playback. В конце концов клиент отказался от автоматизации и проект был отдан в руки тестировщиков для manual тестинга.

Особенности тестирование safety critical систем. Part 1

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

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

Существует несколько характерных признаков Safety Critical систем, непосредственно влияющих на процесс тестирования.  Давайте поговорим о них

·         Соответствие стандартам отрасли

·         Огромное количество требований

·         Формализация и отчетность

·         Вялая текучесть процесса разработки и тестирования

И так давайте взглянем на эти признаки под большим приближением.

Соответствие стандартам отрасли

Разработка ПО, которое будет воздействовать или влиять на любой вид человеческой активности ВСЕГДА сопряжена со стандартизацией. С одной стороны, это понятно, например, спросите себя, насколько Вы хотите быть уверены в своей безопасности, заходя в лифт или садясь в самолет.  С другой стороны стандартизация всегда связана с внешними аудитами процессов разработки и тестирования, дополнительной, более глубокой степенью покрытия требований тестами, более специфическими требованиями к специализации и сертификации специалистов, работающих над разработкой и тестированием  и т.д. Самыми известными организациями по стандартизации являются ISO, IEEE, FDA.

Огромное количество требований

Повторюсь, когда от действий и логики системы зависит здоровье и жизнь человека, то лучше иметь много требований. Все требования должны быть покрыты тестами, и, глубина покрытия регулируется стандартами отрасли, требованиями заказчика ну и конечно бюджетом. Хорошей стратегией работы отдела тестирования в случае, когда требований очень много (для меня очень много начинается от 5000, предположу, что в большинстве проектов количество требований не пересекает отметку в 1000) считается написание Тест Дизайнов перед написанием тест кейсов.

Формализация и отчетность

Любая активность отслеживается контроль за изменениями и конфигурационный менеджмент это слова, которые должны неотступно следовать за safety critical проектами. В тестировании вся документация обязательно должна быть формализирована так как она практически всегда подпадает под пристальный взгляд внешних  аудиторов. Внешний вид тестовой документации разнится в зависимости от требований стандартов. В своей профессиональной карьере я встречал как тест кейсы размером в несколько сотен шагов (медицинская сфера), так и обычные тест кейсы привычные для взгляда тест инженерам СНГ, размерами до 30 шагов и имеющими как один инпут так и один аутпут.

 Вялая текучесть процесса разработки и тестирования

В большинстве своем safety critical системы разрабатываются следуя Waterfall или Итерационным моделям разработки с длинными итерациями, конечно, везде есть свои исключения (например, я встречал проекты работающие в медицинской сфере работающие по SCRUMу). Такие жизненные циклы разработки не предусматривают быстрой реакции на изменения, да и не претендуют на выпуск продукта через 3 месяца после начала проекта. Можно выделить особенность, что тестирование в начальных стадиях проекта проходить на основе прототипов и симуляторов. А так же в начальных стадиях проекта очень много вкладывается в статическое тестирование.

To be continued…