Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.
Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.
Накопив опыт от участия в проектах, я бы условно разделил их на 3 вида:
На момент моего вовлечения каждый из них находился на своем этапе развития. Я стал наблюдать за этими ситуациями и начал вырабатывать свое видение — как продвигать на них процессы тестирования. Спустя какое-то время я наткнулся на Maturity Model, и она легла один в один на мои наработки. Тем самым укрепилась моя вера в то, что это имеет место быть.
И тут я очень ловко вставлю цитату из «Википедии»:
Если коротко и просто, это набор моделей, которые показывают, насколько хорошо налажены процессы в организации по определенным критериям. Имея подобную оценку, можно трезво оценить, стоит ли давать тот или иной заказ тому или иному подрядчику.
Собственно, с этого и началась разработка Maturity Model. В 80-х годах министерство обороны США осознало, что не может точно оценить качество работы подрядчиков по разработке ПО. А так как это государственная структура еще и такого уровня, это неприемлемо. Деньги-то государственные, дедлайны четко очерчены, да и надежное ПО для вооружения позволит всем спать спокойнее. Исходя из этого, министерство поручило Software Engineering Institute заняться созданием подобной системы оценки и спустя год был создан первый опросник, а спустя 4 года была создана первая версия модели.
Это 5 уровней, в рамках которых и оценивается работа/надежность/стабильность предприятия.
Для тестировщиков есть своя особая ММ, ее называют ТММi. Она также содержит 5 уровней, на которых я хотел бы остановиться детальнее и рассмотреть, что характерно для каждого из них.
Первый уровень — «Начальный»
На первом уровне тестирование происходит не структурировано и хаотично. Отсутствует стабильная среда для поддержки процессов тестирования. Команда не уделяет внимание планированию и стандартам.
Главная цель — доставить продукт в срок без критических проблем, потому тестирование тут используется, лишь чтобы показать, что приложение работает без серьезных сбоев. Зачастую успех подобных проектов зависит исключительно от героизма и навыков отдельных людей, а не налаженных процессов.
Как результат:
Второй уровень — «Повторяемый»
На втором уровне тестирование становится управляемым процессом. Дисциплина и достигнутый прогресс позволяет обеспечить сохранение этих практик во время стресса. Тестирование все еще расценивается активностью, которая следует за разработкой. Разрабатываются и внедряются тест-планы, с помощью которых четко определяют, какое тестирование необходимо провести, когда и кем.
Главная цель — убедиться, что продукт соответствует заданным требованиям.
Как результат:
Третий уровень — «Определяемый»
На третьем уровне тестирование больше не расценивается как активность, идущая вслед за программированием. Тестирование полноценно интегрировано в проект. Планирование тестирования выполняется на более ранних этапах и закрепляется в мастер-плане. Внедряется нефункциональное тестирование (например, usability).
Как результат:
Четвертый уровень — «Измеряемый»
На четвертом уровне тестирование четко определенный, прочно устоявшийся и измеряемый процесс. Тестирование воспринимается как оценка и состоит из всех операций жизненного цикла разработки ПО. Внедряется практика измерения качества тестирования. Эти измерения используются для прогнозирования производительности и стоимости тестирования.
Как результат:
Пятый уровень — «Инновационный»
На пятом уровне все подходы и процессы хорошо налажены. Команда не останавливается на этом этапе, а продолжает систематически улучшать процессы, постоянно пытаясь снизить время цикла тестирования и time-to-market без снижения качества проекта. Тестирование сфокусировано на превентивности. Добавляется автоматизация для более эффективного использования ресурсов.
Как результат:
Кейс № 1. Недобросовестное тестирование
Однажды я попал на небольшой проект, где тестирование проводилось заказчиком, его друзьями или котейкой. Оценив ситуацию и взглянув на модель, мы можем понять, что мы находимся на уровне № 1 и нам стоит ориентироваться на уровень № 2 во время планирования активностей. После приведения в порядок Jira, где было огромное количество багов (из которых большинство — дубликаты или не воспроизводимы), я занялся составлением тестовой документации в виде чек-листов и налаживанием основных процессов тестирования. Таких как регрессионное тестирование и санити проверки во время крупных изменений.
Кейс № 2. Без тестирования
На мой взгляд, проекты такого типа могут быть в трех случаях:
Попав на любой из таких проектов, зачастую можно увидеть бенефит того, что он находится на секретном нулевом уровне. Мы можем перепрыгнуть первый уровень и сразу делать все качественно с толком-чувством-расстановкой, руководствуясь целями второго. Зачастую мы можем внедрить тест-планы, на основании которых будут выполняться все необходимые виды тестирования. Можно сразу же обозначить тот самый воркфлоу с командой разработчиков, которого не хватает на проектах из первого кейса.
Кейс № 3. Тестирование было
По правде говоря, наиболее редкий кейс: человек в силу тех или иных событий, решил сменить команду/отдел/работу и передает вам свои наработки. В такой ситуации у вас уже есть налаженная система взаимодействия с разработчиками, определенная база тестовой документации. Дальнейшими путями развития может быть как улучшение устоявшегося процесса, так и продвижение к третьему уровню — внедрять тестирование на более ранние этапы или добавлять нефункциональное тестирование.
Кейс № 4. Три в одном
Когда я пришел на свой проект в Provectus, я столкнулся с ситуацией, в которой было всего по чуть-чуть от трех кейсов, описанных выше. Как и в кейсе № 1, первым делом необходимо было привести в порядок Jira. Как во втором случае, было решено все делать сразу качественно, чтобы сразу руководствоваться вторым уровнем. Потому я сразу начал разрабатывать тестовую документацию и внедрять тест-менеджмент инструментарий. Также постарался выжать максимум из артефактов прошлых итераций, как было в третьем случае.
Спустя совсем короткий срок, я могу смело сказать, что мы уже целенаправленно идём на третий уровень — даже подключили тестирование на этапе бизнес требований :)
На моем опыте, большинство украинских проектов, а также проектов, которые не рассчитаны на длительный срок, успешно удается довести до «Go live» на 3 уровне. Но если у вас долгосрочный проект, возможности улучшать его безграничны и можно смело руководствоваться наработками высших уровней.
В заключение, я хотел бы сказать, что целью этой статьи было показать не столько то, как работать с самой классической ММ или ТММ, а то, что с ее помощью можно четко понять, на каком этапе находится проект, на который ты попал, и какие движения предпринимать, а какие не стоит. Более того, взяв за основу ее принципы, можно создать собственную модель, которую можно применять не только в разработке, но и в различных сферах жизни. И что самое главное — это проверено и работает :)
Но зачастую меня внедряли в небольшие команды, в которых было от 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 уровне. Но если у вас долгосрочный проект, возможности улучшать его безграничны и можно смело руководствоваться наработками высших уровней.
В заключение, я хотел бы сказать, что целью этой статьи было показать не столько то, как работать с самой классической ММ или ТММ, а то, что с ее помощью можно четко понять, на каком этапе находится проект, на который ты попал, и какие движения предпринимать, а какие не стоит. Более того, взяв за основу ее принципы, можно создать собственную модель, которую можно применять не только в разработке, но и в различных сферах жизни. И что самое главное — это проверено и работает :)
