Перфоманс Лаб

организация процесса тестирования
тест-менеджмент
управление
26 сентября, 2016

Основные принципы организации процесса тестирования

Время чтения: 15 мин.
26 сентября, 2016
Автор:
Александр Мешков

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

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

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

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

С чего же начинать организацию процесса тестирования?

Я выделяю 11 основных критериев в организации процесса тестирования:

  1. Цели и область тестирования
  2. Команда
  3. Управление
  4. Коммуникация и взаимодействие
  5. Методология тестирования
  6. Документированность процесса
  7. Управление рисками
  8. Измерение процесса
  9. Инструменты
  10. Тестовые среды
  11. Совершенствование процесса

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

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

  • Зачем нам нужно тестирование?
  • Что мы имеем, чтобы сделать тестирование?
  • Какие процессы нужно формализовать или создать?
  • Как и что мы должны тестировать?
Только после того, как мы получим ответы на эти вопросы, можно начинать переходить к стандартам.

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

  • ISO 29119
  • IEEE 829\1008
  • TPI Next&TMap
  • TMMI
  • ISTQB

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

Любой ИТ процесс всегда должен удовлетворять потребностям бизнеса!

Мы разберем основные критерии построения процесса тестирования.

Цели и область тестирования

Целью тестирования является обнаружение дефектов, проверка соответствия ПО заявленным требованиям, а также предоставление обратной связи о дефектах всем заинтересованным сторонам.

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

Говоря об области тестирования, мы должны прекрасно понимать, что именно нам предстоит тестировать. Это могут быть системы, компоненты, бизнес процессы. Для того, чтобы это понять, то нужно просто ответить на два вопроса:

  • Что надо тестировать?
  • Что будем тестировать?

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

Команда и управление

Команда — это самая важная составляющая процесса тестирования. Без команды вы, как руководитель, ничего не сделаете. Зачастую к формированию команды подходят несколькими подходами:

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

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

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

Коммуникации и взаимодействие

Взаимодействие, как внутри команды тестирования, так и с другими участниками процесса ЖЦПО, является неотъемлемой частью организации любого процесса, а в нашем случае процесса тестирования.

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

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

Если мы рассматриваем формализацию процесса коммуникации, то важными артефактами при его выстраивании является матрица ролей и матрица эскалации.

Матрица ролей  — позволяет правильно определять роли и обязанности всех участников процесса, а также позволяет избегать неопределенности при выполнении задач или активностей. Наиболее применяемым вариантом может служить матрица RACI.

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

Методология тестирования

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

Стандартно разделяют 2 общепринятых подхода к организации процесса ЖЦПО:

  • Каскадная методология
  • Гибкая методология

Зачастую, когда ваша компания не является стартапом, то у компании всегда определен процесс разработки ПО, который работает по одной из 2-х методологий. Каскадная — работа по длительным релизам, которые обычно могут выходить от 3-х до 12 раз в год. Гибкая — это подходы Agile, когда вся наша разработка ведется спринтами, которые могут быть от 1-го дня до 2-х недель.

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

Поэтому, можно выделить 3 подхода к тестированию ПО:

  • Тестирование, основанное на требованиях
  • Тестирование, основанное на рисках
  • Экспертное тестирование

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

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

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

Ну и куда же в методологии без видов тестирования.Для каждой системы должны быть определены необходимые виды тестирования. При выборе необходимости того или иного вида тестирования нужно обязательно учитывать критичность систем для бизнеса и цену дефекта.

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

Документирование процесса

Стоит документировать процесс или нет? Когда документировать? Нужно ли писать ненужную документацию и тратить на это время?

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

Основным стандартном по документированию процесса тестирования является IEEE 829.

К основным документам можно отнести:

  • Стратегия тестирования
  • Тест-план
  • Матрица покрытия требований
  • Тест-кейсы
  • Протоколы тестирования
  • Отчетность о тестировании
Если рассматривать гибкую методологию, то мы можем формализовать:
  • Стратегию тестирования (описывающий порядок тестирования и подход к выполнению работ по тестированию ПО)
  • Тест-план (в кратком содержании для спринта не менее 2-х недель, при меньших сроках спринта ведение не актуально)
  • Чек-листы (аналогия тест-кейсам, кратко описывающие проверки в тестировании)
Управление рисками

Управление рисками — процесс принятия и выполнения управленческих решений, направленных на снижение вероятности возникновения неблагоприятного результата и минимизацию потерь проекта (процесса), вызванных его реализацией.

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

Вести риски можно несколькими способами:

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

При заведение риска определяется его статус:

  • Идентифицирован
  • Отслеживается
  • Предотвращается
  • Реализован
  • Закрыт

Влияние и вероятность в 4-х приоритетах.

Ну и самое важное — это стратегия по работе с риском:

  • Избегание
  • Минимизация
  • Передача
  • Принятие
Далее описывается сам риск, т.е. в чем он заключается и 2 пути решения, первое и резервное, если первое решение не сработало.

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

Измерение процесса тестирования

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

Инструменты и инфраструктура

Какой же процесс тестирования без инструментов? Это получается ручной труд ради ручного труда 🙂 Я думаю многие из вас часто слышали о написании тест-кейсов в документах ворд, о построения графиков и диаграмм в экселе. Но, зачем тратить усилия, если рынок предлагает нам готовые продукты управления тестирования, такие как HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr и многие другие.
Поэтому, если вы приступили к организации процесса тестирования, то делайте этот процесс удобным и эффективным. Пишите тест-кейсы в удобных формах готовых продуктов, интегрируйте инструменты с системой управления задачами, настраивайте автоматизированное тестирование и т.д.

Подходя к выбору инструмента нужно всегда понимать:

  • Какие задачи вы планируете выполнять?
  • Какой у вас бюджет на инструменты?

Получив ответы на эти вопросы вы сможете определить наиболее удобные для вас инструменты тестирования, а возможно и разработать собственные.

Помимо инструментов управления тестирования, к инструментам тестирования также можно отнести:

  • Система управления дефектами и задачами (может включаться в систему управления тестированием)
  • Вспомогательные инструменты (для скриншотов, снятия логов, работы с БД, SOUP UI для XML и т.д.)
  • Инструменты автоматизации (TestComplete, Selenium и т.д.)
  • Системы управления знаниями (на wiki движке)

Теперь поговорим об инфраструктуре. В текущем контексте своего повествования я подразумеваю тестовые среды.

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

Стандартно я выделяю следующие типы тестовых сред:

  • Среда разработки (можно ли ее относить к тестовой?, но тем не менее)
  • Среда тестирования системы (может быть развернута одна или несколько систем, компонент, не требует серьезных мощностей)
  • Среда интеграции (полноценный интеграционная среда для проверки работоспособности сквозных бизнес процессов)
  • Среда нагрузочного тестирования (основное требования — соответствие мощностями боевому контуру)
  • Среда ПродЛайк/ПреПрод (среда для отладки готового протестированного билда, проведение инсталяционного тестирования)

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

Совершенствование процесса

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

Но это не так. Почему мы должны постоянно совершенствовать процесс тестирования:

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

2. ИТ сфера постоянно развивается. Приходят новые технологи подходы, которые всегда позволяются совершенствовать процесс тестирования.

Как говорится, совершенству нет предела!

Ну а как совершенствовать — это стандартный цикл Демминга.

Запланировали — .Сделали — Проанализировали — Скорректировали
цикл Демминга

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

Чтобы узнать подробнее о наших услугах