Test management approach
TMap (Test management approach) це підхід до тестування програмного забезпечення, що комбінує рекомендації щодо того як тестувати та чим керувати, в тому числі і техніки індивідуального консультування щодо тестових процесів. В моделі структуровані всі виникаючі аспекти, середовища та процедури.
Таким чином, TMap більш вузько спеціалізований, ніж технологічні моделі, такі як ITIL або V-модель, які розглядають весь процес розробки програмного забезпечення. TMap є зареєстрованою торговою маркою Sogeti Nederland B.V. і є стандартним у багатьох організаціях у всьому світі. Цей підхід можна порівняти з TPI® (поліпшення тестового процесу). Хоча TMAP виключно структурує тести, в той час як TPI® хоче оптимізувати весь процес тестування. TMAP базується на практичному досвіді і, таким чином, не є теоретичним, а прагматичним методом.
Метод був створений і описаний Мартіном Полом, Рудом Тенісоном та Еріком фон Фенедалем в 1995 році. В кінці 2006 була опублікована нова версія TMap Next описана новими авторами (Тім Конен, Мішель Фрон, Лео фон дер Фльст та Барт Брьокмен). Нова версія більше фокусується на тест процесі і робить наголос на бізнес цілях.
TMap створено голландським офісом Sogeti що входить до корпорації Capgemini.
TMap Next ділиться на 4 блоки: управління тестуванням, інструментарій, структура та гнучкість.
Тест менеджер може керувати процесом в 4 аспектах: час, кошти, ризики та результати.
TMap виділяє техніки для провадження методу.
TMap Next має фази, які необхідно виконати для кожного тесту:
- Планування;
- Підготовка;
- Специфікація;
- Виконання;
- Оцінка та завершення
ще можуть виділятись дві додаткові фази:
- Інфраструктура;
- Управління
TMAP дозволяє адаптуватися до навколишнього середовища, включаючи Agile і Скрам.
TMAP базується на досвіді різних проектів враховує поточні тенденції орієнтований на тестовий процес оптимізує охоплення ризиків та глибину тестування максимізує залучення ділових партнерів
Поведінко орієнтоване управління тестуванням (Behavior Driven Test Management - BDTM)
[ред. | ред. код]Вибір тест кейсів ґрунтується на наступних міркуваннях: які ризики існують, яким має бути результат, скільки часу виділено на тестування, і скільки то буде коштувати? На основі цих міркувань, які приймаються в консультації з клієнтом, TMap підтримує бізнес-процес і близький до клієнта.
Особливості підходу BDTM:
Загальні зусилля для тестування стосуються ризиків системи, яка перевіряється для організації. Використання людей, ресурсів та бюджету зосереджується на тих частинах системи, які є найбільш важливими для організації. TMAP пропонує можливість визначити, скільки ризиків охоплено вибраним тестом, і таким чином оцінити залишковий ризик. Орієнтовні зусилля та планування процесу тестування тісно пов'язані з встановленою стратегією тестування. Це полегшує внесення змін, оскільки існує план щодо часу, бюджету та ресурсів. Замовник бере участь у процедурі тестування, щоб краще вирішувати його побажання. Підхід BDTM також може зробити видимими наслідки майбутніх і минулих рішень.
Процес структурованого тестування підрозділяється на:
Майстер тест план та управління всім процесом тестування Прийомочні та системні тести Тести розробників
На цьому етапі здійснюється ризик-менеджмент продукту та розробляється стратегія тестування, бюджет та план тестування. Вибрані продукти для доставки, тестова інфраструктура та організація тестування. Так званий генеральний план створюється спільно з замовником. Тест менеджер, у координації з замовником та іншими зацікавленими сторонами, визначають, що тестується, на якому рівні і з якою інтенсивністю. Мета полягає в тому, щоб виявити найбільш важливі помилки якнайшвидше та максимально економічно. Майстер тест план є основою для планування окремих етапів тестування. В Майстер тест плані визначені важелі керування процесами тестування.
На цьому етапі відбувається:
- Складання договору
- Розуміння роботи
- Визначення ризиків
- Встановлення тестову стратегію
- Оцінка витрат
- Планування
- Визначення результатів (продуктів) тестування
- Визначення пріоритетів
- Визначення інфраструктури
- Організаційні роботи
- Визначення ризиків тестового процесу та контрзаходів
- Зворотній зв'язок та консолідація плану
Прийомне та системне планування розглядаються як окремі автономні процеси. Вони мають власний план тестування, власний бюджет і часто власне тестування.
Тестування розробників - це тести, які вимагають знання технічної реалізації системи. Тестування розробників не вважається автономним процесом від TMap. Розробник проводить тести самостійно.
Як і процес розробки системи, процес тестування складається з безлічі різних видів діяльності. Різні види діяльності представлені у фазовій моделі.
Існують наступні етапи:
- планування
- фазний контроль
- встановлення та обслуговування інфраструктури
- підготовчий етап
- фаза специфікації
- етап реалізації
- завершальний етап
Фаза планування закладає основу для керованого та високоякісного процесу тестування. Ось чому важливо почати цей етап якомога раніше.
На цьому етапі відбувається:
- Складання договору
- Розуміння роботи
- Детерміновано тестовий базис
- Аналіз товарних ризиків
- Створення тестової стратегії
- Оцінка витрат
- Визначення планування
- Визначення метрик
- Визначення тестових продуктів
- Визначення організації
- Визначення інфра
Первинний процес випробування рідко виконується за графіком, тому виконання плану тестування повинно бути перевірено та, якщо необхідно, скореговано. Це відбувається на контрольній фазі.
На цьому етапі відбувається:
- Управління
- Моніторинг
- Звітність
- Корегування
Тут передбачена необхідна інфраструктура тестування та ресурси. Різниця між тестовими середовищами, тестовими інструментами та робочими місцями.
На цьому етапі відбувається:
- Специфікація інфраструктури
- Побудова інфраструктура
- Специфікація припущення про інфраструктуру
- Прийняття інфраструктури
- Обслуговування інфраструктури
- Збереження інфраструктури
Тут, в першу чергу, виконується перевірка на тестування тестової бази. Мета цієї фази - перейти до тестової бази відповідної якості.
На цьому етапі відбувається:
- Компіляція тестової бази
- Створення чек-лістів
- Оцінка тестової бази
- Створення шаблону звіту про тестування
Фаза специфікації визначає необхідні тести та їх передумови (preconditions). Мета полягає в підготовці якомога ретельніший, щоб тести могли виконуватися якомога швидше, коли розробники доставляють тестовий об'єкт.
На цьому етапі відбувається:
- Створення Test Design
- Визначення вихідних точок
- Специфікація Прийняття тестового об'єкта
Основна мета етапу реалізації - отримати розуміння якості об'єкта тестування шляхом виконання узгоджених тестів.
На цьому етапі відбувається:
- Прийом тестовового об'єкту до роботи
- Підготовка передумов для виконання тестів
- Виконання тестів та повторних тестів
- Експертиза та оцінка результатів тестування
TMAP пропонує багато переваг з точки зору повторюваності процесу. Мета цього етапу полягає в тому, щоб зберегти продукти етапу виконання, з тим щоб вони могли бути пізніше перероблені, можуть бути продукти, тести, тестові середовища, досвід та оцінки.
На цьому етапі відбувається:
- Оцінка процесу тестування
- Збереження тестового продукту
TMap підтримує правильне виконання структурованого тестового процесу з повним набором інструментів. Це зосереджено на роботі з наступними темами:
Техніка: як тестувати Наступні методи доступні:
- * Тестування навантаження
- * Керування помилками
- * Створення метрик
- * Аналіз продуктових ризиків
- * Testdesign
- * Тестування продуктів
Інфраструктура: де і з чим буде випробувано Для того, щоб бути в змозі протестувати, необхідно тестове середовище, тестові інструменти та робочі місця.
Організація: хто тестує Структуроване тестування вимагає уваги до таких питань:
- * Технічні рекомендації
- * Постійна організація тестування
- * Перевірте організацію в проекті
- * Експерти з тестування
- * Тест ролі
TMAP - це підхід, який може бути використаний у всіх тестових ситуаціях та у поєднанні з усіма методами розробки системи. На сьогодні підходи до розвитку ІТ можуть бути надзвичайно різноманітними, ось деякі згадані програми, в яких TMAP може бути використаний.
- Клієнт-постачальник (аутсорсинг)
- Інтерактивний, інкрементальний, водоспад і гнучкі підходи
- Нове розробка, підтримка та міграція інформаційних систем
- Комбіновані процеси розробки, такі як внутрішній, багаторазовий доступ, використання стандартних пакетів, збірка придбаних модулів, все в рамках єдиної ІТ-архітектури
- Для покриття нефункціональних вимог інформаційної системи в процедурі тестування
- У ситуаціях, коли велику увагу слід приділити комунікаційним процесам та пов'язаним з ними навичкам
- Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon: TMap Next. dpunkt, Heidelberg 2015, ISBN 978-3-89864-461-7.
- Bob Legrand: Q-Course Quality and Organization. Lulu Press, Morrisville 2004, ISBN 1-4116-1020-2.
- Workbook TMap Suite. Study for TMap Suite Certification. Sogeti Netherlands B.V. Vianen, 2016
- Joseph K. Berry: TMap, Version 3.2 (Software). Wiley, Hoboken 1996, ISBN 0-470-23704-X.
- TMap Next: For Result-driven Testing (2006)
Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon, Rob Baarda
ISBN 9072194802 - Software Testing: A guide to the TMap Approach (2001)
Martin Pol, Ruud Teunissen, Erik van Veenendaal
ASIN 0201745712
Категорія:Тестування програмного забезпечення
 | На цю статтю не посилаються інші статті Вікіпедії. Будь ласка розставте посилання відповідно до прийнятих рекомендацій. |