Покращення процесу тестування (TPI) за допомогою моделі PDCA
Томас Гамільтон
⚡ Розумний підсумок
У рамках покращення процесу тестування застосовується цикл PDCA до тестування, щоб кожен проект залишав після себе вимірювані уроки. На цій сторінці пояснюються чотири кроки PDCA, моделі зрілості, що лежать в їх основі, та показники, які доводять, що покращення дійсно відбулося.
Що таке покращення процесу тестування?
Покращення процесу тестування — це практика вимірювання ефективності процесу тестування, виявлення його слабких місць та внесення контрольованих змін, щоб наступний проект забезпечував вищу якість за менші кошти та за менший час. Вона розглядає тестування як процес, який можна виміряти та налаштувати, а не як діяльність, яка повторюється однаково в кожному релізі.
Уявіть собі GuruПроект банку 99 щойно завершено. Правління цінує вашу роботу, а клієнт задоволений. Незважаючи на це, у вашого начальника все ще є до вас запитання.
Менеджери часто описують тестування програмного забезпечення як проблемний та неконтрольований процес. Озираючись назад на GuruЧи зіткнулися ви з якимись із наступних проблем у проекті Банку 99?
Це поширені проблеми майже в будь-якому тестовому проекті. Багато організацій усвідомлюють, що покращення процесу тестування — єдиний довгостроковий спосіб їх вирішення, оскільки навчання на минулих помилках запобігає повторенню тих самих помилок у наступному циклі випусків.
Навіщо покращувати процес тестування?
Наведений нижче сценарій показує, чому важливо покращити процес тестування. GuruПроєкт 99 Bank завершено, якість тестування чудова, і ви отримали схвальні відгуки від клієнта.
Який урок винесено з цього сценарію? Він просто «Завжди намагайся робити краще»Навіть коли ви вважаєте, що виконали гарну роботу, завжди є інші, хто робить це краще, бо вони знайшли кращі ідеї та кращі рішення, ніж ваші.
Кожен бізнес хоче, щоб проект був завершений з найвищий якість, на найнижчий вартість, і в найкоротший час виконання. Покращення процесу тестування – це те, що допомагає команді тестувальників рухатися до всіх трьох цілей одночасно.
Як впровадити покращення процесу тестування?
Впровадити покращення процесу тестування на Guru99 Банківський проект, менеджер тестування може слідкувати за PDCA модель. PDCA (Плануй-Виконуй-Перевіряй-Дій) – це чотириетапний метод управління, що використовується в бізнесі для контролю та постійного вдосконалення процесу. Кожен прохід через цикл є окремим циклом вдосконалення, а вихід дії стає вхідним сигналом для наступного Плану.
💡 Порада: Запускайте цикл PDCA для однієї вузької проблеми за раз. Цикл, спрямований на одну вимірювану больову точку, таку як час виконання регресії, завершується достатньо швидко, щоб показати результат протягом одного релізу.
Крок 1) План
Фаза планування – це етап, на якому розробляється вдосконалення. Вона поділена на три менші кроки.
Крок 1.1) Визначте проблему
Першою діяльністю процесу вдосконалення тесту є ідентифікує проблеми, які виникли в поточному проекті. Проблеми в цьому проекті можуть повторитися в іншому проекті. Вирішення проблем і пошук рішень, щоб уникнути їх у майбутньому, є основною метою Test Improvement.
А тепер повернемося до проєкту GuruВебсайт банку 99. Чи знаходите ви якісь проблеми або пункти для покращення? Виберіть нижче.
| Sr Ні | Проблема | Опис | Виберіть |
|---|---|---|---|
| 1 | Якість | Клієнт все ж знайшов деякі Дефект після звільнення | |
| 2 | Доставка | Проект затримався | |
| 3 | професіонали | Деякі працівники не співпрацювали з іншими членами команди | |
| 4 | Навички | Члену команди не вистачало бажаних навичок для виконання своїх завдань | |
| 5 | управління | Менеджер тестування погано відстежував прогрес, що призвело до затримки деяких проектів | |
| 6 | Комунікація | відсутність постійного контакту з клієнтом; неправильне розуміння вимог замовника | |
| 7 | Коштувати | Вартість проекту перевищила встановлений бюджет |
Крок 1.2) Визначте ціль
Зрозумійте проблему та труднощі, що виникли в проекті. Саме так ви визначаєте точки покращення та фази тестування, які заслуговують на увагу в першу чергу.
Припустімо, ви визначили, що фаза виконання тесту теж зайняла багато час і вартість виконання. Чи можна зробити тестування швидшим і дешевшим? Це питання стає метою циклу. Корисна ціль зазначається у вигляді числа та терміну, наприклад, «скоротити зусилля на виконання регресії на 30 відсотків до наступного релізу».
Крок 1.3) Визначте дії щодо покращення
На основі узгодженої цілі визначаються дії щодо покращення. Ці дії мають бути поступовими та впроваджуватися крок за кроком, оскільки нереально змінити все одразу.
Наприклад, щоб зробити тестування швидшим і дешевшим, можна вжити таких дій.
У наведеному вище прикладі варіанти A та B пришвидшують та здешевлюють тестування. Варіант C пришвидшить тестування, але він коштує дорожче, оскільки досвідченіший тестувальник отримує вищу зарплату. Саме цей компроміс є причиною того, що кожну дію кандидата потрібно оцінювати з урахуванням цільової аудиторії, а не інтуїції.
Крок 2) Зробіть
Ви вже визначили точки покращення. Тепер час розробити план їх реалізації. Цей план має відповісти на наступні питання.
- Які пункти покращення потрібно впровадити та в якому порядку?
- Коли план має бути завершений?
- Які кроки необхідно виконати для досягнення плану?
- Хто відповідає за кожен крок, і як буде підтверджено його завершення?
Виконайте дії з покращення
Після того, як план розроблено, його необхідно впровадити. Заходи з покращення можуть порушити роботу з тестування, яка вже триває, тому менеджер з тестування повинен платити увагу їм, щоб уникнути небажаних наслідки
Розглянемо наступний сценарій. На GuruУ рамках проекту 99 Bank, щоб зробити тестування швидшим та дешевшим, ви вирішили використати тестування автоматизації замість великого блоку ручних регресійних тестів. Після застосування дії продуктивність значно зросла.
Крок 3) Перевірити
На кроці перевірки ви робите три речі.
- Оцініть значення ефективність дій щодо покращення тесту
- Виміряти як ефективний рішення було
- Проаналізуйте, чи це може бути поліпшений далі
Мета цього етапу полягає в тому, щоб підтвердити, що дії з покращення були успішно впроваджені, та оцінити, чи дійсно досягнуто ціль, встановлену в Плані.
Найкращий спосіб виконати цю оцінку – це показникиМетрики є важливими для успішного управління організацією. Менеджер з тестування збирає дані та використовує їх для вимірювання таких параметрів, як продуктивність, якість та вартість.
Наприклад, до того, як до проекту було застосовано автоматизацію, продуктивність тестування була 10 тестових випадків за людино-годинуПісля застосування автоматизації продуктивність вимірювалася на 20 тестових випадків за людино-годину.
Але поряд із цим здобутком виникла небажана проблема.
У цьому випадку застосовується автоматизація збільшений продуктивність тестування, а й якість тестування знизивсяТаким чином, дії з покращення можуть спричинити серйозні Наслідки в іншому місці. У такому сценарії інструмент тестування має бути обраний набагато ретельніше, а автоматизований набір має бути перевірений з такою ж ретельністю, як і виробничий код. Структурована оцінка інструментів-кандидатів, таких як описано в Selenium підручник, запобігає впровадженню інструменту виключно через його популярність.
⚠️ Попередження: Ніколи не оцінюйте дії щодо покращення за одним показником. Зміна, яка подвоює пропускну здатність виконання та одночасно знижує рівень виявлення дефектів, робить процес швидшим і гіршим одночасно. Завжди поєднуйте показник швидкості з показником якості.
Розглянемо той самий сценарій ще раз. Guruвартість проекту 99 перебіг тому що члени команди теж взяли багато часу для виконання тестів. Використовуючи інструмент автоматичного тестування, ви заощадили 30 відсотків вартості проекту. Це гарне покращення, але ваш начальник очікує більшого.
Тому вам завжди доводиться шукати новіші рішення, які ще більше покращують процес тестування. У цьому випадку інші варіанти можуть заощадити додаткові кошти на проекті.
- Ефективно керуйте своїми людськими ресурсами, щоб кваліфіковані тестувальники працювали там, де вони додають найбільшу цінність
- Домовтеся про кращі комерційні умови з постачальниками інструментів та персоналу
- Видаляйте дублікати або малоцінні тестові випадки замість їх автоматизації
Крок 4) Дійте
Коли дії з покращення успішно впроваджено та ціль досягнуто, менеджер тестування повинен завершити цикл виконанням наступних дій.
- Review заходи з покращення та дії на основі отриманих уроків
- Стандартизувати точка покращення в процесі управління тестуванням
- Оновити документи політики, шаблони планів тестування та стандартні документи процесу
- Визначати коли і де ці зміни будуть застосовані в наступному проєкті
Якщо ціль не була досягнута, цикл не зупиняється. Недосягнута ціль переноситься на нову фазу Планування разом з усім, що було виявлено на фазі Перевірки щодо причин неефективності дії.
Порівняння TPI NEXT, TMMi та CMMI
PDCA є двигуном удосконалення, але еталонна модель показує, як виглядає «краще». Зазвичай використовуються три моделі, і їх часто плутають одну з одною.
TPI NEXT – це еталонна модель, розроблена для конкретних тестів, опублікована компанією Sogeti. Вона оцінює 16 ключових областей, організованих у три групи, за чотирма рівнями зрілості: початкова, контрольована, ефективна та оптимізована. Оскільки оцінювання відбувається по кожній ключовій області, команда може бути ефективною в одній області, водночас залишаючись контрольованою в іншій.
ТММі, що підтримується TMMi Foundation, – це поетапна модель зрілості тестування з п'ятьма рівнями: початковий, керований, визначений, виміряний та оптимізований. Організація досягає певного рівня лише після задоволення вимог процесів цього рівня.
CMMI це взагалі не модель тестування. Вона охоплює всю організацію розробки, а її поетапне представлення також має п'ять рівнів зрілості: початковий, керований, визначений, кількісно керований та оптимізований. TMMi була розроблена як доповнення до CMMI, а не як його заміна.
| Модель | Сфера | Структура | Рівні зрілості |
|---|---|---|---|
| TPI NEXT | Тільки процес тестування | 16 ключових зон у 3 групах, з контрольними пунктами та кластерами | 4 — Початковий, Контрольований, Ефективний, Оптимізуючий |
| ТММі | Тільки процес тестування | Поетапний, з областями процесу, призначеними кожному рівню | 5 — Початковий, Керований, Визначений, Виміряний, Оптимізація |
| CMMI | Організація розвитку в цілому | Поетапне або безперервне представлення | 5 (поетапний) — Початковий, Керований, Визначений, Кількісно керований, Оптимізація |
Метрики, що підтверджують покращення процесу тестування
Фаза перевірки згортається без чисел. Достатньо невеликого, стабільного набору метрик, зібраних до та після кожного циклу, і однакові визначення повинні використовуватися з обох сторін порівняння.
- Продуктивність виконання тестів — кількість виконаних тестових випадків за людино-годину
- Відсоток виявлення дефектів (DDP) — дефекти, виявлені під час тестування, як частка всіх виявлених дефектів, включаючи ті, про які повідомлялося після випуску
- Вартість за виконаний тестовий випадок — загальна вартість тестових зусиль, поділена на кількість виконаних тестових випадків
- Покриття вимог — вимоги, що мають принаймні один пов’язаний тестовий випадок
- Виправлення дефектів — середній вік дефекту в межах життєвий цикл дефекту
Використання GuruЗ огляду на 99 банківських даних, де під час тестування було виявлено 180 дефектів, а про 20 повідомив клієнт після випуску, розрахунок є простим.
# Defect Detection Percentage and improvement deltas def ddp(found_in_test, found_after_release): return found_in_test / (found_in_test + found_after_release) * 100 def delta(before, after): return (after - before) / before * 100 print("Defect Detection Percentage: %.1f%%" % ddp(180, 20)) print("Productivity gain: %.1f%%" % delta(10, 20)) print("Test cost change: %.1f%%" % delta(50000, 35000))
вихід:
Defect Detection Percentage: 90.0% Productivity gain: 100.0% Test cost change: -30.0%
DDP у 90 відсотків означає, що один дефект з десяти все ж таки залишився поза увагою клієнта, тому цільовий показник якості не був повністю досягнутий, навіть попри те, що продуктивність подвоїлася, а витрати знизилися на 30 відсотків. Саме цей єдиний огляд заважає команді оголосити перемогу надто рано.
Поширені помилки покращення процесу тестування
Більшість програм покращення зазнають невдачі з організаційних, а не технічних причин. Наведені нижче помилки пояснюють більшість закинутих ініціатив.
- Покращення без базової лінії. Якщо ніхто не вимірював процес до змін, ніхто не зможе довести, що зміни допомогли. Зафіксуйте базовий рівень під час Планування, а не після нього.
- Гоніння за рівнем зрілості, а не за рушійною силою бізнесу. Сертифікат, який не зменшує вартість, кількість дефектів або час виконання, є витратою, а не покращенням.
- Занадто багато змін за один раз. Коли п'ять дій виконуються в одному випуску, регресію не можна tracдо будь-якого з них.
- Автоматизація зламаного процесу. Автоматизація посилює будь-який процес, до якого вона застосовується, включаючи слабкий дизайн тестів та нечіткі критерії входу.
- Пропускатиping фаза «Дія». Покращення, яке ніколи не прописано в політиці тестування та життєвий цикл тестування ПЗ документи помирають разом з командою проекту, яка їх винайшла.
- За винятком тестерів. Люди, з якими не консультувалися щодо змін, надійно знаходять способи їх обійти.
Щоб глибше розвинути ці ідеї, розглянемо фази життєвий цикл тестування ПЗ, затягніть тестовий випадок спроектувати, формалізувати процес управління дефектами, оцінити, де тестування автоматизації дає справжню віддачу, і подивіться, як такий інструмент, як HP ALM може містити показники, від яких залежить ваша фаза перевірки.
