Применение TMMI для оценки и совершенствования процессов обеспечения качества ПО

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

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

На удивление, на DOU нет никаких упоминаний о TMMI. Я решил написать небольшую статью на эту тему. Мои знания по этой теме чисто теоретические, поэтому у статьи две цели:

• в общих чертах рассказать о фреймворке;
• получить комментарии или рекомендации от тех, кто возможно использовал TMMI.

Почему TMMI показался мне интересным

Если кратко, то к преимуществам TMMI я бы отнес:

• легкость и простоту
• открытость и доступность
• узкую направленность
• четкую структуру

Рассмотрим преимущества детальнее.

Я считаю TMMI простым для понимания потому, что с его помощью специалист не очень высокого уровня может провести экспресс-оценку качества процессов тестирования и выявить слабые стороны. В отличии от тех же стандартов ISO серии 9000 или Six Sigma, TMMI оперирует широко известными в области тестирования понятиями и сущностями, взятыми из ISTQB, а так как ISTQB является де-факто стандартом в отрасли, то для большинства тестировщиков не сложно разобраться в TMMI.

Что касается открытости и доступности, то в отличие от других стандартов, вся документация свободно скачивается на официальном сайте организации. В случае, например, со стандартами IEEE это не так. Так же никто не заставляет вас сертифицироваться. Вы можете просто использовать рекомендуемые подходы.

Далее к преимуществам я отнес узкую сферу применения TMMI. Возможно, выглядит немножко парадоксально, так как обычно наоборот универсальность считают преимуществом, но чем более универсальным будет описание чего-либо, тем более оно будет абстрактным и размытым. Взять хотя бы тот же ISO 9001. Без глубокого погружения достаточно сложно понять, как использовать этот стандарт. Частично, думаю, причина в его универсальности, так как он используется во многих сферах жизни.

Также к плюсам я отнес структуру, потому как она показалась достаточно прозрачной. Авторы решили не придумывать велосипед и сослаться на широко известную модель зрелости процессов разработки. TMMI, как и CMMi, состоит из 5 уровней:

• Level 1 Initial
• Level 2 Managed
• Level 3 Defined
• Level 4 Management and Measurement
• Level 5 Optimization

У каждого уровня есть процессные области (для разных уровней их состав и количество разное). Процессные области — это своего рода сгруппированные по определенным критериям виды активностей (Test Planning, Test Monitoring and Control, Test Design and Execution). При этом у каждой процессной области есть набор определенных конкретных целей (Specific Goals) и способов достижения этих целей (Specific Practices). Упрощенно говоря, выполнение практик в рамках уровня позволяет говорить, что вы соответствуете этому уровню зрелости.

Процессные области, соответствующие второму уровню зрелости

Большинство отделов тестирования в начале своего развития находятся на первом уровне зрелости. Цель тестирования на этом уровне — лишь убедиться в том, что нет серьезных багов.

Характерными для этого уровня являются следующие признаки:

• Тесты придумываются на ходу после передачи ПО на тестирование
• Фазы тестирования и отладки постоянно сменяют друг друга с целью удаления блокирующих багов
• Оценка качества и рисков не проводится

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

• Test Policy and Strategy
• Test Planning
• Test Monitoring and Control
• Test Design and Execution
• Test Environment

Давайте рассмотрим их детальнее:

Test Policy and Strategy

В рамках процессной области Test Policy and Strategy подразумевается достижение следующих целей:

• Establish a Test Policy
• Establish a Test Strategy
• Establish Test Performance Indicators

Подразумевается, что у вас существуют и используются такие документы как test policy и test strategy. Согласно словарю ISTQB эти термины подразумевают следующую трактовку:

test policy A high-level document describing the principles, approach and major objectives of the organization regarding testing.

test strategy A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).

В официальной доке есть детальное описание содержания этих документов, но так как статья обзорная, я эти детали упускаю.

Что касается Test Performance Indicator, то для достижения этого пункта должны существовать и использоваться показатели эффективности работы тестировщиков. Например, могут использоваться следующие метрики:

• Test effort and cost
• Test lead time
• Number of defects found
• Defect detection percentage
• Test coverage

Test Planning

В рамках процессной области Test Planning предполагается достижение следующих целей:

• Perform a Product Risk Assessment
• Establish a Test Approach
• Establish Test Estimates
• Develop a Test Plan
• Obtain Commitment to the Test Plan

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

Test Monitoring and Control

В рамках процессной области Test Monitoring and Control подразумевается достижение следующих целей:

• Monitor Test Progress against Plan
• Monitor Product Quality against Plan and Expectations
• Manage Corrective Action to Closure

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

Test Design and Execution

В рамках процессной области Test Design and Execution предполагается достижение следующих целей:

• Perform Test Analysis and Design using Test Design Techniques
• Perform Test Implementation
• Perform Test Execution
• Manage Test Incidents to Closure

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

Test Environment

В рамках процессной области Test Environment подразумевается достижение следующих целей:

• Develop Test Environment Requirements
• Perform Test Environment Implementation
• Manage and Control Test Environments

То есть тестировщики формулируют требования к тестовому окружению, настраивают тестовое окружение и отвечают за configuration management на этом окружении. Покрытие этой процессной области в реальности может быть достаточно сложным, так как обычно хорошее тестовое окружение — это значительная статья расходов, и хорошо если оно вообще есть, и вам не приходится тестировать на среде девелоперов или на проде :).

Недостатки

TMMi кажется достаточно удобным инструментом для быстрой оценки уровня зрелости процессов тестирования. Но уже сейчас заметны возможные недостатки, которые могут проявиться во время внедрения метода.

Объем документации

На мой взгляд, следствием достижения более высоких уровней TMMI будет большой объем неиспользуемой документации. Взять хотя бы ту же test policy. Согласно определению в этом документе описаны:

«principles, approach and major objectives of the organization regarding testing»

Я не представляю какую полезную информацию можно отразить в этом документе. Ну то есть можно конечно вставить туда что-то типа «Качество является одной из ценностей компании» и т.д и т.п. Но как наполнить этот документ смыслом в условиях аутсорса я не знаю. На разных проектах проводятся разные виды тестирования: иногда оценка производительности проводится иногда нет, где-то предъявляются высокие требования к usability, а кто-то на этом экономит, часть компаний понимают важность тестовой документации, а часть — считают это лишними артефактами. Как и главное зачем в таких условиях описывать «principles, approach and major objectives of the organization regarding testing» я не знаю. Тем более что в тест-плане заложена та же информация:

test plan: A document describing the scope, approach, resources and schedule of intended test activities. Почти слово в слово то же самое.

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

Качество процессов и качество продукта

Второй момент, вызывающий сомнение — это предположение о том, что качество процессов приводит к качеству продукта на выходе.

Согласно Демингу:

Появление дефектов продукции (услуг) — это проблема прежде всего несовершенства управления компанией (96–98%) и только затем исполнителей (2–4%).

Идея TMMi состоит в том, что имея налаженные процессы, вы просто не сможете плохо тестировать, а следовательно качество продукта будет выше. К качеству продукта согласно «ISO 9126 Software engineering — Product quality» относятся такие характеристики:

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

Любую из этих характеристик можно определенным образом оценить или измерить, а процедуру оценки или измерения можно описать. По идее когда у исполнителя будет готовый алгоритм объективной оценки каждой характеристики, то роль исполнителя сводится к минимуму. Но на самом деле, мне кажется, что влияние исполнителей значительно выше чем процессов. Хочется думать, что в сфере ИТ все еще первичными являются кадры, и что строго регламентированные, конвейерные методы разработки проигрывают менее формализованным подходам.