Рівень 8. Тест-план. Робота з вимогами
На цьому рівні ти вивчиш
як працювати з вимогами, поки ми знищуємо імперські війська в системі Dagobah.
Поспішай, нам потрібна твоя допомога!
Ролі під час створення тест-плану
Нижче перелічено основні ролі, які вам доведеться приміряти на себе під час створення тест-плану. Це не означає, що на вашому робочому місці ви виконуватимете їх усі (хоча, найімовірніше, так і буде). Зрозуміло, що потрібно бути готовим до всього. Адже не скажеш роботодавцю: «Мені якось не дуже подобається адмініструвати базу даних, попросіть Васю це зробити». Перелічимо всі ролі, які знадобляться, але не варто зосереджуватися на них надто довго, адже ця інформація вже була в 4-му рівні. Пригадаймо, які ролі ми розглядали.
Основні ролі:
- Тест-менеджер, менеджер проєкту з тестування
- Тест-аналітик
- Тест-дизайнер
- Тестувальник, інженер з тестування
Допоміжні ролі:
- Адміністратор тестової системи та застосунків, що підтримують життєвий цикл тестування
- Адміністратор баз даних, менеджер баз даних
- Розробник тестів
Після того як ти дізнався про всі ролі в тестуванні, пропоную розібрати кожну детальніше. А тим часом Імперська армія відступила й займається своїми справами.
Тест-менеджер, менеджер проєкту з тестування
Здійснює управлінський контроль (management oversight)
Відповідальність:
- Забезпечує технічний напрям
Приклад: розподіляє обов'язки з виконання та проєктування тестів між іншими тестувальниками. У нашому випадку дає вказівку створити тест-план.
- Отримує необхідні ресурси
Приклад: з'ясовує, скільки ресурсів вам знадобиться (серверів, смартфонів, комп'ютерів тощо), і запитує їх у відділі техпідтримки до початку робіт.
- Забезпечує управлінську звітність
Приклад: оформлює необхідну документацію за попередніми двома пунктами.
Зазвичай це обов'язки тімліда тестувальників. Якщо ви єдиний тестувальник у відділі, то вам пощастило: займатися всім цим доведеться лише вам.
Тест-аналітик
Визначає та пріоритизує тестові сценарії й забезпечує їхню розробку
Відповідальність:
- Розробляє план тестування
Ця роль несе головну відповідальність за координацію дій зі створення плану тестування
- Розробляє модель тестування
Приклад: обирає види тестування, кількість і тривалість тестових циклів
- Оцінює ефективність тестування
Здійснюється шляхом розрахунку покриття проєкту тестами, створення мапи проєкту та обчислення рівня якості ПЗ у відсотках
Тест-дизайнер
Встановлює та визначає операції, атрибути й зв'язки тестових класів
Відповідальність:
- Встановлює та визначає тестові класи
- Встановлює та визначає тестові набори (пакети)
Приклад: створює завдання з написання тест-кейсів і тест-скриптів. Об'єднує всі тести в тест-сьюти
Тестувальник, інженер з тестування
Виконує тестові сценарії
Відповідальність:
- Виконує тести
- Фіксує результати
- Відновлює тести та систему після збоїв
- Документує запити на зміни (виявлені дефекти, пропозиції щодо покращення)
Як усе складно! Давайте я спробую пояснити все простими словами клінгонською.
Який жах! Ви не розумієте клінгонської?!
Гаразд, поясню так:
1. Тест-план починається з тест-менеджера або тімліда. Він ставить завдання з тестування та створення тестової документації й зобов'язаний надати технічну документацію до фічі або чітко дати зрозуміти, де її можна знайти. Під документацією маються на увазі вимоги до тестування, мокапи, дизайн тощо. Про вимоги поговоримо одразу після цього розділу.
2. Тест-аналітик насамперед займається тест-планом. Він прописує стратегію, обирає види тестування, вирішує, які саме види тестування потрібні, складає розклад тестування, ділить усе на тестові розділи (за областями, які покривають тест-кейси) — словом, заповнює всі пункти тест-плану.
3. Далі настає черга тест-дизайнера. Для кожного тестового розділу він створює тест-кейси, чек-листи або автотести. Після створення тестового покриття на ньому лежатиме відповідальність за звіт про це покриття. Також він відповідає за підтримку всіх тестів.
4. Час тестувати! Наприкінці тестувальники проходять усі тест-кейси, створюють за ними баг-репорти, і тестування завершується гучною перемогою над багами та релізом.
Робота з вимогами
Приклад нетестованої вимоги до продуктивності ПЗ
- Час відгуку системи має бути в прийнятних межах
- Час відгуку (відгуку на якій операції?) системи (що таке система в цій вимозі: UI, DB, клієнт + сервер + мережа?) має бути (за яких умов? за якого навантаження?) в прийнятних межах (які ці прийнятні межі в цифрах?)
Що ми випустили з вимоги?
Який час відгуку? За якого завантаження каналу пропускання? «Не повинен перевищувати 1 секунди» — за яких умов? Зрештою, час виконання чого?!
Що з ресурсами? Якими вони мають бути?
Приклад тестованої вимоги:
- Час відгуку системи з погляду кінцевого користувача (end-to-end) під час продуктивного навантаження (50 користувацьких сесій у режимі «менеджер» / 15 користувацьких сесій у режимі «аналітик») за завантаження каналу пропускання від клієнтської системи до сервера застосунків у межах 50% для мережі 100 Mb/sec не повинен перевищувати однієї секунди для операцій створення запису та трьох секунд для операцій пошуку запису.
- Час виконання аналітичних звітів визначається окремо для кожного звіту.
- Обсяг використаної оперативної пам'яті має залишатися стабільним.
Практичні поради:
- Зміни у вимогах мають однозначно відображатися у зміні функціональності системи та тестового набору, що її покриває
- Аналіз покриття вимог рекомендується проводити на етапі проєктування тестів за умови, що процес гарантує фіксовані вимоги в межах ітерації
- За умови «плаваючих» вимог аналіз покриття виконується за фактом поставки версії системи, до якої входить набір актуальних вимог. Такий підхід збільшує загальний час, відведений на тестування, через технологічні простої
- Кожна вимога має бути протестована (мати тест)
- Кожен тест має стосуватися якоїсь вимоги
- Вимоги можуть народжуватися з тестів (за використання agile-методологій)
- Вимоги обов'язково мають перебувати під контролем версій.
Перш ніж магістр перевірить твої знання, поглянь, чим зараз займаються сили зла,
Перевір себе, перш ніж рухатися далі
1. Що таке вимога до ПЗ?
2. Наведіть приклад тестованої вимоги.
3. Наведіть приклад нетестованої вимоги.
Огляд артефактів тестування за ролями
Потрібно розуміти, що тестова документація створюється для всіх ролей у тестуванні. Більш того, вона необхідна для процесу тестування загалом, а також для програмістів, продактів та інших фахівців, з якими ви працюватимете. Далі перелічено ролі, до яких найчастіше належить цей вид тестового документа.
Тестувальник ПЗ:
Аналітик:
Тест-дизайнер
Тест-менеджер
- Test script
- Test log
- Test Case
- Test-Ideas List
- Workload Analysis Model
- Test Data
- Test results
- Test Strategy
- Test Automation Architecture
- Test Environment Configuration
- Test Suite
- Test Plan
- Test Evaluation Summary
Усе це — графік структури артефактів
тестування, запропонованої стандартом IEEE 829
Артефакти тестування — це документи, що зберігаються в системі контролю версій, або заповнені форми в системі управління тестуванням та вихідні звіти, які вони генерують.
Подальший огляд артефактів тестування наведено в розрізі визначених раніше ролей у групі тестування
Тестувальник ПЗ
Test script – покроковий опис дій, які потрібно виконати для проходження одного тестового сценарію. Тестовий скрипт має описувати дії для ручного виконання, придатні для передачі в групу автоматизації тестування.
Test log – протокол виконання скрипта в системі: результат виконання тестового скрипта, що заноситься в тестовий звіт, або відмітка про нормальне проходження тестового набору в контрольному листі.
Аналітик
Workload Analysis Model – робоча модель навантаження, яка визначає умови та конфігурацію системи під час проведення тестування.
Test Data – формальний опис тестових даних, які будуть використані для проведення тестування, або алгоритмів отримання тестових наборів, якщо їх неможливо описати та подати через розмір чи складність.
Test results – підсумковий звіт, що складається на основі тестових логів та інформації про дефекти, зафіксовані для поточного стану системи.
Test Case – формальна специфікація стану системи до виконання тестового набору, опис вхідних умов, дій тестового сценарію (можливо, набір посилань на тестові скрипти) та очікуваного результату (найчастіше у вигляді опису стану системи після виконання тестового сценарію).
Test-Ideas List – нумерований список ідей, які можуть бути реалізовані у вигляді тестових сценаріїв. Слугує для попереднього узгодження напряму та підходів до тестування.
Мабуть, ти втомився, темна сторона теж відпочиває. Послухай жартик:
"Яким же я тоді був зеленим..." — подумав Йода після перегляду першого епізоду.
Тест-дизайнер
Test Strategy – документ, який визначає стратегію (сукупність дій, типів тестів, що виконуються, потрібних ресурсів тощо) тестування системи. RUP пропонує стратегію тестування як основну частину Тест-плану проєкту з тестування.
Test Automation Architecture – документ, що фіксує підходи до автоматизації тестування, а також специфікації тестів, які підлягають автоматизації, та опис інструментальних рішень для автоматизації тестування ПЗ.
Test Environment Configuration – опис програмної та апаратної конфігурації тестового стенда, а також особливостей налаштування й адміністрування прикладного ПЗ.
Test Suite – документ, що описує набір тестових сценаріїв, які покривають бізнес-транзакції, та відображає можливості аналізу стану системи під тестом шляхом аналізу тестових логів і повідомлень про зафіксовані помилки.
Тест-менеджер
Test Plan – документ, що описує цілі та завдання тестування застосунку або системи під тестом, включно з описом загального підходу до тестування, стратегії тестування, переліку артефактів, що постачаються, і плану використання ресурсів.
Test Evaluation Summary – документ, що містить підсумковий аналіз результатів тестування в розрізі витрачених ресурсів і досягнутих результатів, готовності системи до випуску та прогнозів щодо покращення співвідношення витрати/результат на подальших етапах проєкту.
Ура! Тепер ти знаєш, що таке тест-план, і легко зможеш його написати! Думаєш, це жарт?
Ні, не жарт! Швидше за все, ти вже почав створювати тест-план і переглянув усю документацію, передану на попередньому рівні. Саме час відкрити твій шаблон тест-плану та почати його заповнювати. А з чого ж почати? Далі все по пунктах...
Магістр усе тобі детально пояснить.
Для мене завжди було загадкою, як штурмовики ходять до вбиральні у своїх скафандрах.
Ах так, вибач, я відволікся. Давай почнемо з визначень...
Визначення
Проєкт – Проєкт «bla bla» призначений для створення .......
Функціональне тестування – тестування функцій застосунку на відповідність вимогам
Стрес-тестування – оцінка надійності та стійкості системи в умовах перевищення меж нормального функціонування. Тестове середовище – набір програмного забезпечення для відтворення дій користувача, максимально наближених до реальних.
ТЗ (технічне завдання) – документ, що описує набір технічних і функціональних вимог до програмного продукту. Юзер-сторі – покрокова інструкція, що відтворює дії користувача.
Purpose
Цілі документа (purpose):
Метою цього тест-плану є опис процесу тестування сайту bla-bla.ru (повна адреса http://bla-bla.ru). Цей документ дає змогу отримати уявлення про планові роботи, терміни та стратегії тестування. У цьому документі не передбачено опису тест-кейсів, посилань на знайдені дефекти, а також їх аналізу.
Мета тестування
Метою тестування проєкту є перевірка всіх його функціональних можливостей на різних версіях браузерів, за різних роздільних здатностей монітора, а також проведення серії стрес-тестів для виявлення вузьких місць і вразливостей проєкту. Підсумковими документами процесу тестування будуть: звіт про результати тестування, що містить опис тестових середовищ і знайдених дефектів та недоліків; висновок тестувальників про загальний стан проєкту, який являє собою графік співвідношення критичних дефектів до їхньої загальної кількості. Тестування планується проводити вручну, без використання автоматизованих систем.
Стратегія
Стратегію процесу тестування заплановано в три етапи. Розглянемо етапи проведення процесу тестування:
Перший етап полягає в аналізі ТЗ, складанні критичного чек-листа, складанні тест-плану, а також частковому прогоні функціональних тестів.
Другий етап буде присвячено деталізації функціонального чек-листа та детальному прогону функціональних тестів із виявленням і описом дефектів.
На третьому етапі буде проведено стрес-тестування та навантажувальне тестування з описом знайдених дефектів або демонстрацією відповідності системним вимогам.
Таким чином досягається максимальна деталізація глибини тестування, що, своєю чергою, дає змогу точніше визначити необхідні ресурси, а також дозволяє розробникам проєкту почати виправляти дефекти на найраніших етапах.
Зважаючи на відмову від ведення дефектів у баг-трекері, усі виявлені дефекти передаватимуться менеджерам проєкту в письмовому вигляді через баг-листи.
На першому етапі буде застосовано смоук-тестування, під час якого уточнюватимуться вимоги, визначатимуться та конфігуруватимуться тестові середовища.
До початку другого етапу буде сформовано критичний чек-лист, а також чек-лист із функціонального тестування та юзер-сторі.
На другому етапі проводиться детальне тестування функціоналу проєкту, збираються й описуються дефекти. Кожен чек-лист прогоняється для кожного браузера.
Третій етап завершує роботи з тестування. У ньому проводиться встановлений набір тестів для виявлення вразливостей. Такий вид тестування досить затратний за часом, тому необхідний набір тест-кейсів розробляється спільно з розробниками проєкту.
Смоук-тестування
Мета: накидати скелет чек-листів для функціонального тестування та стрес-тестування. Цей метод застосовується з мінімальним набором тестів і мінімальним ТЗ. Метою цього тестування не є виявлення помилок, проте якщо на цьому етапі виявляться явні дефекти, тестувальник їх зафіксує.
Функціональне тестування
Мета: виявлення функціональних помилок, невідповідностей ТЗ та очікуванням користувача шляхом реалізації стандартних, а також нетривіальних тестових сценаріїв.
Тестування в певному середовищі
Мета: перевірити коректну роботу та дизайн проєкту в різних браузерах і за різних роздільних здатностей монітора.
Опис конфігурацій:
Браузер/Роздільна здатність
1680*1050/Internet Explorer 11
Моя зовсім нічого не розуміти! Тест-план великий і страшний. Там усе англійскою. Жжжах!! Бррр! Магістре, допоможи моя!
Моя зовсім нічого не розуміти! Тест-план великий і страшний. Там усе англійською. Жжжах!! Бррр! Магістре, допоможи моя!
Що за голос у моя в голові? Здається, магістр Йода почав телепатичну передачу, щоб пояснити нам сенс тест-плану. Хай пребуває з нами Сила!
Мій юний падаване. Ми ніколи не залишимо тебе в невіданні. Нагадаю, що ти завжди можеш звернутися по допомогу до магістрів у соцмережах або через форму. Сподіваюся, моє пояснення тобі допомогло. Але це ще не вся допомога — ось тобі приклад тест-плану, який писав мій найкращий падаван щодо іншої фічі. Користуйся ним з розумом, не копіюй усе підряд, і хай пребуде з тобою Сила!
Підсумки теоретичної частини курсу,
усього, що ми вивчили до цього рівня
Цей підсумок потрібен, щоб ви переглянули кожен пункт і згадали все, що знаєте про нього, — така собі невелика ретроспектива. До цього йшлося про теорію тестування та тестову документацію. Теорія... теорія... вона така нудна, але все ж необхідна, перш ніж ми почнемо вже тестувати й вивчати практичні аспекти на конкретних видах тестування. Це необхідна база, без неї в космос тестування потикатися не можна. Закріпити базу ти зможеш, написавши тест-план. Пригадаймо, що ми вивчили:
- Визначення тестування ПЗ та якості інформаційних систем
- Місце тестування в процесі розробки ПЗ
- Вимоги до процесу тестування
- Цілі та завдання тестування
- Рівні тестування
- Етапи тестування
- Види тестів
- Ролі в тестуванні
- Робота з дефектами
- Огляд артефактів тестування та тестової документації
1. Як ви розумієте нетестовану вимогу?
2. Як зробити тестованою вимогу, яка такою не є?
Час покаже, що ти зрозумів із курсу.
А зараз пройди тест рівня — здивуй магістра.
Сподіваюся, ти надіслав тест-план ще з минулого рівня, а якщо ні, то поспішай
його надіслати. Форма та сама. Якщо ви надсилали його раніше, повторно надсилати не потрібно.
Саме час перевірити всі твої знання, отримані за теоретичну частину курсу. Це фінальний тест із теорії, у ньому зібрано запитання за перші 8 рівнів. Скористайся силою тестування, щоб його пройти, а також повтори пройдений матеріал перед тестом.