Моделі зрілості процесу тестування ПО

Сьогодні багато говориться про якість програмного забезпечення та інформаційних систем, проводяться дослідження, що демонструють залежність якості і ефективності автоматизованих бізнес-процесів. Якість програмного забезпечення з абстрактного і невловимого поняття перетворюється в комплексну метрику оцінки програмного рішення, проекту його впровадження, процесу створення і рівня використання інформаційних систем в цілому. Від чого ж залежить якість програм і якомога на нього впливати?

Очевидно, що якість програмного забезпечення безпосередньо залежить від якості процесу його виробництва. Керуючи процесом виробництва і контролюючи показники ефективності всіх його технологічних етапів, можна впливати на якість продукту, що виробляється. Говорячи про характеристики програм, можна виділити прості для розуміння і аналізу кількісні метрики, що відносяться до якості програмного коду (цикломатическая складність коду - складність структури модуля, наприклад, кількість незалежних маршрутів в ньому); кількість рядків коду, віднесене до артефактів проектного сховища та т.п .; тести (покриття гілок і модулів коду сценаріями тестів, співвідношення кількості помилок, знайдених до і після випуску продукту, динаміка виявлення помилок і ін.); покриття вимог на відповідність рекомендаціям до інтерфейсу додатків і операційних платформах. Однак, при переході на процесний рівень забезпечення якості розроблюваних програм виникають певні труднощі в розумінні якості цього процесу. Справді, як, наприклад, оцінити і виміряти ефективність того чи іншого способу розробки, якщо практично не існує проектів розробки двох однакових програмних систем, і тим більше не зустрічаються дві ідентичні з досвіду і навичкам команди розробників? Судити за кінцевим результатом не представляється можливим: крім процесних умов виробництва програмного забезпечення (застосовується методологія, структура проектної команди, способи комунікації з замовником) найчастіше сильно відрізняються і умови проекту (терміни, вартість і обсяги ресурсів). Більш детальний розгляд процесу тестування програмного забезпечення - технологічної складової процесу виробництва - виявляє проблему вибору метрик ефективності тестування.

Крім безпосередньої оцінки поточного рівня ефективності того чи іншого процесу є і більш цікаве завдання - підвищення рівня ефективності або, як прийнято говорити, рівня зрілості процесів. Коли базові проблеми планування і проведення робіт з тестування в інтеграції з процесом розробки програмного забезпечення вирішені, виникає завдання пошуку оптимальних організаційних і процедурних схем виконання робіт. Відповівши на питання «хто» і «коли», доводиться шукати відповіді на питання «як, яким чином», «як вимірювати результати», «як контролювати», «як працювати ефективніше», а також «як управляти і розвивати процес, базуючись на отриманих даних і досвіді ».

У повсякденній практиці - при роботі з конкретними інструментами - у ІТ-фахівців і менеджерів проектів складається стійка думка про технологічну природі всіх проблем, пов'язаних з якістю програмного забезпечення і досягаються рівнями зрілості процесу його розробки. Як наслідок, посилено просувається постачальниками віра в силу програмних засобів підвищення якості на практиці стає ґрунтом для необґрунтованих рішень про впровадження методологій або автоматизації процесів розробки, починаючи з впровадження конкретних програмних рішень. Однак сучасні засоби автоматизації процесів розробки є настільки гнучкими і налаштованим платформами, що вимагають попередньої глибокого опрацювання саме процессной складової з подальшим впровадженням та адаптацією вже під конкретні умови виробництва.

У 1980 році в Інституті програмної інженерії при Університеті Карнегі-Меллона була розроблена модель зрілості процесів розробки програмного забезпечення (Capability Maturity Model for Software, CMM), яка згодом отримала розвиток в CMMI (Capability Maturity Model Integration), де-факто визнаному в індустрії виробництва програмного забезпечення сертифікаті рівня зрілості процесу розробки. За аналогією зі світом розробки програмного забезпечення та існуючими моделями зрілості їх процесів, розглянемо моделі зрілості процесу тестування.

Модель зрілості тестування

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

Консультант з питань тестування Террі Везер в 2001 році одним з перших порівняв існуючі моделі зрілості тестування [1] і виділив шість моделей:

• Testability Maturity Model (TMM);

• Software Testing Maturity Model (TMMSW);

• Test Process Improvement (TPI);

• Test Organization Maturity (TOM);

• Testing Assessment Program (TAM);

• Proposed Evaluation and Test SW-CMM Key Process Areas (SW-CMM KPA).

Потім в деякі моделі були внесені принципові зміни; так, модель ТОМ (її створила і розвиває компанія Gerrard Consulting) пропонує оновлений набір метрик, що описують безпосередньо процес тестування (тривалість тестових ітерацій, співвідношення тестових сценаріїв і функціональних вимог і ін.), які збираються і аналізуються на етапі опису існуючого процесу.

Серед шести моделей зрілості тестування програмного забезпечення практики і консультанти виділяють дві: TMMSW, розроблену в Технологічному інституті штату Іллінойс, і TPI, запропоновану в компанії Sogeti. Обидві моделі отримали поширення в першу чергу завдяки своїй простоті, а також пропонованих практикам внутрішніх аудитів, які можуть проводитися фахівцями компанії, що встала на шлях процесних поліпшень. Розглянемо структуру моделей зрілості тестування програмного забезпечення на прикладі моделі TMM.

Модель TMMSW, обрана Томасом Стаaбом [2], одним із провідних консультантів в області тестування програмного забезпечення, є найбільш цікавою для застосування, оскільки поряд з простотою розуміння і використання практик дозволяє організаціям власними силами проводити оцінки (assessment) і поступово наближатися до поставлених цілей розвитку , контролюючи проміжні результати. У своїй роботі ми також зупинили вибір на цій моделі, враховуючи непопулярність у вітчизняних ІТ-компаній практики залучення сторонньої компетенції (компанії намагаються економити на інвестиційних проектах, якими по суті є проекти консалтингові, а також на проекти, що приносять непрямі вигоди, до яких відносять процесні зміни), і пропонуємо познайомитися з нашим досвідом, що демонструє готовність компаній самостійно проводити внутрішні зміни силами власних фахівців. Ітеративна підходу є для багатьох компаній ключовим моментом при виборі тієї або іншої моделі зрілості, так як вона дозволяє контролювати терміни виконання проекту по впровадженню процесних змін.

Модель TMMSW розроблена групою фахівців під керівництвом Ілен Барнштейна в 1996 році як розширення і доповнення до моделі SW-CMM. До її переваг можна віднести відповідність рівнів зрілості процесів тестування програмного забезпечення і рівнів зрілості процесів розробки в моделі SW-CMM. Також модель TMMSW може бути використана в інтеграції з CMMI, рекомендаціями ISO-9001 та стандартом ISO / IEC Std 12207, які дозволяють пройти формальну сертифікацію і при постійному контролі у вигляді аудитів та переатестацію залишатися на заданому рівні якості. З одного боку, ця особливість TMMSW дозволяє впроваджувати процесні зміни в підрозділі тестування програмного забезпечення в форматі виділеного проекту меншого масштабу, ніж впровадження CMMI в межах організації (що економить кошти і забезпечує прозорість); з іншого боку, при такому підході виключаються витрати на адаптацію і сполучення декількох моделей. Говорячи про своєрідний спорідненість з CMMI, хотілося б підкреслити, що ця модель досить широко поширена в світі ІТ і заслужила високу ступінь довіри до себе, що набагато полегшує мотивацію керівництва до витрат на проект по впровадженню процесних змін.

Модель TMMSW пропонує полегшене планування, впровадження та моніторинг процесу поліпшення. З недоліків моделі можна відзначити обмеженість літератури: книга Practical Software Testing: A Process-oriented Approach, випущена Springer Professional Computing, - мабуть, єдиний значний працю з даної тематики.

Модель TMMSW, як і CMM, передбачає п'ять рівнів зрілості.

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

Рівень 2 - фаза розробки. Тестування програмного забезпечення відокремлено від кодування і виділяється як наступна фаза. Головна мета тестування - показати, що додаток відповідає вимогам. Є базові підходи та практики тестування. Цілі рівня: визначити завдання розробки і тестування, створити відповідні процедури, ініціювати процес планування тестування, зафіксувати і описати базові процедури і методики тестування.

Рівень 3 - інтегрований. Процес тестування інтегрований в життєвий цикл розробки програмного забезпечення. Цілі тестування базуються на вимогах. Є організація тестування, а саме тестування виділено в професійну діяльність. Цілі рівня: виділити тестування в окрему групу і визначити програму технічного навчання, інтегрувати процес тестування в життєвий цикл розробки, а також контролювати безпосередньо процес тестування.

Рівень 4 - управління і вимірювання. Тестування є вимірюваним та контрольованим процесом. Процеси критичних оглядів (review) проектних артефактів (тестові плани і сценарії, повідомлення про помилки, підсумкові звіти про стан версії і т.д.) відносяться до тестових активностей. Продукт тестується на відповідність таким якісним метрик, як надійність, зручність, сопровождаемость. Тестові сценарії записані, зберігаються в системі управління тестуванням і можуть бути багаторазово використані разом з тестовими наборами даних. Виявлені дефекти не тільки фіксуються, а й аналізуються за формальними ознаками: критичність, «вага» дефекту, важливість, час життя і т.д. Цілі рівня: впровадження програм критичних переглядів і аудитів на рівні всієї організації / підрозділу нарівні з програмою вимірюваного тестування. Проводиться оцінка якості програмних продуктів.

Рівень 5 - оптимізація процесу, запобігання помилок і контроль якості. Тестування є певним і керованим процесом. Вартість тестування нарівні з показниками ефективності може бути визначена. Тестування як процес піддається змінам, які однозначно позитивно на нього впливають. Впроваджені і використовуються практики запобігання помилок і контролю якості. Автоматизоване тестування застосовується як основний підхід в тестуванні. Проектування тестів, аналіз отриманих результатів, обробка описів помилок, а також метрик, пов'язаних з тестуванням, здійснюється за допомогою відповідних інструментальних засобів. Широко поширений підхід повторного використання процесних практик. Цілі рівня: оптимізація процесу тестування, запобігання помилок і контроль якості.

Всі перераховані рівні зрілості, крім першого, включають цілі розвитку, які, в свою чергу, містять подцели, тобто дозволяють оперувати не тільки високорівневими завданнями менеджменту якості процесу розробки програмного забезпечення, а й формулювати оперативні завдання для всіх виконавців в проекті. Контроль і аналіз виконання завдань досягаються покриттям так званих ATR-матриць (Activities - Tasks - Responsibilities) - артефактів проектного рівня, з якими можуть працювати учасники проекту без попередньої підготовки або тривалого навчання. ATR-матриці визначають активності і завдання, які повинні бути виконані на кожному конкретному етапі впровадження моделі, і служать одночасно і «дорожньою картою», і своєрідним «контрольним листом» процесу впровадження змін. Наявність пропонованих самою моделлю проектних артефактів часто є істотним критерієм успішності проекту по адаптації і впровадження моделі. Кожній активності в ATR-матриці призначається завдання контролю, яка виконується менеджерами, розробниками / тестувальниками або ж клієнтами / користувачами. Особливо відзначимо, що контроль над проектом по внесенню змін не покладається на виділену групу людей або конкретної людини в проекті, а є загальною проектною функцією, у виконанні якої зацікавлені учасники проекту всіх рівнів.

Аж до п'ятого рівня зрілості процесів тестування програмного забезпечення не вимагається застосування будь-яких спеціальних інструментів або інтегрованих рішень, на відміну від зрілості процесів розробки, де інструменти збору та аналізу вимог і версионного контролю, наприклад, є необхідною умовою досягнення певного рівня зрілості процесу розробки в цілому. На п'ятому рівні моделі TMMSW можливе застосування певних інструментів статистичного аналізу коду, що дозволяють вирішувати одну з цільових завдань цього рівня зрілості - запобігання помилок за рахунок виявлення ділянок коду, що містять логічні помилки відсутності операторів вивільнення ресурсів або пошуку невикористовуваних змінних або масивів пам'яті. Однак застосування спеціального інструменту не є обов'язковим навіть на цьому рівні; наприклад, підхід, коли на одного кодувальника доводиться два тестувальника, один з яких - розробник більш високого рівня - зайнятий на завданнях критичних оглядів коду, також дозволяють вирішувати завдання запобігання помилок.

Застосування конкретних методик або проходження будь-який з обраних методологій (RUP, MSF або Scrum) також не дає гарантій досягнення якості продукту або успішності проекту, так як методологія розробки програмного забезпечення працює тільки для конкретного типу проектів. Аналогічно для процесу тестування програмного забезпечення жодна методологія без адаптації до умов конкретного проекту не дає гарантованого результату. Модель зрілості процесу - саме тим і цікава для застосування практика досягнення певних рівнів якості процесу, що представляє собою структуру цілей і підходів для їх досягнення, дозволяючи використовувати «всередині» практично довільну методологію розробки (при правильній адаптації) і набір інструментарію. Модель пояснює, «що і як» робити, але не «чим і в якому порядку».

Практика

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

• Контрольованій за термінамі процес випуску версій з завдань рівнем якості. Тут не йдеться про ідеальний як продукту, що випускається або повній відсутності дефектів - йдеться про впевненість в стані випускається версії, з боку як проектної команди, так і групи тестування.

• Регулярність і прогнозована повторюваність всіх етапів проекту. В умовах початкових рівнів зрілості процесів тестування програмного забезпечення активності з тестування слідують як замикає етап робіт і часто «страждають» через обмежені термінів і нестачі ресурсів, що безпосередньо позначається на стабільності випускаються версій і на їхній якості. При переході на більш високі рівні моделі зрілості процесу тестування активності по тестуванню все більше інтегруються в процес розробки і випуску версій продукту, що позитивно позначається на виділенні необхідних ресурсів і часу для виконання робіт.

• Зміна такого якісного показника, який характеризує процес розробки і випуску програмного забезпечення, як кількість виявлених дефектів після випуску версії продукту в дослідній або навіть виробничої експлуатації. Цей показник є дуже суттєвим для менеджерського складу і служб технічної підтримки, які можуть підтвердити фактами позитивну динаміку підвищення рівня якості програмного забезпечення, провівши кількісний і якісний аналіз зареєстрованих звернень від клієнтів або користувачів. Позитивні моменти, за нашими оцінками, пов'язані з практичними поліпшеннями на етапі планування і контролю тестування, так як часто припущення дефекти викликані саме нестачею часу на планування і контроль проведених робіт по тестуванню.

література

1. Terry Weatherill, In the Testing Maturity Model Maze. Journal of Software Testing Professionals, 2001..

2. Thomas Staab, Using SW-TMM to Improve the Testing Process. Wind Ridge International.

В'ячеслав Панкратов ( [email protected] ) - генеральний директор компанії QAExpert (Київ, Україна).