Портал TMGuru:. Тест менеджер

10 вещей, которые должен сделать любой уважающий себя тест-менеджер

Автор: Наталья Руколь

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

1. Формируйте грамотную команду и инвестируйте в её развитие. Если Ваша команда недостаточно квалифицирована, то Вам придётся всё время решать возникающие проблемы и вникать во все вопросы. Если же Вы сформируете команду профессионалов и проявите их потенциал, то Вам останется лишь обозначать стратегические цели (которые, учитывая рост команды, также смогут непрерывно расти!).

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

3. Внедрите эффективный тест-дизайн. Если у Вас гибкие процессы с исследовательским или сессионным тестированием, то Вам будет достаточно высококлассной карты функционала, к примеру, распечатанной на большом листе ватмана и повешенной на стене. В более формальных подходах Вам потребуются тест-кейсы, при использовании которых требования к тест-дизайну ещё выше: оптимизация проверок, сокращение трудозатрат, прозрачная отчётность… Инвестируйте в продуманный и грамотный тест-дизайн, и эффективность работы Вашей команды выйдет на новый уровень!

4. Планируйте тестирование. Вы можете использовать формальные тест-планы, самостоятельно разработанную веб-систему, MS Project или экселевские таблички. Но Вам в любом случае потребуются сбор статистики по трудозатратам, минимальный тест-дизайн и глубокое понимание методологии планирования. Благодаря наличию хорошего плана Вы всегда сможете оценивать прогресс, а следовательно – необходимые меры, если что-то идёт не по плану.

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

6. Определите стратегические цели тестирования. «Если звёзды зажигают – значит, это кому-то нужно».Выявите миссию своей звезды – зачем нужно тестирование на Вашем проекте? Поставьте на основании этого конкретные стратегические цели. Это поможет не сбиваться с намеченного курса и принимать взвешенные решения.

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

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

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

10. Внедрите контроль рисков качества. Учёт рисков качества позволит сделать Ваш тест-дизайн более эффективным, а качество продукта более предсказуемым. Вы можете использовать риски качества в качестве основного инструмента тест-анализа или в качестве дополнительно способа формирования тестов. Но при любом из подходов Вам необходимо довести его до конца – «частичного» контроля рисков быть не может.

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

Командная работа (Формирование команды, делегирование, коммуникации):

· Бестселлер института Гэллопа: «Сначала надо нарушить все правила»

· Мой тренинг «Управление командой тестировщиков»

Тест-дизайн и риски качества:

· Lee Copeland: «A Practitioner's Guide to Software Test Design» – это Библия тест-дизайна. Несмотря на отсутствие перевода, её чтения является строго обязательным!

· Мой тренинг «Тест-дизайн для менеджеров»

· Тренинг Алексея Баранцева «Тест-дизайн от А до Я»

Планирование, стратегические цели тестирования, метрики:

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

· Школа Тест-Менеджеров

Пожалуйста, если у Вас есть дополнения к списку (книги и тренинги, которые Вам нравятся и которые Вы можете порекомендовать) – дополняйте!

И главное – внедряйте, радуйтесь результатами и гордитесь собой! И о результатах сообщайте – интересно же!

www.software-testing.ru

10 вещей, которые должен сделать любой уважающий себя тест-менеджер

Автор: Наталья Руколь

Командная работа (Формирование команды, делегирование, коммуникации):

· Бестселлер института Гэллопа: «Сначала надо нарушить все правила»

· Мой тренинг «Управление командой тестировщиков»

Тест-дизайн и риски качества:

· Мой тренинг «Тест-дизайн для менеджеров»

· Тренинг Алексея Баранцева «Тест-дизайн от А до Я»

Планирование, стратегические цели тестирования, метрики:

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

· Школа Тест-Менеджеров

И главное – внедряйте, радуйтесь результатами и гордитесь собой! И о результатах сообщайте – интересно же!

www.software-testing.ru

Об исследовательском тестировании в Microsoft Test Manager 2012 / Хабр

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

Требования к инструменту

На мой взгляд, такой инструмент должен:

Быть интегрирован с системой баг-трекинга, чтобы можно было заводить дефекты по мере их обнаружения
Автоматически документировать обнаруженный дефект. Это важно, когда тест идёт не по сценарию, а в произвольной последовательности, которую невозможно держать в голове

Обеспечивать возможность повторения последовательности исследовательского теста
Быть интегрирован с системой управления требованиями — чтобы по возможности привязывать обнаруженные дефекты к требованиям
Быть интегрирован с системой управления тестами, чтобы:

проводить все виды тестирования в единой среде
создавать новые сценарии тестирования на основе исследовательских тестов

Собственно, оптимальным вариантом в этом смысле будет наличие поддержки исследовательского тестирования в интегрированном инструменте управления требованиями, тестами и дефектами. Об одном из таких инструментов — Microsoft Test Manager 2012 — я и хочу рассказать. В 2012-й версии MTM появилась поддержка исследовательского тестирования. Способы применения этого функционала мне видятся следующие:

Проведение исследовательского тестирования в дополнение к тестам по сценариям
Проведение тестирования в условиях отсутствия сценариев тестирования
Быстрое создание новых сценариев тестирования через сеансы исследовательского тестирования

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

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

Запустим MTM, выберем проект и откроем план тестирования. В проекте может быть несколько планов тестирования, поэтому требования, сценарии тестирования, дефекты и т.д. хранятся в общем хранилище TFS, а план тестирования позволяет организовать работу с некоторыми из них.

Наш план тестирования может быть совсем пустым, но мы рассмотрим сценарий, когда у нас есть несколько требований и мы добавили их в план (кнопка «Add requirements» — активна, когда выбрана корневая папка или подпапка, Suite). Когда мы добавляем в план требование, для него создается папка, в которую автоматически добавляются все связанные с требованием сценарии тестирования. Здесь же мы можем добавить другие сценарии (кнопка «Add») или создать новые (кнопка «New»). Здесь и далее я использую термин «Требование», хотя его конкретная реализация в TFS может отличаться в зависимости от выбранного шаблона. Это будет «User Story» для Agile, «BacklogItem» для SCRUM, «Requirement» или ещё какой-нибудь тип из категории требований для разных шаблонов.

Сессия исследовательского тестирования

Перейдем к исследовательским тестам. Для этого переключимся на закладку «Test» и дальше откроем пункт «Do Exploratory Testing».

Здесь у нас две ключевые возможности — запустить сеанс исследовательского тестирования («Explore») и запустить сеанс исследовательского тестирования для выбранного требования из списка входящих в текущий план («Explore work item»). Разница между этими двумя опциями довольно проста: если мы выбираем исследуемое требование, то созданные потом артефакты (результаты тестирования, дефекты, сценарии тестирования) будут автоматически привязаны к этому требованию. Выберем вариант «Explore work item». Откроется окно оснастки тестирования. Этот инструмент позволит нам собирать информацию о ходе исследовательского тестирования. Когда будем готовы, нажмём кнопку «Start», наш инструмент активизируется.

Правая часть рабочего стола остаётся свободной для работы с тестируемым Web- или Desktop-приложением, а в нашей оснастке мы можем оставлять комментарии по ходу тестирования, добавлять скриншоты, управлять ходом записи действий. В процессе тестирования также могут записываться: — видео происходящего на экране — голосовые комментарии — действия (actions), выполняемые в пользовательском интерфейсе — отладочная информация Intellitrace — другие данные, собираемые Diagnostics Adapters (см. ниже про их настройку)

Итак, у нас есть Web-приложение и мы тестируем его поведение. Пользователь открыл сайт, выбрал товар, добавил его в корзину, ввёл промо-код, нажал чудо-кнопку Go и ничего не произошло. Мне кажется, что это дефект, поэтому я пишу в комментариях «Нет реакции на кнопку Go» и прикладываю скриншот («Add screenshot»). На первый взгляд, малоинформативно. К сожалению, именно так тестировщики частенько документируют дефекты. Когда они начинают писать нормальное описание, их переименовывают в специалистов по качеству (QA Engineer). Однако, посмотрим, что может сделать современный инструментарий.

Создание отчета об ошибке.

Кнопкой «Create Bug» создадим новый отчет об ошибке:

И вот тут-то мы понимаем, зачем в исследовательском тестировании нужен MTM: Дефект уже практически сам задокументирован: — автоматически записана последовательность действий (шаги 1-7) — сформировано описание дефекта из введенных комментариев и скриншотов — приложена собранная системная информация — приложен лог Intellitrace — приложена видеозапись происходившего на экране

Теперь специалисту по качеству нет нужды вспоминать, что же он делал для того, чтобы получить ошибку. Все ходы записаны. Разработчику будет очень легко воспроизвести последовательность шагов и очень трудно отклонить ошибку со словами «а у меня всё работает», глядя на видеозапись.

Создание сценария тестирования

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

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

Сохранённые сессии исследовательского тестирования

Информация о сессиях исследовательского тестирования может сохраняться, даже если не было обнаружено дефектов. Посмотреть их можно на закладке View Exploratory Test Sessions

Можно открыть детальное описание сессии и просмотреть собранные данные

Такие же данные (Test Result) собираются системой и при проведении других типов тестов.

Настройка собираемой информации

Кратко посмотрим настройку параметров собираемой информации в ходе тестирования. В MTM мы можем создать и использовать несколько конфигураций тестирования, включая не только локальные профили, но и профили для сложных тестовых сред, включающих несколько машин, что позволяет, например, собирать протоколы происходившего и на серверах приложений, и на клиентском рабочем месте, и на других машинах, входящих в тестовую среду. Для настройки переключаемся из режима «Testing Center» в «Lab Center» и открываем закладку «Test Settings»

Выберем одну из конфигураций и посмотрим её настройки для одной из ролей машин, входящих в тестовые среды:

Достуны несколько базовых адаптеров сбора данных:

IntelliTrace — сбор исторического протокола исполнения приложений. Статьи на Хабре.
EventLog — сбор событий из журнала событий Windows
System Information — сбор данных о конфигурации операционной системы
Test Impact — сбор данных об исполняемых в ходе теста строчек кода приложений. Используется для выявления тестов, на которые могли повлиять новые изменения в системе версионного контроля (хорошая тема для статьи, правда?)
Video Recorder — запись происходящего на экране в видеофайл. Есть настройки битрейта и уровня качества. Можно также писать звук.
Action Log — запись операций с пользовательским интерфейсом.

Последний пункт требует пояснений. Система действительно распознает, какие кнопки были нажаты, какие ссылки открыты, какие поля заполнены, и т.д. Причем, этот механизм используется в нескольких местах: в инструментах описания автоматических тестов пользовательского интерфейса (Coded UI Test), в системе частичной автоматизации ручных тестов, а также при проведении исследовательского тестирования. Поддерживаются приложения Windows Forms 2.0, Win32, WPF, Silverlight, Web и HTML5 через IE8-10 и некоторые другие. Есть и неподдерживаемые технологии — Flash/JAVA, SAP, Lotus Notes. Ряд технологий поддерживаются через дополнительные расширения.

Заключение

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

habr.com

10 вещей, которые должен сделать любой уважающий себя тест-менеджер - Портал TMGuru

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

6. Определите стратегические цели тестирования. «Если звёзды зажигают – значит, это кому-то нужно». Выявите миссию своей звезды – зачем нужно тестирование на Вашем проекте? Поставьте на основании этого конкретные стратегические цели. Это поможет не сбиваться с намеченного курса и принимать взвешенные решения.

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

Командная работа (Формирование команды, делегирование, коммуникации):

· Бестселлер института Гэллопа: «Сначала надо нарушить все правила»

· Мой тренинг «Управление командой тестировщиков»

Тест-дизайн и риски качества:

· Lee Copeland: «A Practitioner’s Guide to Software Test Design» – это Библия тест-дизайна. Несмотря на отсутствие перевода, её чтения является строго обязательным!

· Мой тренинг «Тест-дизайн для менеджеров»

· Тренинг Алексея Баранцева «Тест-дизайн от А до Я»

Планирование, стратегические цели тестирования, метрики:

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

· Школа Тест-Менеджеров

И главное – внедряйте, радуйтесь результатами и гордитесь собой! И о результатах сообщайте – интересно же!

на Ваш сайт.

tmguru.ru

Если вы стали QA-менеджером

Автор: Юлия Нечаева

Представляю перевод статьи Джеймса Виттакера "Если вы стали QA менеджером". Оригинальному тексту почти год, я прочла его первый раз как раз, когда сама оказалась на месте героя поста. За это время у меня появились комментарии к мнению Джеймса, поэтому, можно сказать, что мы соавторы получившейся статьи.

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

Начните жить своим продуктом!

Джеймс:Итак, вы оказались новым QA менеджером. Первое, что вам нужно сделать, это начать жить своим продуктов, загореться им.

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

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

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

К примеру, я сейчас живу без лаптопа и использую в своей повседневной работе только Chrome OS Netbook. Так как люди видят меня с ним в коридорах, мне доводится произносить рекламные спичи по многу раз каждый день. Великолепная практика, скажу я вам! Мне же доводится жить и с огрехами, и записывать штуки, которые ещё надо доделывать. Это хворост для пламени спора между разработчиками и другими стейкхолдерами, и это тоже заставляет меня взвешивать конкурирующие продукты. Когда у меня не получается сделать что-нибудь, что мне нужно, на моем Chrome OS Netbook и я вынужден использовать конкурирующий продукт, это порождает здоровую дискуссию о том, как пользователи воспринимают недостатки наших продуктов, и о том, как мы можем правильно преподнести плюсы и минусы нашего продукта потребителям.

И это прекрасный путь для начинания нового продукта, кстати ;-)

Юля:Если вы приходите не просто в продукт, выпускаемый вашей компанией, а в новую компанию, начните жить вашей компанией. Её культурой. Поймите, почему она выпускает именно такие продукты. Чтобы приносить людям пользу, чтобы отвечать на их вопросы, чтобы решать их проблемы? Чтобы веселить их? Чтобы что?

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

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

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

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

Фокусируйтесь на тест-плане, сделайте это высшим приоритетом

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

Объясню, что я имею ввиду под этим.

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

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

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

Тест-план стал в точности, как спецификация: Документ-Который-Был.

Юля:Тест-план (как и все тестирование, конечно же), может работать на вас, а может на продукт. Иными словами, часто хочется применить все свои теоретические знания и накопленный опыт и отразить все предыдущие годы работы в документе под названием Тест-План-Всего.

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

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

Если вы делаете его для того, чтобы потешить свое чувство сертифицированного тест-менеджера – будьте честными в этом признаться. Хотя бы себе.

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

Разберитесь с процессом и приоритетами релиза

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

Юля:Будьте всегда готовы ответить себе, команде и инвесторам, почему этот баг встретился 20 процентам пользователей и породил тысячи петиций. Почему вы не наняли ещё троих тестировщиков, чтобы протестировать тщательно все области, а не только самые приоритетные? Почему вы держите именно такой баланс между знанием о качестве и затратами на его контроль? Почему вы в последний момент кинули все силы на эту область, хотя в недельной давности тест-плане она шла вторым приоритетом?

Главное, чтоб вы четко понимали это сами.

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

Я обнаружил, что в Гугле увеличение фокуса команды на мануальном тестировании искренне приветствовалось командой разработчиков. Найдите комфортную зону вашей команды разработки и удерживайте баланс между тем, чтобы всё-таки правильно тестировать, и тем, чтобы сделать финальные часы (дни) как можно безболезненнее.

Тестируйте ваш процесс тестирования

Джеймс:Начните с чтения каждого теста-кейса и просмотра всей информации. Можно ли привязать эти тесты к тест-плану? Сколько тестов у вас есть на один компонент? А на фичу? Если баг находится за пределами процесса тестирования, создаете ли вы на него тест-кейс? Есть ли у вас процесс исправления или выбрасывания испорченных или неактуальных тест-кейсов?

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

Юля:Чем критичнее вы относитесь к своей работе, тем больше у вас права критично относиться к чужой. Считается, что тестировщик не должен ошибаться и не должен пропускать баги. В то время, как программисту вполне позволено их делать. Чтобы изменить это мнение, нужно действительно крепко тестировать не только работу программистов, но и свою собственную. Вы должны всегда видеть ещё возможности протестировать что-то лучше, тщательнее, если представится такая возможность. И вы должны четко понимать, от чего вы осознанно отказываетесь. И уметь объяснить это всей команде.

Чем более требовательны вы к своим тестам, тем более требовательными у вас получится быть к разработчикам.

Ищите пути для инноваций

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

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

Юля:Очень важно выдерживать баланс между «так у нас принято» и «я знаю, как сделать лучше». Когда вы приходите в новой роли в новую команду, у вас есть огромный плюс и страшное оружие: «свежий взгляд». Если его применять правильно – вы взорвете тестирование на проекте (в хорошем смысле). Будьте готовы столкнуться с «это не заработает, потому что…», «мы это пробовали, это фигня…», «да ну , бред какой-то, лучше делать по-старому…». Жизненно важно отличать реальные причины того, почему здесь делается именно так, от пустых отговорок, за которыми люди скрывают привычку и нежелание двигаться.

Если вы возьмете правильный опыт этой команды и дадите ему новое дыхание – будет бомба!

Джеймс:Нет совета, который мне показался бы универсально применимым касательно "Как лучше внедрять новшества". Что работает для меня – так это найти звезд в своей команде и убедиться, что они работают над тем же, чем горят. Как менеджер, это одна самая важная штука, которую вы можете сделать, чтобы повысить продуктивность и внедрить новшество.

Юля:Так что - дерзайте! И удачи вам.

Обсудить в форуме

www.software-testing.ru

различия в мотивации и перспективах

Автор: Шрини Кулкарни (Shrini Kulkarni)

Оригинал статьи: http://shrinik.blogspot.ru/2016/12/test-manager-vs-project-manager.html

Перевод: Ольга Алифанова

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

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

Рядом со мной сидит мой друг и коллега, прожект-менеджер. Он вечно взволнован. Каждый раз, когда кто-то из моей команды просит разъяснений, у менеджера сбивается сердечный ритм, потому что он думает – о боже, нет, они нашли еще один баг! Во время наших встреч, посвященных багам, я гордо говорю, что сегодня мы нашли 40 новых багов, то есть всего за эту неделю – 370, 80 из которых критические! ПМ, придя в себя, отвечает – ок, какие из исправленных багов уже прошли ретест? Какие области приложения относительно стабильны? Что хорошего мы можем сообщить нашим заказчикам?

Видите разницу подходов? ПМу важно знать, что работает, что именно работает хорошо, и о чем хорошем мы можем сообщить. Тест-менеджеру хочется похвастать новыми проблемами, найденными командой. Для тестировщика неплохо бы побыть в шкуре ПМа или разработчика, чтобы понять, как мыслят эти ребята.

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

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

Напряжение между разработкой, тестированием и управлением проектами появляется именно из-за этой разнице в перспективе, мотивах и нехватке коммуникации по проекту в целом.

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

Это сплотит вашу команду и вас будут называть "зрелым тестировщиком".

Обсудить в форуме

www.software-testing.ru

Способны ли Вы стать менеджером?

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

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

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

Подсчет очков

За каждый положительный ответ на вопросы 1, 2, 3, 4, 5, 7, 8, 23, 25, 30 и отрицательный — на остальные вопросы записывается по 1 очку.

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

При сумме 10—21 очков можно говорить о возможности стать со временем хорошим менеджером. Но все же ваш выбор в большей степени продиктован рекламой и модой, чем внутренними побуждениями. Внимательно проанализируйте результаты тестов этой главы: может быть, вам и стоит потратить усилия на развитие способности к управлению. Но для этого потребуется пройти хороший курс социально-психологической подготовки.

Если сумма выше 22 очков, то вы на правильном пути и, скорее всего, точно угадали свое призвание. А если результат выше 26 очков, то вы прирожденный ме-неджер. Хотя учиться и совершенствоваться в условиях конкуренции всегда необходимо (что вы и сами прекрасно знаете). Желаем успеха!

bgumanagement2009.narod.ru