TPI NEXT Контрольний список

Мова: English | Українська

Як використовувати цей контрольний список:

  • Ви не зобов'язані відповідати на всі питання в наданому порядку. Коли проходите аудит, спілкуйтесь вільно, готуйтесь заздалегідь, щоб покрити всі теми
  • Будьте чесними
  • Виберіть Так, Ні або Н/З для кожного пункту
  • Натисніть Нотатки, щоб додати додаткові коментарі до будь-якого пункту. Намагайтеся робити нотатки якомога частіше
  • Ваш прогрес автоматично зберігається у вашому браузері
  • Використовуйте індикатор прогресу для відстеження завершення
  • Використовуйте Скинути, щоб очистити всі вибори та почати спочатку
  • Перевірте матрицю внизу для аналізу результатів
  • Експортуйте результати в csv або pdf

Автори: Цей контрольний список засновано на Моделі покращення процесів тестуванні від Sogeti – TPI NEXT, з додатковою категорією ШІ в тестуванні, доданою QAMania.

Повідомлення про конфіденційність: Всі дані зберігаються локально лише у вашому веб-браузері. Жодна інформація не надсилається на наші сервери або не зберігається на них.

Stakeholder commitment

Controlled

Зацікавлені сторони (стейкхолдери) мають підтримувати тестовий процес шляхом надання та забезпечення узгоджених ресурсів

Опис Так Ні Н/З Нотатки
Особу головного стейкхолдера визначено (не обов’язково задокументовано) і вона відома тестувальникам. Є той, хто приймає фінальні рішення і в нього можна піти спитати
Бюджет на тестові ресурси надається головним стейкхолдером, і з ним можливе узгодження бюджету
Зацікавлені сторони фактично надають обіцяні ресурси. А не так, що обіцяли, а потім не надали
Головний стейкхолдер відповідає за аналіз ризиків продукту і їх документування (що є вхідними даними для тестової стратегії)

Efficient

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

Опис Так Ні Н/З Нотатки
Усі релевантні стейкхолдери визначені (не обов’язково задокументовані) і відомі тестувальникам. ПО, БА, менеджери команди і 3-rd party, девопси і т.д.
Стейкхолдери активно отримують інформацію про якість як тестового процесу, так і об'єкта тестування. Активно! Не просто надати звіт, а й попросити фідбек
Стейкхолдери проактивно вживають заходів щодо аспектів, які впливають на процес тестування. Наприклад: змінюють пріоритети задач, надають додаткові ресурси, змінюють вимоги

Optimized

Зацікавлені сторони визнають і стимулюють удосконалення процесів як спільну відповідальність

Опис Так Ні Н/З Нотатки
Керівники проєкта визнають, що вдосконалення тестового процесу потребує більше часу на навчання, і для цього виділяються ресурси
Стейкхолдери готові адаптувати свій спосіб роботи до вимог тестового процесу. Це включає розробку програмного забезпечення та управління вимогами. Наприклад, розробники готові писати юніт-тести
Адаптований спосіб роботи стейкхолдерів відповідно до вимог тестового процесу спільно оцінюється тестовою організацією (командою тестування) та зацікавленою стороною. Тобто, не просто деви зробили юніт тести для галочки, а потім ще всі разом провели рев'ю

Degree of involvement

Controlled

Тестові активності розпочинаються заздалегідь, щоб забезпечити систематичну підготовку

Опис Так Ні Н/З Нотатки
Цілі тестування, обсяг і підхід узгоджені на ранньому етапі проєкту з головним стейкхолдером
Тестові активності починаються заздалегідь, якомога раніше в життєвому циклі! Наприклад, тестування вимог починається до початку розробки
Тестувальник бере участь у плануванні проєкту: враховуються залежності між тестовим процесом та іншими процесами
Тестувальник бере участь в аналізі та зниженні загальних проєктних ризиків

Efficient

Залучення тестування забезпечує надійний вихід тестового процесу та запобігання дефектам

Опис Так Ні Н/З Нотатки
Тестувальники беруть участь в аналізі впливу та ризиків змінних запитів і змін. Якщо вимоги, строки, плани міняються, тестери сигналізують про потенційні проблеми
Тестувальники беруть участь в аналізі впливу дефектів (Root cause analysis)
Тестувальники активно беруть участь в оптимізації тестової бази (не просто аналіз вимог, планів, обмежень, а й активна участь в їхньому поліпшенні)

Optimized

Залучення тестування в межах проєкту дозволяє оптимізувати як сам проєкт, так і тестовий процес

Опис Так Ні Н/З Нотатки
Тестова команда бере участь в оцінюванні проєкту. Отримані уроки (позитивні і негативні) тестового процесу записуються та використовуються для майбутніх проєктів
Тестова команда відіграє беззаперечну роль у всіх релевантних активностях розробки, її визнають і цінують ❤️. Нема такої активності, де тестувальник не може бути корисним

Test strategy

Controlled

Тестова стратегія забезпечує розподіл зусиль і ресурсів між рівнями та активностями тестування

Опис Так Ні Н/З Нотатки
Головний стейкхолдер погоджується з задокументованою тестовою стратегією. Прочитав і заапрувив
Тестова стратегія ґрунтується на аналізі ризиків продукту
Визначено відмінності між рівнями тестування, типами тестів, охопленням та глибиною тестування відповідно до проаналізованих ризиків
Для повторного тестування та регресійного тестування використовується спрощене визначення стратегії

Efficient

Тестова стратегія використовується для досягнення балансу між ризиками продукту, покриттям тестування та наявними зусиллями й ресурсами з урахуванням усіх зацікавлених сторін

Опис Так Ні Н/З Нотатки
Усі релевантні зацікавлені сторони погоджуються з визначеною (і задокументованою) тестовою стратегією. Dev, BA, PM, QA, DevOps і т.д.
Добре продумано перекриття або прогалини в тестовому покритті між рівнями чи типами тестування. Чи є traceability matrix?
Тестова стратегія включає відповідні техніки тест дизайну

Optimized

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

Опис Так Ні Н/З Нотатки
Тестова стратегія регулярно оцінюється та за потреби адаптується для майбутнього використання. Не просто раз написали і забули, а й регулярно переглядають
Сама тестова стратегія оцінюється на основі метрик з продакшену (баги, CR-и, нефункціональні метрики)

Test organization

Controlled

Тестова організація (команда) забезпечує єдність підходів, продуктів і процедур тестування, узгоджень та прозорих результатів

Опис Так Ні Н/З Нотатки
Залучені особи знають, до кого звертатися з питань тестових послуг. Всі знають, хто тест менеджер, хто тест-лід, хто тестувальник
У межах тестової організації існує структура контролю та відповідальності. Тобто, хто за що відповідає, а за що не відповідає, і може сказати ніт
Цілі тестування й обов’язки визначено та задокументовано і призначено конкретній особі або команді
Продукти та послуги тестової організації (команди) є зрозумілими для її клієнтів. Тобто, є звіти, є тестова документація, є тестові артефакти, читабельні баг репорти

Efficient

Тестова організація забезпечує наявність належної експертизи й досвіду в потрібному місці

Опис Так Ні Н/З Нотатки
Різні особи або команди, що займаються тестуванням, узгоджують організацію своєї роботи. Не просто почали робити тестування, а всіх повідомили
Тестова організація надає проєктам погоджені ресурси та послуги
Було прийнято обґрунтоване рішення, де і як позиціонувати тестову організацію. Наприклад, як окрему команду, як частину Agile команди, як окремий департамент
Виконується тестова політика, якщо вона є на рівні компанії. Якщо нема, ставте N/A

Optimized

Тестова організація забезпечує постійне покращення результатів завдяки тестовим послугам

Опис Так Ні Н/З Нотатки
Продукти й послуги тестової організації (тестові активності і артефакти) регулярно оцінюються; нові послуги додаються, якщо вони є економічно доцільними. Якщо у вас є автомейшн, який не приносить користі, то це не оптимізовано
Тестова організація несе відповідальність за успіх або провал тестових завдань. Завжди є крайній
Результативність тестової організації регулярно порівнюється з зовнішніми постачальниками або подібними структурами. Це ок хоча б дізнатись, чи може хтось зробити краще, ніж ви

Communication

Controlled

Комунікація всіх залучених осіб дає змогу ухвалювати відповідні рішення

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

Efficient

Чітка форма й зміст інформації для цільової аудиторії сприяє продуктивнішій роботі

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

Optimized

Комунікація є засобом командоутворення

Опис Так Ні Н/З Нотатки
Найкращі практики та уроки, отримані щодо комунікації та її ефективності, оцінюються (і документуються) під час і після завершення тестового проєкту для подальшого використання
Організація досліджує нові засоби комунікації й формує відповідні політики. Почали користуватись джира (наприклад), і зрозуміли, що це добре 😊

Reporting

Controlled

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

Опис Так Ні Н/З Нотатки
Звітність включає аспекти часу й/або витрат, результати та ризики
Частота та зміст звітності відповідають базовим вимогам стейкхолдерів для процесу ухвалення рішень
Звітність ведеться у письмовій формі. Артефакти наше все!

Efficient

Звітність адаптована до конкретних цільових груп для підтримки процесу ухвалення рішень

Опис Так Ні Н/З Нотатки
Витрати на підготовку звітності врівноважуються з потребами стейкхолдерів у прийнятті рішень
Звітність містить тренди й рекомендації щодо прогресу тестового процесу та ризиків проєкту
Звітність містить тренди й рекомендації щодо тестових цілей і ризиків продукту

Optimized

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

Опис Так Ні Н/З Нотатки
Звітність надає дані й/або вимірювання, які можуть бути використані для покращення тестового процесу та життєвого циклу розробки програмного забезпечення — як нинішнього, так і в майбутньому
Ці дані й метрики передаються замовникам, керівництву проєкту і компанії після завершення тестового проєкту

Test process management

Controlled

Проактивне управління тестовим процесом дозволяє виконати цілі тестування

Опис Так Ні Н/З Нотатки
На початку тестового проєкту створено тест план. Він включає щонайменше: цілі тестування, обсяг, планування, ролі та відповідальності
Тест план погоджується з головним стейкхолдером
Кожна тестова активність моніториться, і при необхідності вживаються коригувальні заходи
Тест план узгоджується з відповідними стейкхолдерами. Не тільки з менеджментом, а ще й з розробниками, бізнес-аналітиками, девопсами і т.д.

Efficient

Управління тестовим процесом з чіткими повноваженнями дозволяє швидко коригувати хід тестового проєкту

Опис Так Ні Н/З Нотатки
Очікувані відхилення від тестового плану обговорюються з головною та іншими релевантними зацікавленими сторонами. Не встигаєте потестувати до дедлайну? Повідомте всім ASAP
Зміни в тестовому плані документуються. Історія версій!
Тест-ліду делеговано повноваження на (повторний) розподіл ресурсів. Можливість робити тестування без мікроменеджменту

Optimized

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

Опис Так Ні Н/З Нотатки
Управління тестовим процесом регулярно оцінюється — як всередині команди, так і разом із зацікавленими сторонами
Уроки, отримані з попередніх тестових проєктів, використовуються для покращення управління тестовим процесом. Пишіть lesson learned і користуйтесь

Estimating and planning

Controlled

Прогнозується обсяг ресурсів, необхідних для кожної активності

Опис Так Ні Н/З Нотатки
Для оцінки зусиль на тестування використовуються прості техніки, такі як 50% часу на розробку. Навіть такий підхід краще, ніж нічого
Для кожної тестової активності вказується період її виконання, необхідні ресурси та продукти, які мають бути надані. До таких активностей належать: планування та керування тестуванням, визначення тест-кейсів і їх виконання
Залежності між фазами тестування або тестовими активностями відображаються в тестовому плануванні. Допускається певне перекриття між фазами та активностями
Оцінки та планування тестування обговорюються з головною зацікавленою стороною (стейкхолдером)

Efficient

Формальні техніки роблять оцінювання й планування надійними

Опис Так Ні Н/З Нотатки
Щоб бути максимально точними, використовуються щонайменше дві техніки оцінювання. Наприклад, експертна оцінка, триточкова, Planning Poker, Wideband Delphi
Фази тестування та/або тестові активності оцінюються та плануються із застосуванням формальних технік
Для підтримки оцінювання та планування використовуються метрики, наприклад, історичні дані з попередніх проєктів
Планування тестування включає перевірку тестової бази (вимоги, дизайн) на тестованість і оцінку тестового проєкту

Optimized

Оцінювання ґрунтується на фактичних даних організації

Опис Так Ні Н/З Нотатки
Планування тестування включає збереження артефактів для повторного використання в майбутньому
Набір технік і принципів оцінювання підтримується на рівні організації (компанії), а не тільки в межах окремого проєкту
Ключові показники/дані для визначених технік оцінювання надаються на організаційному рівні. Є корпоративні гайди, як оцінювати проєкти

Metrics

Controlled

Використовуючи визначені метрики, можливо оцінювати та контролювати тестовий процес

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

Efficient

Об'єктивність, яку надають метрики, переважає витрати на збір і аналіз даних

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

Optimized

Метрики відповідають змінним інформаційним потребам

Опис Так Ні Н/З Нотатки
Відстежується, як метрики задовольняють потребу в інформації. Деякі метрики можуть втратити актуальність, деякі можуть стати більш важливими
Зміни в інформаційних потребах призводять до появи нових або вдосконалення існуючих метрик

Defect management

Controlled

Дефекти відстежуються на індивідуальному рівні, а їхній статус контролюється

Опис Так Ні Н/З Нотатки
Життєвий цикл дефекту визначений (включно з повторним тестуванням) і впроваджений
Для кожного дефекту реєструються: унікальний ID, пов'язаний тест-кейс (якщо є), особа, яка зареєструвала дефект, дата, категорія серйозності, опис (дії для відтворення, очікуваний і фактичний результат), статус дефекту
Визначено відповідальних за подальше опрацювання дефектів
Усі залучені до оцінки й усунення дефектів мають доступ до відповідного інструмента керування дефектами

Efficient

Аналізуються спільні риси дефектів для виявлення подібних

Опис Так Ні Н/З Нотатки
Інструмент керування дефектами забезпечує контроль доступу для зміни статусів дефектів
Усі, хто фіксує та/або відстежує дефекти, використовують один і той самий інструмент або сумісні інструменти з безшовною інтеграцією
Адміністрування дефектів дозволяє створювати розширені звіти, які можна сортувати та фільтрувати різними способами
Визначаються тренди. Для цього реєструється додаткова інформація: підсистема, пріоритет, програма і версія, тестова база і її версія, першопричина, усі зміни статусу й відповідальний за вирішення

Optimized

Аналіз дефектів за спільними характеристиками допомагає уникати їх у майбутньому

Опис Так Ні Н/З Нотатки
Компанія, замовники надають набір вказівок для управління дефектами в кожному тестовому проєкті
Управління дефектами — це відповідальність лінійної чи проєктної організації (компанії), а тестовий процес надає необхідні дані. Джира менеджиться не на рівні проєкту, а на рівні компанії
Проводиться аналіз дефектів за спільними характеристиками й формуються рекомендації для їх запобігання

Testware management

Controlled

Усі використані тестові й проєктні документи в затвердженому стані ідентифікуються та реєструються окремо

Опис Так Ні Н/З Нотатки
Тестова база (вимоги, дизайн), об’єкт тестування та всі тестові матеріали ідентифікуються за назвою та версією
Кожен тест-кейс прозоро пов'язаний з відповідним документом тестової бази. Наприклад, traceability matrix на рівні документа
Команда тестування має доступ до всіх тестових артефактів
Процедура керування тестовими артефактами, тестовою базою (вимогами, дизайном) та об'єктом тестування є явно задокументованою й відомою команді

Efficient

Зв'язки між усіма (тестовими) артефактами відомі й підтримуються в актуальному стані

Опис Так Ні Н/З Нотатки
Тестова база, об’єкт тестування та тестові матеріали мають посилання з назвою та версією
Забезпечено простежуваність між тест-кейсами та вимогами. Наприклад, traceability matrix на рівні окремих вимог-тестів
Управління тест артефактами підтримується логічною структурою зберігання, ролями та системою авторизацій

Optimized

Тестові матеріали доступні для повторного використання в майбутніх проєктах і дійсно повторно використовуються (якщо це не заборонено NDA)

Опис Так Ні Н/З Нотатки
На початку тестового проєкту узгоджується (і переглядається в процесі), які матеріали будуть збережені після завершення проєкту
Існують інструкції щодо збереження тест артефактів для повторного використання, а фактичне повторне використання вимірюється
Після завершення проєкту тестові матеріали, що передаються на супровід, легко відокремлюються від тих, що не підлягають супроводу

Methodology practice

Controlled

Описаний тестовий метод забезпечує передбачуване виконання тестових активностей. Тестовий метод - набір правил, які визначають, як тестування має виконуватись

Опис Так Ні Н/З Нотатки
Процес тестування базується на задокументованому методі: метод описує набір тестових активностей, тестові продукти й додаткові вимоги до способу роботи
Метод тестування відповідає методу розробки, який використовується в проєкті
Команди тестування вважають впроваджений метод корисним у практиці. Повний консенсус, не примус

Efficient

Описаний метод тестування забезпечує практичну підтримку для тестових проєктів

Опис Так Ні Н/З Нотатки
Метод описує для кожної тестової активності її мету, відповідальну роль, використовувані техніки та передумови
Метод включає повний і вичерпний набір шаблонів
У методі зазначено обов’язкові, умовні та необов’язкові елементи
Обов’язкові й умовні елементи реалізуються на практиці

Optimized

Відхилення від методу оцінюються й використовуються для його вдосконалення

Опис Так Ні Н/З Нотатки
Тестові команди регулярно надають зворотний зв'язок щодо тестового методу
Впроваджений тестовий метод постійно вдосконалюється й поліпшується

Tester professionalism

Controlled

Завдяки спеціальним навичкам і компетенціям у сфері тестування тестувальник робить процес більш передбачуваним і керованим

Опис Так Ні Н/З Нотатки
Тестувальники пройшли спеціальне навчання або мають достатній досвід у структурованому тестуванні
Тестувальники знайомі з прийнятим методом тестування і застосовують його на практиці
Уся необхідна експертиза — галузева, бізнесова чи технічна — доступна тестовій команді
Тестувальників регулярно оцінюють як за спеціалізованими навичками тестування, так і за загальними ІТ-компетенціями під час оцінки ефективності роботи

Efficient

Тестовий персонал має спеціальну роль або функцію в тестуванні та виконує завдання згідно з очікуваннями

Опис Так Ні Н/З Нотатки
Тестувальники мають сертифікацію в галузі тестування (наприклад, TMap Next або ISTQB)
Тестувальники можуть пояснити логіку обраних технік, які були застосовані
Тестувальники отримують задоволення від роботи й підтримують добрі стосунки з іншими спеціалістами в проєкті. Щоб не вигорати і не токсичити
Цілі тестування визначено, призначено й виконано відповідно до очікувань

Optimized

Тестувальники діють із позиції забезпечення якості, постійно розвиваючи та вдосконалюючи свої навички

Опис Так Ні Н/З Нотатки
Тестувальники активно читають фахову літературу, відвідують мітапи, конфенерції, тренінги для підтримки своєї кваліфікації. Ровиваються
Функції тестування є частиною HR-системи та особистого кар'єрного розвитку в організації. Наприклад, є PDP (персональний план розвитку)
Тестувальники прагнуть до відповідальності за свою роботу та до постійного вдосконалення процесу її виконання

Test case design

Controlled

Тест-кейси забезпечують повторюваність виконання тестів і незалежність від конкретної особи

Опис Так Ні Н/З Нотатки
Тест-кейси задокументовано на логічному рівні
Тест-кейси складаються з опису: а) початкової ситуації, б) процесу змін = дій, що виконуються під час тесту, в) очікуваного результату
Тест-кейси дають уявлення про те, яка частина тестової бази (яка описує певну поведінку системи) перевіряється

Efficient

Проєктування тест-кейсів із фокусом на досягнення певного покриття є обґрунтованою реалізацією тестової стратегії

Опис Так Ні Н/З Нотатки
Тест-кейси зрозумілі та підтримувані колегами всередині тестової організації
Відомий рівень покриття тестової бази, досягнутий за допомогою тест-кейсів
Для створення тест-кейсів використовуються формальні техніки тест-дизайну
Для перевірки якостей, які не піддаються формалізації через тест-кейси, застосовуються чеклісти

Optimized

Оцінка тест-кейсів, технік тест-дизайну та дефектів дає змогу підвищити ефективність тестування

Опис Так Ні Н/З Нотатки
Дефекти, виявлені на наступних рівнях (UAT, PROD), аналізуються з метою покращення точності та ефективності тест-кейсів
Тест-кейси перевіряються й оцінюються незалежно щодо їхньої валідності та зручності підтримки
Техніки тест-дизайну оцінюються та коригуються для подальшого повторного використання

Test tools

Controlled

Інструменти тестування, необхідні для виконання конкретних активностей, доступні й використовуються

Опис Так Ні Н/З Нотатки
Необхідні тестові інструменти доступні тестовій команді й використовуються для досягнення цілей тестування
Інформація про використовувані тестові інструменти доступна
Усі залучені, включно з відділом закупівель, вважають використання конкретного тестового інструменту доцільним

Efficient

Тестові інструменти використовуються для прискорення окремих активностей

Опис Так Ні Н/З Нотатки
Поточні інструменти тестування обрано для прискорення, здешевлення або підвищення керованості процесу тестування
Інструменти доступні тестувальникам у будь-який необхідний момент
Для кожного впровадженого тестового інструменту створено бізнес-кейс
Використання цих інструментів інтегроване в тестовий процес

Optimized

Інструменти тестування та їхнє використання постійно оцінюються й удосконалюються

Опис Так Ні Н/З Нотатки
Політика щодо інструментів створена та підтримується в синхронізації з тестовою політикою
Експертиза, найкращі практики й продукти, пов’язані з інструментами тестування, збираються та публікуються для використання в майбутніх проєктах
Інструменти тестування регулярно оцінюються щодо досягнення цілей, визначених у бізнес-кейсі та політиці щодо інструментів

Test environment

Controlled

Зміни в тестовому середовищі не відбуваються несподівано

Опис Так Ні Н/З Нотатки
Вимоги до тестового середовища задокументовано
Укладено робочі домовленості з постачальниками тестового середовища, які містять завдання та відповідальності
Тестове середовище доступне команді тестування у погоджений час
Менеджера з тестування завчасно інформують про заплановані зміни в середовищі

Efficient

Тестове середовище безпосередньо відповідає вимогам відповідного рівня або типу тестування

Опис Так Ні Н/З Нотатки
Прийняття в експлуатацію (від DevOps, наприклад) тестового середовища здійснюється заздалегідь створеним чеклістом
Розробляється логічна або функціональна схема тестового середовища, яка охоплює застосунки, системи, їхні зв’язки та використання стабів і драйверів (мокапів)
Постачальники надають технічний дизайн тестового середовища, який офіційно затверджується тест-менеджером або спеціалістом із середовищ
Домовленості з постачальниками мають характер угоди про рівень послуг (SLA)

Optimized

Тестові середовища надаються тестувальникам як сервіс

Опис Так Ні Н/З Нотатки
Власником тестових середовищ є окремий підрозділ
Використання тестових середовищ регламентується стандартним контрактом
Описано, які сервіси щодо тестових середовищ включено й не включено до сфери дії, у каталозі послуг

AI in testing

Controlled

ШІ є ключовою зміною в тестовому процесі, його слід враховувати й використовувати там, де це доцільно

Опис Так Ні Н/З Нотатки
У тестової команди є доступ до чат-бота / агента зі ШІ, який допомагає у щоденній роботі
Навчання ШІ та використання даних відбувається відповідно до політик організації щодо конфіденційності даних і безпеки
Існують керівні принципи використання ШІ в тестовому процесі, включно з етичними аспектами та дотриманням нормативних вимог

Efficient

Інструменти ШІ використовуються у тестових рутинах для підвищення ефективності та результативності

Опис Так Ні Н/З Нотатки
Інструменти ШІ використовуються для аналізу тестової бази з метою виявлення потенційних ризиків і зон для покращення
Інструменти ШІ використовуються для генерації тест-кейсів на основі вимог і проєктної документації
Інструменти ШІ автоматизують повторювані тестові завдання, зокрема виконання тестів і аналіз результатів. Це може бути агент ШІ для допомоги AQA
Результати роботи ШІ перевіряються тестувальниками для забезпечення точності й релевантності
Після перевірки результати ШІ зберігаються як частина тестової документації для подальшого використання

Optimized

Інструменти ШІ постійно оцінюються й удосконалюються для покращення тестового процесу

Опис Так Ні Н/З Нотатки
Уроки, отримані під час використання ШІ, документуються й поширюються в межах тестової команди та організації
Інструменти ШІ регулярно оновлюються з урахуванням новітніх досягнень у сфері ШІ та практик тестування
Ефективність інструментів ШІ вимірюється за попередньо визначеними метриками, такими як охоплення тестуванням, рівень виявлення дефектів і економія часу

Матриця зрілості тестування

Ключові області Важливість Прогрес за рівнями
Контрольований Ефективний Оптимізований
Stakeholder Relations
Stakeholder commitment
Н З В
0%
0%
0%
Degree of involvement
Н З В
0%
0%
0%
Test strategy
Н З В
0%
0%
0%
Test organization
Н З В
0%
0%
0%
Communication
Н З В
0%
0%
0%
Reporting
Н З В
0%
0%
0%
Test Management
Test process management
Н З В
0%
0%
0%
Estimating and planning
Н З В
0%
0%
0%
Metrics
Н З В
0%
0%
0%
Defect management
Н З В
0%
0%
0%
Testware management
Н З В
0%
0%
0%
Test Profession
Methodology practice
Н З В
0%
0%
0%
Tester professionalism
Н З В
0%
0%
0%
Test case design
Н З В
0%
0%
0%
Test tools
Н З В
0%
0%
0%
Test environment
Н З В
0%
0%
0%
AI in testing
Н З В
0%
0%
0%

Огляд керівництва за пріоритетом ключових областей

Контрольований Ефективний Оптимізований
Високий
0%
0%
0%
Нейтральний
0%
0%
0%
Низький
0%
0%
0%

Інформація про проєкт та резюме