вторник, 28 декабря 2010 г.

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

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

воскресенье, 26 декабря 2010 г.

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

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

суббота, 25 декабря 2010 г.

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

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

пятница, 24 декабря 2010 г.

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

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

среда, 22 декабря 2010 г.

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

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

воскресенье, 19 декабря 2010 г.

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

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

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

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

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

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

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

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

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

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

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

пятница, 17 декабря 2010 г.

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

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

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

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