Идеальной методологии тестирования не существу… А вот и да, существует.

Привет, Хабр. На связи Константин Синанов, директор отделения аутсорсинга экспертизы тестирования, и Александр Александров, ведущий инженер-тестировщик в IBS. В этой статье мы расскажем о системном подходе к тестированию, который применяется в нашей компании на проектах любой сложности.

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

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

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

Что такое DR3.0 и откуда она взялась

DR3.0 — это методология разработки и тестирования программного обеспечения, которую используют в IBS. Аббревиатура DR расшифровывается как Development Reengineering, «реинжиниринг разработок».

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

Методология основана на 30-летнем опыте IBS в заказной разработке. Подход несколько раз дорабатывали и улучшали, подгоняли под реалии современных трендов разработки, согласовывая с современными трендами. 

Первая версия методологии появилась в IBS еще в 2019 году. В версии DR1.0 были предложены шаблоны описания требований, макеты интерфейсов, карты компетенций, калькулятор оценки, создана база повторно используемых компонентов и проведено пилотирование версии на нескольких проектах.

В 2021 году появилась версия DR2.0. Основная идея перехода с DR1.0 на DR2.0 — сделать методологию не перечнем стандартов, «выбитых в камне», а динамичным и развивающимся набором лучших практик.

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

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

Особенности подхода к тестированию по DR3.0

Применение методологии в каждом конкретном проекте заключается в  определенной последовательности действий.

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

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

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

Такой проект характеризуется следующим набором значений атрибутов:

Организационные:

• Длительность — до 3 месяцев

• Стоимость — малая

• Тестировщиков — до 2 человек

• Нормативные требования — нет

Технологические:

• Документация — нет

• Распределенная команда — нет

• Внешних интеграций — до 2

• Тестовых сред — до 2

• Видов автоматизации — нет

Это атрибуты простого проекта.

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

Организационные:

• Длительность — более 6 месяцев

• Стоимость — огромная

• Тестировщиков — более 50 человек

• Нормативные требования — есть

Технологические:

• Документация — есть

• Распределенная команда — есть

• Внешних интеграций — более 5

• Тестовых сред — более 5

• Видов автоматизации — более 1

В качестве примера подобного проекта можно привести создание для крупного банка новой распределенной системы «с нуля» — с миграцией из старой системы данных за 25 лет и интеграцией новой системы с разнообразным ИТ-ландшафтом заказчика.

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

Для простого проекта предлагается следующий набор артефактов, распределенных по этапам:

Для очень сложного проекта набор артефактов выглядит так:

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

Процессы и артефакты

Этапы проекта — это отдельные процессы, последовательность действий в которых оформлена в виде BPMN-схемы.

Вот так, например, выглядит описание процесса «Подготовка проекта». Он одинаковый для любого проекта. 

А это — описание «Анализа требований». Этот этап есть только в сложных проектах.

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

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

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

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

Подробно о процессах и артефактах, их применении мы расскажем в отдельных статьях. Не отключайтесь!