Home

Автор: Mikhail Dovgiy

Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.

Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.

Первым делом вам стоит понять, на каком вы проекте

Накопив опыт от участия в проектах, я бы условно разделил их на 3 вида:

• проекты без тестирования;
• проекты с недобросовестным тестированием;
• проекты с тестированием.

На момент моего вовлечения каждый из них находился на своем этапе развития. Я стал наблюдать за этими ситуациями и начал вырабатывать свое видение — как продвигать на них процессы тестирования. Спустя какое-то время я наткнулся на Maturity Model, и она легла один в один на мои наработки. Тем самым укрепилась моя вера в то, что это имеет место быть.

Что такое Maturity Model

И тут я очень ловко вставлю цитату из «Википедии»:

Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности.

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

Собственно, с этого и началась разработка Maturity Model. В 80-х годах министерство обороны США осознало, что не может точно оценить качество работы подрядчиков по разработке ПО. А так как это государственная структура еще и такого уровня, это неприемлемо. Деньги-то государственные, дедлайны четко очерчены, да и надежное ПО для вооружения позволит всем спать спокойнее. Исходя из этого, министерство поручило Software Engineering Institute заняться созданием подобной системы оценки и спустя год был создан первый опросник, а спустя 4 года была создана первая версия модели.

Уровни Maturity Model

Это 5 уровней, в рамках которых и оценивается работа/надежность/стабильность предприятия.

Где в Maturity Model тестирование

Для тестировщиков есть своя особая ММ, ее называют ТММi. Она также содержит 5 уровней, на которых я хотел бы остановиться детальнее и рассмотреть, что характерно для каждого из них.

Первый уровень — «Начальный»

На первом уровне тестирование происходит не структурировано и хаотично. Отсутствует стабильная среда для поддержки процессов тестирования. Команда не уделяет внимание планированию и стандартам.

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

Как результат:

• нет тестовой документации;
• продукт нестабилен;
• отказ от процессов во время проблемных ситуаций;
• тестирование — не более чем помощь в отладке.

Второй уровень — «Повторяемый»

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

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

Как результат:

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

Третий уровень — «Определяемый»

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

Как результат:

• тестирование начинается с этапа требований;
• добавляются активности, позволяющие работать более эффективно (внутренние тренинги, дополнительные ревью);
• внедряется нефункциональное тестирование.

Четвертый уровень — «Измеряемый»

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

Как результат:

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

Пятый уровень — «Инновационный»

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

Как результат:

• продолжение улучшения процессов;
• фокусировка на превентивности и оптимизации.

Каким образом помогает знание этой структуры

Кейс № 1. Недобросовестное тестирование

Однажды я попал на небольшой проект, где тестирование проводилось заказчиком, его друзьями или котейкой. Оценив ситуацию и взглянув на модель, мы можем понять, что мы находимся на уровне № 1 и нам стоит ориентироваться на уровень № 2 во время планирования активностей. После приведения в порядок Jira, где было огромное количество багов (из которых большинство — дубликаты или не воспроизводимы), я занялся составлением тестовой документации в виде чек-листов и налаживанием основных процессов тестирования. Таких как регрессионное тестирование и санити проверки во время крупных изменений.

Кейс № 2. Без тестирования

На мой взгляд, проекты такого типа могут быть в трех случаях:

• проект только стартует;
• на проекте не было необходимости в тестировщике, пока был небольшой функционал;
• команда full-stack закрывала нехватку тестировщиков с помощью качественного code-review и dev-testing.

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

Кейс № 3. Тестирование было

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

Кейс № 4. Три в одном

Когда я пришел на свой проект в Provectus, я столкнулся с ситуацией, в которой было всего по чуть-чуть от трех кейсов, описанных выше. Как и в кейсе № 1, первым делом необходимо было привести в порядок Jira. Как во втором случае, было решено все делать сразу качественно, чтобы сразу руководствоваться вторым уровнем. Потому я сразу начал разрабатывать тестовую документацию и внедрять тест-менеджмент инструментарий. Также постарался выжать максимум из артефактов прошлых итераций, как было в третьем случае.

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

Выводы

На моем опыте, большинство украинских проектов, а также проектов, которые не рассчитаны на длительный срок, успешно удается довести до «Go live» на 3 уровне. Но если у вас долгосрочный проект, возможности улучшать его безграничны и можно смело руководствоваться наработками высших уровней.

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

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