Аудит і оцінювання. Вдосконалюємо процес тестування
Привіт! Я QA Team Lead із семирічним досвідом роботи в галузі контролю якості, п’ять років з яких залучена до управління QA-командами. Володію сертифікатом ISTQB Certified Tester Full Advanced Level, маю досвід управління QA-командами (manual, automation, hybrid) різного розміру, включаючи розподілені команди, де учасники перебували у різних країнах. Під час підготовки до сертифікаційних іспитів зацікавилася темою аудиту та вдосконалення процесів тестування і почала застосовувати теоретичні знання на практиці.
Стаття буде цікавою тим, хто вже замислювався про аудит процесів на проєкті, почав збирати метрики або тільки збирається це робити — QA Manager, QA Lead, PM та навіть executive persons. У статті розглянемо, чим відрізняється аудит від оцінювання, а також для чого і як часто проводити аудит. Окрім того, запропоную приклад використання однієї з галузевих моделей вдосконалення тестового процесу.
Пишу цю статтю не тільки тому, що хочу поділитися досвідом і теоретичними знаннями, а й тому, що виступала з цією темою на вебінарі для WWC (Women Who Code). Вважаю, що задля кращого сприйняття матеріал краще прочитати, ніж почути, та й цікаві питання від аудиторії доповнили мою розповідь.
Audit vs assessment — чи є різниця
Вперше я ознайомилася з темою аудитів та моделей вдосконалення процесів тестування під час підготовки до екзамену ISTQB Advanced Level Test Manager. Через деякий час мене попросили долучитися до роботи над одним з проєктів компанії, щоб оцінити його й запропонувати варіанти вирішення проблем.
Потрібна була добре підготовлена та досвідчена людина, яка зможе переконати замовника, що треба запровадити зміни, щоб запобігти ще більших проблем з процесами. Саме тоді я повернулась до книжок і почала вивчати тему аудитів і моделей поліпшення процесів тестування докладніше.
Спершу пропоную розібратися, що таке аудит і оцінювання (audit і assessment). З одного боку, це питання спірне, але з іншого — все досить просто. Ці два поняття тісно пов’язані між собою, але різняться.
Кажучи про оцінювання (assessment), ми маємо на увазі отримання актуальної інформації щодо проєкту й маємо на меті виявити його слабкі та сильні сторони й те, що можна поліпшити. Окрім того, ми отримаємо якісну оцінку, виражену цифрами (наприклад, «Документування» — 3 з 5).
В основі аудиту (audit) також оцінювання, але щодо відповідності певним стандартам і документам (як, наприклад, зовнішні аудити для отримання сертифікатів ISO).
Є три види аудитів: 3rd party, 2nd party та 1st party.
- 3rd party аудит проводить зовнішня незалежна аудиторська організація. У аудиті ISO 9001 є реєстратор. Зазвичай зовнішня сторона не зацікавлена в кінцевому результаті. Третьою стороною може бути реєстратор, державний службовець або наймана компанією фірма. Результатом аудиту може бути сертифікація, ліцензія, ухвалення або нагорода.
- 2nd party аудит проводять ті, хто глибоко зацікавлений у кінцевому результаті. Це може бути аудит ваших постачальників або клієнтів. Його можна назвати опитуванням або оцінюванням.
- 1st party — це внутрішній аудит. Це інструмент управління з акцентом на постійне вдосконалення. Аудитор повинен бути не зі сфери, з якої проводять аудит, а сам процес має бути спрямований на цілі та показники компанії. Наприклад, відповідати стандартам ISO, або ж показникам успішності (кількість контрактів, клієнтів, критична кількість скарг від клієнтів щодо продукту тощо), які продумала для себе компанія.
Я вважаю, що як процес не називай, а користь він дати має. Саме тому далі буду оперувати обома поняттями: і аудитом, і оцінюванням.
Для чого потрібен аудит тестування і як часто його проводити
Тож коли треба замислюватися про аудит?
- Ви не маєте чіткої інформації про якість програмного забезпечення чи вузькі місця процесу (bottlenecks).
- Навантаження на проєкт збільшується, але поточний процес контролю якості не дає змоги масштабувати його.
- З наявним процесом контролю якості ви не можете перейти на іншу методологію розробки, застосувати інший підхід до управління інфраструктурою або внести інші зміни.
- Вам потрібно пройти сертифікацію продукту/процесу, і ви хочете переконатися, що процес контролю якості відповідає вимогам.
Варто пам’ятати, що для досягнення стабільного позитивного результату аудит процесів повинен стати циклічним. Це означає, що час від часу все коло дій треба повторювати (планувати аудит, проводити його, перевіряти результати та впроваджувати зміни відповідно до отриманих результатів і бажаного ефекту). Для цього можна застосовувати так званий цикл Демінга, який ще називають PDCA Model.
Критичні складники процесу тестування
Тепер, коли ми розібралися з оцінюванням, аудитом та його видами, час визначитися, які з тестових процесів є критичними. Поняття «критичні тестові процеси» (Critical Testing Processes) описане в однойменній книзі Рекса Блека й охоплює процеси, які підлягають оцінюванню і подальшим змінам:
- Тестування (Testing).
- Визначення контексту (Establishing context).
- Аналіз ризиків (Quality risk analysis).
- Естимація (Test estimation).
- Планування (Test planning).
- Розвиток команди тестування (Test team development).
- Розвиток тестової системи (Test system development).
- Реліз менеджмент (Test release management).
- Виконання тестів (Test execution).
- Створення баг-репортів (Bug reporting).
- Звітування про результати (Results reporting).
- Управління змінами (Change management).
Докладно про ці процеси можна почитати у Рекса Блека, та наразі нас цікавлять поширені моделі поліпшення процесів тестування, які можуть слугувати базою для аудитів.
Книга для підготовки до іспиту ISTQB Advanced Test Manager описує чотири галузеві моделі. Я обрала одну і використала як базу для майбутнього аудиту. Можливо, для ваших проєктів краще підійде інша модель, тому пропоную коротко ознайомитися з різними підходами.
Моделі удосконалення процесу тестування
TPI Next (Test Process Improvement Next). На мою думку, найбільш складна та комплексна модель. Оцінити пропонують 16 ключових процесів і декілька рівнів зрілості для кожного з них. Також є спеціальна матриця.
Така модель більше підходить для відокремлених QA-команд і сконцентрована на паралельному підвищенні рівня зрілості для всіх ключових показників.
З мого досвіду отримати прозорий, зрозумілий та простий висновок за короткий час буде неможливо. Звісно, якщо часу більше ніж
CTP (Critical Testing Processes). Ця модель є більш гнучкою, вона нічого не приписує, на відміну від інших моделей, які очікують від нас постійного циклічного вдосконалення. Але все ж таки мені хотілося б скористатися чимось більш свіжим (книжечка Critical Testing Processes вже трохи застаріла) і зрозумілішим для людей, які найімовірніше вперше почують про існування схожих моделей взагалі.
STEP (Systematic Test and Evaluation Process). Усі зміни, які пропонує впроваджувати ця модель, можуть відбуватися в будь-якому порядку. Вона не має складних матриць. Але одна із засад — наявність чітких формалізованих вимог. Тобто для процесу, де таких немає, ця модель, ймовірно, не підійде.
TMMi (Test Maturity Model Integration). Модель розробив Іллінойський інститут технологій на базі CMM (Capability Maturity Model). Її мета — надати основи для оцінювання зрілості процесів тестування. І таким чином підвищувати рівень зрілості. TMMi має п’ять рівнів, вони зображені на схемі:
Отже, типові процесні ділянки поділені на групи, кожна з яких має цілі (Specific Goals) та засоби для їх досягнення (Specific Practices). Таким чином для використання цієї моделі нам треба оцінити засоби для досягнення цілей у межах конкретного проєкту.
Звісно, ця модель має свої недоліки, основний — треба створювати багато документів для переходу на наступний рівень, якщо їх ще немає в межах проєкту.
Приклад практичного використання галузевої моделі вдосконалення тестового процесу TMMi
Я не буду докладно описувати обрану модель, тому що на DOU є окремі статті, присвячені цьому, а також офіційний сайт пропонує посилання на документацію. Хочу лише поділитися власним прикладом застосування моделі під час аудиту процесів на проєкті, де я безпосередньо не працювала, але була запрошена як незалежна експертка.
Тож як я застосувала теоретичні знання про цю модель:
- Спочатку мені треба було оцінити рівень проєкту згідно з рівнями моделі.
- Після отримання обґрунтованого результату надати рекомендації щодо переходу на наступний рівень.
Оскільки я не працювала з проєктом, треба було створити список запитань (вони можуть бути різними, адже модель не вимагає конкретного переліку) і провести інтерв’ю з колегами, які були в нього залучені. Запитання стосувалися здебільшого процесів, документації тощо. Після цього я додала запитання без відповідей (бо це могло спровокувати упереджене ставлення до моїх колег з боку клієнта, якщо раптом він не буде згодний з їхніми відповідями) до фінального документа, який потім презентували клієнту.
Потім я запропонувала певні кроки, щоб перевести проєкт на наступний рівень. Сформувала окремий документ для презентації замовнику, який містив таку інформацію:
- Короткий огляд моделі, рівні, а також посилання на офіційну документацію за цією моделлю.
- Опис проведення аудиту, хто був залучений до опитування, а також список запитань, на які пропонувала відповісти.
- Висновок про рівень, на якому наразі перебуває проєкт, і рекомендації щодо переходу на наступний. Зафіксувала переваги для проєкту та замовника після застосування необхідних змін.
На жаль, не можу сказати, що це була магічна пігулка для проєкту, але ми спробували оцінити процеси, застосувати знання щодо моделі та зробити фінальний документ за короткий термін.
Це корисно, оскільки такі спроби не займають багато часу, дають незалежну оцінку від колег, бо часто ми не помічаємо дрібниць, які можуть впливати на роботу, якість продукту й рівень задоволеності клієнтів.
Корисні посилання
- Книга Critical Testing Process Рекса Блека.
- Книга для підготовки до іспиту ISTQB Advanced level Test Manager, де є багато інформації щодо моделей поліпшення процесів, а також порівняльний аналіз.
- Офіційний сайт TMMi, де можна знайти посилання на документацію.
- Приклад опитування на основі TMMi level 2 to 5.
