.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

Test Maturity Model: как тестировщику оценить проект и спланировать процессы

Привет! Меня зовут Миша, и я 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 уровне. Но если у вас долгосрочный проект, возможности улучшать его безграничны и можно смело руководствоваться наработками высших уровней.

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

LinkedIn

15 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хочу сказати, шо стаття досить легко написана і гарно читається. Але, мені здається, шо люди, які працюють в тестуванні вже давно зрозуміли, шо їм нема про шо розказувати на різних конференціях і в різних статтях і тому один за одним починають придумувати різні моделі, документи, підходи і тд. Може пора вже сісти почати вчити python, або Java та почати писати авто тести ? Давайте ще згадаємо ISTQB і будемо топити за то на скільки воно важливе і як ті всі бабульки і дедульки, які писали сілабус до нього ахеренно зашибають сотні тисяч в рік, виступаючи на конфах і впарюючи шось тіпа «як юзати ексельку при регресійному тестуванні»... А потім люди, які на ті всі документи, підходи ітд ведуться, коли чують, шо сініор автомейшн може в Україні заробляти 6к баксів роблять квадратні очі і тіпа " No way ... !!!" Я от замітив таку тенденцію, шо люди які пишуть статті про мануальщину в жодній статті не використовують ніфіга з понять CI, Continuous Delivery, TDD, pipeline, automation testing, dev ops, test ops practices etc. Я канешн сорі, але майбутнє все таки за «інженерними» практиками, а не за pdf документами, які описують поверхнево підходи і лиють воду...

Тарас, дякую за комент. Проте я вважаю, що майбутнє завжди буде за міксом таких практик та технічних рішень. Мені здається, що ви ще не прийшли до думки що автоматизація це лише помічник, а не заміна мануального тестування. Саме так радикально настроєні коллєги полюбляють писати автоматизацію на проектах де ще дуже багато дир, де постійно йде девелопмент і покриття автоматизації замикається в колі полагодження або й перенаписання автотестів. А стаття є доречною для автотестерів також — вона показує що автоматизація буде працювати на високих рівнях, коли вже всі процеси є, а не з початку проекту — коли насправді є на чому сфокусуватися

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

вона показує що автоматизація буде працювати на високих рівнях

" — це суперечить Agile Testing Pyramid кагбе... )

Щодо «фігової тучі» — хіба по автоматизації не так само? 1000 й 1 стаття про «як я постменом я класно ганяю БЕ тести», чи «який классний інструмент SoapUI» (нєт). Не знаю чому вас так заділа тема, адже матеріалу щодо моделей було досить мало, а як вона вкладається на реальний досвід — геть зовсім пусто)

ну якшо Ви пишете тести на postman-і або на Soap UI тоді ...)

Статья не плохая, но описывает только одну Модель Зрелости. А есть еще как минимум не пошаговая а матричная модель TPI Next, которая на много проще к применению (практический опыт).
А вообще всем кому интересна эта тема, то 13 апреля я буду выступать с ней на конференции — kyiv.qaday.org/...​iacheslav-sakharov-2019s
Там будут охвачены несколько моделей и поделюсь опытом по применению.

спасибо, новая информация для меня

И что самое главное — это проверено и работает :)

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

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

Вот еще одна статья на эту тему dou.ua/forums/topic/19754

На www.tmmi.org/tmmi-documents два файла
• TMMi Assessment Method Application Requirements
• Data Submission Requirements
запаролены.

Это нормально вапще?

а Вы, простите, что с ними пытаетесь сделать?? ))
там нет паролей. чистые пдфки

О!

При открытии через Evince они требуют ввода пароля для доступа к содержимому.

А через адоб — открываются.

Пароль там есть — запрещено изменение и комментирование и запрет на индексирование содержимого для поисковых роботов.

У основы TMMi стоит Erik van Veenendaal, который крупно отметился и в подготовке материалов для ISTQB, и вообще автор тем, постов, комментариев и книг про всё это дело www.erikvanveenendaal.nl/en/publicaties/boeken

На сайте tmmi.org он значится в числе директоров. Спасибо за дополнительную информацию)

Подписаться на комментарии