Test Maturity Model: как тестировщику оценить проект и спланировать процессы
Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.
Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.
Первым делом вам стоит понять, на каком вы проекте
Накопив опыт от участия в проектах, я бы условно разделил их на 3 вида:
Что такое 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. Без тестирования
На мой взгляд, проекты такого типа могут быть в трех случаях:
Кейс № 3. Тестирование было
По правде говоря, наиболее редкий кейс: человек в силу тех или иных событий, решил сменить команду/отдел/работу и передает вам свои наработки. В такой ситуации у вас уже есть налаженная система взаимодействия с разработчиками, определенная база тестовой документации. Дальнейшими путями развития может быть как улучшение устоявшегося процесса, так и продвижение к третьему уровню — внедрять тестирование на более ранние этапы или добавлять нефункциональное тестирование.
Кейс № 4. Три в одном
Когда я пришел на свой проект в Provectus, я столкнулся с ситуацией, в которой было всего по чуть-чуть от трех кейсов, описанных выше. Как и в кейсе № 1, первым делом необходимо было привести в порядок Jira. Как во втором случае, было решено все делать сразу качественно, чтобы сразу руководствоваться вторым уровнем. Потому я сразу начал разрабатывать тестовую документацию и внедрять тест-менеджмент инструментарий. Также постарался выжать максимум из артефактов прошлых итераций, как было в третьем случае.
Спустя совсем короткий срок, я могу смело сказать, что мы уже целенаправленно идём на третий уровень — даже подключили тестирование на этапе бизнес требований 🙂
Выводы
На моем опыте, большинство украинских проектов, а также проектов, которые не рассчитаны на длительный срок, успешно удается довести до «Go live» на 3 уровне. Но если у вас долгосрочный проект, возможности улучшать его безграничны и можно смело руководствоваться наработками высших уровней.
В заключение, я хотел бы сказать, что целью этой статьи было показать не столько то, как работать с самой классической ММ или ТММ, а то, что с ее помощью можно четко понять, на каком этапе находится проект, на который ты попал, и какие движения предпринимать, а какие не стоит. Более того, взяв за основу ее принципы, можно создать собственную модель, которую можно применять не только в разработке, но и в различных сферах жизни. И что самое главное — это проверено и работает 🙂
Тестирование на основе моделей
Картинка с unsplash.com
Обеспечение качества, оно же Quality Assurance, оно же QA, включает в себя много разных активностей, позволяющих делать продукт лучше. Незаменимая и широко известная часть этого процесса — тестирование.
Принято считать, что тестирование следует после разработки ПО. В каком-то смысле это правда: нельзя проверить работающий продукт, пока он не готов. Однако в эпоху гибких методологий только ленивый не слышал про так называемый принцип «смещения влево», или shift left — включение специалиста по тестированию в процесс разработки продукта как можно раньше.
Как это возможно?
Пара слов обо мне: меня зовут Настя Заречнева, и я обеспечиваю качество рекламы ВКонтакте. Раньше я работала в аутсорсе на самых разных проектах, выполняя роли от тест-аналитика до руководителя команды QA, поэтому не понаслышке знаю, что начинать тестирование заранее — классный способ сэкономить себе время и нервы в будущем.
Содержание
Предисловие
Дело в том, что наиболее серьезные баги, как известно, можно найти на этапе проектирования продукта. Особенно актуально это для разработки новой фичи, которая так или иначе затрагивает уже работающие компоненты. Как правило, такие взаимосвязи продумывает архитектор (или человек, выполняющий эту роль в команде), но даже работу такого опытного специалиста необходимо тестировать — как минимум из-за человеческого фактора и возможности ошибиться, как максимум из-за силы коллективного разума.
Как тестировщик может помочь в этом случае? В ситуации, когда есть макеты или спецификация, все становится проще: можно использовать готовый нарисованный интерфейс для составления тестовой документации и продумывания неочевидных, но реальных кейсов.
Если же макеты еще не готовы, или есть только функциональные требования, или, что еще интереснее, задача затрагивает не столько интерфейс, сколько логику взаимодействия между компонентами тестируемой системы, довольно легко упустить важные зависимости, касающиеся разрабатываемого решения.
Есть 2 варианта: либо учиться читать код (что не панацея, ведь даже разработчики зачастую разбираются лишь в той части системы, с которой непосредственно работают), либо искать другой существующий способ тестировать функциональные аспекты продукта.
Тут нам и приходят на помощь тестовые модели. Это не rocket science и не что-то ультрановое: аналогией с использованием тестовых моделей в разработке ПО можно считать использование схем при проектировании электроприбора или электроустановки. Даже если сама установка еще не готова, мы уже можем увидеть части системы, их связи и слабые места, — например, на изображении ниже можно заметить будущее короткое замыкание.
По сути, тестовые модели — нечто похожее: это абстрактные наглядные схемы, описывающие состояние, взаимодействия и связи системных компонентов. Единственное, что компоненты у нас чуть менее материальные, чем в примере с электротехникой, однако это не избавляет нас от вероятности ошибки, а, возможно, даже несколько ее увеличивает.
Тестирование на основе моделей (Model-Based Testing, далее MBT) — одна из техник тестирования черного ящика. В непрерывной разработке (и, как правило, частых поставках) большого продукта ошибка может стоить дорого, и именно потому, что MBT — один из проверенных и эффективных способов предотвратить ее как можно раньше, мне захотелось собрать и представить вам информацию о нем.
Что такое тестовые модели
Как мы успели разобраться, тестовые модели — это схема, наглядное описание тестируемой системы. Тестовыми моделями могут служить схемы, таблицы, диаграммы переходов состояний и в некоторых случаях даже интеллект-карты. В идеале тестовые модели должны создаваться на этапе проектирования системы (или ее отдельного компонента) и понятно демонстрировать влияние одной части ПО на другую.
Аналогично другим моделям, они должны быть в меру точны, адекватны (соответствовать реальности), универсальны (могут быть использованы неоднократно и для разных задач) и целесообразно экономичны. Последнее очень важно: не стоит применять MBT ради галочки: важно понимать цель и ожидаемый результат такого подхода. Если создание и поддержание модели занимает больше времени, чем нахождение и исправление проблем без нее, а сам продукт не планируется поддерживать в долгосрочной перспективе, лучше сконцентрироваться на более доступных методах обеспечения качества.
Основные особенности тестовых моделей в том, что их можно начинать собирать еще до фактического старта разработки, и в том, что их можно обновлять и переиспользовать при изменении системы. Таким образом, тестовая модель дает более ясное представление о системе всем участникам разработки и упрощает поддержку будущей тестовой документации, — но обо всем по порядку.
Какое отношение к математике имеют тестовые модели
Как и другие модели — достаточно близкое. В математике довольно много абстракций, поэтому без моделирования никак — вспомнить хотя бы конечные автоматы — детерминированные и недетерминированные. В классическом случае они используются для математического моделирования и описания формальных грамматик, однако если заменить состояния автомата на состояния системы, а переходы — на возможные действия в каждом из состояний, то из вот такого академического примера НКА:
мы получим грубую и пока не исчерпывающую, но уже достаточно понятную тестовую модель, — например, с вариантами пополнения баланса в рекламном кабинете ВКонтакте.
Кроме того, в проектировании тестов активно используются математические дисциплины: теория графов, комбинаторика, различные минимальные и максимальные значения. Если немного вспомнить курс матанализа в университете, можно понять, что тестовые модели — лишь одно из применений всего того, что вы уже умеете.
Плюсы и минусы тестовых моделей
Как и любой подход, MBT имеет преимущества и недостатки. Давайте рассмотрим их по порядку.
Как начать использовать тестовые модели
Мы поняли, что такое тестовые модели, откуда они взялись и что в них хорошего. Мы даже готовы к потенциальным челленджам тестирования на основе моделей. Осталось лишь сделать первый шаг. Ниже представлю один из допустимых вариантов, как это сделать.
Пример тестовой модели
Давайте немного отойдем от теории и рассмотрим на практике пример из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design», а именно диаграмму переходов состояний как иллюстрацию рабочей тестовой модели.
Тестировать будем покупку билета — например, на концерт.
Для начала, мы инициируем транзакцию: после того, как выбрали билет, мы ввели информацию о себе и перешли на страницу оплаты, в то время как система автоматически инициировала таймер оплаты. Так как нас интересует процесс оплаты и использования билета, можно сделать именно этот шаг входной точкой тестовой модели.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Что мы будем делать после этого? В идеальном случае оплатим билет, а затем распечатаем и предъявим его на входе. Отразим эти действия в нашей модели.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
После распечатывания и предъявления на входе у билета есть точка невозврата — мы использовали его на прошедшем мероприятии. Дальше билет недействителен и не может быть как-то использован, — значит, примерно здесь наш «золотой путь» и заканчивается: обозначим конец на нашей диаграмме.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Как тестировщики, мы прекрасно понимаем, что все не так просто и на каждом этапе что-то может пойти не по плану. Что будет, если пользователь отменил оплату? А если просто забыл про нее, и таймер оплаты истек, тем самым завершив сессию? Это будут 2 разных типа отмены. Добавим указанные ситуации в модель.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Еще мы помним, что покупатель может захотеть вернуть билет в момент после оплаты или после распечатывания билета, но до того, как начался концерт. Эти ситуации подходят под уже существующее состояние «Отмена по инициативе клиента», — осталось лишь добавить соответствующие переходы.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Та-дааааам! Наша небольшая, но гордая работоспособная модель готова. Двигаясь по вершинам-состояниям путем ребер-переходов, мы составляем сценарии, которые будем проверять при тестировании:
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Мы получили 5 рабочих кейсов и бонусом наглядное представление процесса. Совсем не трудно, правда? 🙂
Полезности для самостоятельного изучения
Тестирование на основе моделей — большая и интересная область, которая позволяет применять аналитические навыки для изучения системы как на уровне пользователя, так и на более глубоких слоях — например, для визуализации связей между микросервисами или таблицами в базе данных. Прелесть ее в том, что она позволяет распространять знания о системе внутри команды, достигать лучшего понимания разрабатываемого продукта, а еще порог вхождения для использования MBT достаточно невысок.
Как и любой другой подход к тестированию, она должна применяться с умом: лучше всего прикинуть время, которое сэкономит использование модели, и соотнести его со временем, необходимым для ее составления и поддержания. Модель обязательно нужно актуализировать и обновлять, иначе ее использование теряет смысл.
Конечно же, эта статья дает лишь обзорное представление о том, что такое тестовые модели и зачем они нужны. Если тема заинтересовала вас и вы чувствуете, что хотите узнать больше и, возможно, даже применить знания на практике, рекомендую обратить внимание на источники ниже.
Методологии тестирования ПО. Какую выбрать?
Как и процесс разработки, процесс последующего тестирования программного обеспечения также следует определенной методологии. Под методологией в данном случае мы понимаем разнообразные комбинации принципов, идей, методов и концептов, к которым вы прибегаете во время работы над проектом.
В настоящее время существует довольно большое количество разнообразных подходов к тестированию, каждый со своими отправными точками, продолжительностью выполнения и методами, используемыми на каждом этапе. И выбор того или иного из них может быть довольно непростой задачей. В этой статье мы рассмотрим разные подходы к тестированию ПО и поговорим об их основных особенностях, чтобы помочь вам сориентироваться в существующем многообразии.
Каскадная модель (Линейная последовательная модель жизненного цикла ПО)
Каскадная модель (Waterfall Model) является одной из наиболее старых моделей, которую можно применять не только для разработки или тестирования ПО, но также практически для любого другого проекта. Его базовым принципом является последовательный порядок выполнения задач. Это значит, что мы можем переходить к следующему шагу разработки или тестирования только после того, как предыдущий был успешно завершен. Эта модель подходит для небольших проектов и применима только в том случае, если все требования точно определены. Главными достоинствами этой методологии являются экономическая эффективность, простота использования и управления документацией.
Процесс тестирования ПО начинается после завершения процесса разработки. На этой стадии все необходимые тесты переносятся с юнитов на системное тестирование для того, чтобы контролировать работу компонентов как по отдельности, так и в комплексе.
Помимо упомянутых выше достоинств, данный подход к тестированию также имеет и свои недостатки. Всегда существует вероятность обнаружения критических ошибок в процессе тестирования. Это может привести к необходимости полностью изменить один из компонентов системы или даже всю логику проекта. Но подобная задача невозможна в случае каскадной модели, поскольку возвращение на предыдущий шаг в этой методологии запрещено.
V-Model (Модель верификации и валидации)
Как и каскадная модель, методика V-Model основана на прямой последовательности шагов. Основным отличием между этими двумя методологиями является то, что тестирование в данном случае планируется параллельно с соответствующей стадией разработки. Согласно этой методологии тестирования ПО, процесс начинается как только определены требования и становится возможным начать статическое тестирование, т.е. верификацию и обзор, что позволяет избежать возможных дефектов ПО на поздних стадиях. Соответствующий план тестирования создается для каждого уровня разработки ПО, что определяет ожидаемые результаты, а также критерии входа и выхода для данного продукта.
Схема данной модели показывает принцип разделения задач на две части. Те, которые относятся к дизайну и разработке, размещены слева. Задачи, относящиеся к тестированию ПО, размещены справа:
Основные этапы этой методологии могут изменяться, однако обычно они включают следующие:
Единственным недостатком рассмотренной методологии тестирования является отсутствие готовых решений, которые можно было бы применить, чтобы избавиться от дефектов ПО, обнаруженных на этапе тестирования.
Инкрементная модель
Данная методология может быть описана, как мультикаскадная модель тестирования ПО. Рабочий процесс разделяется на некоторое количество циклов, каждый из которых также делится на модули. Каждая итерация добавляет определенный функционал к ПО. Инкремент состоит из трех циклов:
В этой модели возможна одновременная разработка разных версий продукта. Например, первая версия может проходить этап тестирования в то время, как вторая версия находится на стадии разработки. Третья версия в то же самое время может проходить этап дизайна. Этот процесс может продолжаться до самого завершения проекта.
Очевидно, что данная методология требует обнаружения максимально возможного количества ошибок в тестируемом ПО настолько быстро, насколько это возможно. Так же, как и фаза реализации, которая требует подтверждения готовности продукта к доставке к конечному пользователю. Все эти факторы существенно увеличивают весомость требований к тестированию.
В сравнении с предыдущими методологиями, инкрементная модель имеет несколько важных преимуществ. Она более гибкая, изменение требований ведет к меньшим затратам, а процесс тестирования ПО является более эффективным, поскольку гораздо проще проводить тестирование и дебаггинг за счет использования небольших итераций. Тем не менее, стоит отметить, что общая стоимость все же выше, чем в случае каскадной модели.
Спиральная модель
Спиральная модель это методология тестирования ПО, которая основана на инкрементном подходе и прототипировании. Она состоит из четырех этапов:
Сразу после того, как первый цикл завершен, начинается второй. Тестирование ПО начинается еще на этапе планирования и длится до стадии оценки. Основным преимуществом спиральное модели является то, что первые результаты тестирования появляется незамедлительно после появления результатов тестов на третьем этапе каждого цикла, что помогает гарантировать корректную оценку качества. Тем не менее, важно помнить о том, что эта модель может быть довольно затратной и не подходит для маленьких проектов.
Несмотря на то, что эта модель является довольно старой, она остается полезной как для тестирования, так и для разработки. Более того, главная цель многих методологий тестирования ПО, включая спиральную модель, изменилась в последнее время. Мы используем их не только для поиска дефектов в приложениях, но также и для выяснения причин, их вызвавших. Такой подход помогает разработчикам работать более эффективно и быстро устранять ошибки.
Agile
Методология гибкой (Agile) разработки и тестирование ПО может быть описана как набор подходов, ориентированных на использование интерактивной разработки, динамического формирования требований и обеспечения их осуществления как результата постоянного взаимодействия внутри самоорганизующейся рабочей группы. Большинство гибких методологий разработки ПО нацелены на минимизацию рисков посредством разработки в рамках коротких итераций. Одним из главных принципов этой гибкой стратегии является возможность быстрого реагирования на возможные изменения, нежели стремление положиться на долгосрочное планирование.
Экстремальное программирование (XP, Extreme Programming)
Экстремальное программирование является одним их примеров гибкой разработки ПО. Отличительной особенностью этой методологии является “парное программирование”, ситуация, когда один разработчик работает над кодом, в то время как его коллега постоянно проводит обзор написанного кода. Процесс тестирования ПО является довольно важным, поскольку начинается даже раньше, чем написана первая строка кода. Каждый модуль приложения должен иметь юнит-тест, чтобы большинство ошибок могло быть исправлено на стадии написания кода. Другим отличительным свойством является то, что тест определяет код, а не наоборот. Это значит, что определенная часть кода может быть признана завершенной только в том случае, если все тесты пройдены успешно. В противном случае, код отклоняется.
Главными достоинствами такой методологии являются постоянное тестирование и короткие релизы, что помогает обеспечить высокое качество кода.
Scrum
Scrum — Часть методологии Agile, итеративный инкрементный фреймворк, созданный для управления процессом разработки ПО. Согласно принципам Scrum, команда тестировщиков должна участвовать в следующих этапах:
Более того, участники QA-отдела должны присутствовать на всех ежедневных собраниях, как и другие члены команды, чтобы обсудить, что было протестировано и сделано вчера, что будет протестировано сегодня, а также общий прогресс тестирования.
В то же время принципы Agile методологии в Scrum к появлению специфических особенностей:
Заключение
В заключение важно отметить, что сегодня практика использования той или иной методологии тестирования ПО подразумевает мультиверсальный подход. Иными словами, не стоит рассчитывать на то, что какая-то одна методология окажется подходящей для всех типов проектов. Выбор одной из них зависит от большого числа аспектов, таких как тип проекта, требования заказчика, поставленные сроки, а также многих других. С точки зрения тестирования ПО, для некоторых методологий характерно приступать к тестированию на ранних этапах разработки, в то время как при работе с другими принято ожидать до тех пор, пока система не готова полностью.
Если вам нужна помощь с разработкой программного обеспечения или тестированием, выделенная команда разработчиков и QA инженеров готова к работе.