QA Galaxy QA Academy

Рівень 4. Ролі в тестуванні. Тест-дизайн

Рівень 4

Ролі в тестуванні. Тест-дизайн

З назви не дуже зрозуміло, про що йтиметься в цьому уроці. Простими словами, сьогодні ви дізнаєтеся, чим доводиться займатися тестувальникам і які завдання входять у цю професію. Тема дуже широка й охоплює не лише спеціалізацію Junior QA, а й усі наявні посади у сфері тестування. Дуже важливо знати, хто є хто на вашій майбутній роботі.

Отже, розглянемо процес розробки ->

Картинка, звісно, жартівлива. Але, як кажуть, у кожному жарті є частка правди. Вона дуже яскраво показує перекоси у світі IT-розробки, і водночас одразу зрозуміла послідовність процесу.

Але зараз нас цікавлять процеси всередині кола тестувальників. Тому ми звернемо увагу на Ролі в тестуванні — це посади/робочі обов'язки в ієрархії тестування, а також на Активності — те, що ці люди безпосередньо роблять. За свою кар'єру я на практиці перепробував усі ці ролі, тому із задоволенням вам їх представляю, але одразу скажу, що початківцю-тестувальнику не доведеться зіткнутися з усіма ними одразу.

Активності процесу тестування ПЗ

Увесь процес тестування представлений приблизно 20 основними активностями:

- Для наочнішого структурування активностей за етапами робіт їх розглянемо в групах, що відповідають етапам робіт із тестування.

- Не всі активності є строго обов'язковими, але більшість із них рекомендовані до виконання.

Отже, які ролі трапляються в тестуванні:

Роль
Опис

Навколо ролей і завдань, пов'язаних із тестуванням та забезпеченням якості, склалося кілька протилежних ідейних течій, які ретельно культивують їхні прихильники. Погляди значною мірою протилежні й суперечливі. З одного боку, тестування сприймають як напівмеханічний процес, що не потребує особливої кваліфікації: тестувальника бачать таким собі «клікальником», який просто ганяє застосунок, чекає, поки той «впаде», потім радісно повідомляє про помилку й продовжує в тому самому дусі.

Але в нас із вами зовсім інший підхід — епоха простого клікання давно минула, і в основі керування процесом трудовитрат, часом чи ресурсами лежать методології Agile або RUP. А в основі того самого знаменитого клікання мишкою лежать техніки тест-дизайну.

Я розкрию вам секрет усіх айтішників: хоч усі й кажуть, що користуються якоюсь там методологією, і з гордістю заявляють: «У нас усе по Scrum-у», — у реальному світі в кожної компанії свій мікроклімат і свої правила, які накладатимуться на обрану методологію. Давайте докладніше розглянемо ці методології. Хоча постривайте, спочатку дізнаймося, чим тим часом зайняті сили зла?

А ким же я буду в цій таблиці??? Мабуть, візьмуть мене тест-менеджером одразу після курсів і возитимуть додому на червоній машині ...

Ну так, розмріявся! Роль джуніорів — це Tester і Test Designer. Це базові ролі, потрібні кожному тестувальнику. Проходити тести й писати тести ви навчитеся на цих курсах. А от тест-аналіз приходить лише з досвідом. Набравши достатньо знань про проєкт, ви зможете аналізувати тест-кейси інших тестувальників і одним поглядом робити в них діри!! Або хоча б знаходити недоліки і, що не менш важливо, — надлишкові кроки та перевірки.

Що ж до Test Manager, то це, звісно, вищий пілотаж, але ви навчитеся створювати тест-план, у якому якраз присутні всі перелічені вище ролі, і на собі випробуєте задоволення побути тест-менеджером.

Далі — докладніше про активності в ролях тестування.

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

А тепер правда. А правда в тому, що Agile — процес модний на сьогодні, і всі компанії хочуть його використовувати. Тому знання цієї методології — великий плюс у резюме, а іноді навіть необхідність. Але попри те, що всі хочуть використовувати Agile, мало хто його справді використовує, бо Agile передбачає щоденні мітинги та регулярні ретроспективи. Розберемо гнучку методологію розробки докладніше. Її суть подано на схемі:

Agile — це сімейство процесів розробки, що поєднує принципи всіх гнучких методологій. Agile не передбачає покрокових інструкцій і конкретних рекомендацій, а лише окреслює загальні принципи, які використовують гнучкі методології. Вони значною мірою стали основою двох найпоширеніших із них — Scrum і Kanban.

У ваших інтересах докладніше прочитати про Scrum і додати цю чудо-мітку у своє резюме :')

Гнучкі методології націлені на мінімізацію ризиків шляхом зведення розробки до серії коротких циклів, які називають ітераціями й які зазвичай тривають два-три тижні. Кожна ітерація сама по собі виглядає як програмний проєкт у мініатюрі та включає всі завдання, необхідні для видачі невеликого приросту функціональності: планування, аналіз вимог, проєктування, програмування, тестування й документування. Хоча окрема ітерація, як правило, недостатня для випуску нової версії продукту, мається на увазі, що гнучкий програмний проєкт готовий до випуску наприкінці кожної ітерації. Після завершення кожної ітерації команда переоцінює пріоритети розробки.

Отже, ми з'ясували ролі, методології та активності в тестуванні. Тепер ми готові перейти до найвідповідальнішої практичної частини тестування. Від знання й уміння користуватися тест-дизайном залежить уміння тестувати. Це і є «ядро» практичного тестування.

Приклад позитивного тест-кейсу (усі поля OK):

Дії

Очікуваний результат

1. Відкриваємо форму надсилання повідомлення

  • Форму відкрито
  • Усі поля за замовчуванням порожні
  • Обов'язкові поля позначено *
  • Кнопка "Відправити" неактивна

2. Заповнюємо поля форми:

  • Тип звернення = Консультація
  • Контактна особа = йцукенгшщзйцукенгшщзйцуке
  • Контактний телефон = +38-056-111-11-11
  • Повідомлення
  • Поля заповнено
  • Кнопка "Відправити" — активна (Enabled)

3. Натискаємо кнопку "Відправити"

  • Повідомлення "Заявку відправлено" виведено на екран.
  • Нова заявка з'явилася в списку на сторінці "Заявки".

4. Відкриваємо форму надсилання повідомлення

  • Форму відкрито
  • Усі поля за замовчуванням порожні
  • Обов'язкові поля позначено *
  • Кнопка "Відправити" неактивна

5. Заповнюємо поля форми:

  • Тип звернення = Консультація
  • Контактна особа = @#$%^&;.?,>|\/№"!()_{}[<~
  • Контактний телефон = (916)333-33-33
  • Повідомлення = йццуйцуйц(...)йцу - 1024 символи
  • Поля заповнено
  • Кнопка "Відправити" — активна (Enabled)

6. Натискаємо кнопку "Відправити"

  • Валідаційне повідомлення з усіма помилками виведено на екран:
    "У полі "Контактна особа" заборонено використання цифр і спец. символів."
  • Заявка НЕ з'явилася в списку на сторінці "Заявки".
Вебінар рівня 4

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

Ура! Ти дістався кінця цього рівня!

Знаю, було дуже цікаво. Мені теж подобається вчитися разом із тобою. Але щоб стати справжнім тестувальником, потрібно не лише прочитати курс, а й щось із нього запам'ятати. Пройди тест і дізнаєшся, що ти запам'ятав сьогодні.

Пройти тест

Відчуваю, набуваєш ти мудрого погляду тестувальника. Скористайся ж ним на практиці.

Завдання 1 буде тобі під силу:

скористатися технікою тест-дизайну під час створення тест-кейсу. Напиши тест-кейс для тестування контактної форми на сайті з печивом.

Для створення тест-кейсу скористайся цим шаблоном Google-таблиці.

Завдання 2 ще цікавіше:

Протестуй сайт і знайди всі баги! Усе просто! Те, що працює неправильно, — це баг!

Надішли всі завдання мені через форму

Сайт

форма

Мій юний падаване, я приніс тобі корисні статті для проходження рівня:

Стаття про перевірку email: Валідація email-адрес у суворому варіанті.

І антитеза: про те, що стандарти надто заплутані

Також корисно знати:

У якому форматі буває поштова адреса

У якому форматі пишуться адреси вебсайтів

У якому форматі використовуються телефони

Рівень 5

Для переходу на рівень 5 необхідно набрати щонайменше 19.2 бала (60%) за завдання рівня 4.

Тест-менеджер, менеджер проєкту з тестування

(Test Manager, Test Project Manager)

Здійснює управлінський контроль (management oversight).

Відповідальність:

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

Тест-дизайнер (Test Designer)

Визначає, пріоритезує та забезпечує розробку тест-кейсів.

Відповідальність:

  • Розробляє план тестування
  • Розробляє модель тестування
  • Оцінює ефективність тестування

Тестувальник, інженер із тестування

(Tester)

Виконує тести.

Відповідальність:

  • Виконує тести
  • Фіксує результати
  • Відновлює тести та систему після збоїв
  • Документує запити на зміну

Адміністратор тестової системи, застосунків, що підтримують життєвий цикл тестування (Test System Administrator)

Забезпечує керування та підтримку тестових середовищ і даних. Відповідальність:

  • Адмініструє систему управління тестуванням
  • Інсталює тестові системи та керує доступом до них

Адміністратор баз даних, менеджер баз даних (Database Administrator, Database Manager)

Забезпечує керування та підтримку тестових даних (баз даних).

Відповідальність:

  • Адмініструє тестові дані (бази даних)

Тест-аналітик (Test Analyst)

Встановлює й визначає операції, атрибути та зв'язки тестових класів.

Відповідальність:

  • Встановлює й визначає тестові класи
  • Встановлює й визначає тестові набори (пакети)

Розробник тестів (Implementer)

Розробляє юніт-тести (unit tests), тестові класи та тестові набори (пакети).

Відповідальність:

• Створює тестові класи, збирає тестові пакети та інтегрує їх у тестову модель

Активності тестування за RUP

Ролі для тестувальників — це ті робочі позиції, які посідають люди в ієрархії тестування програмного забезпечення. На практиці, коли ви прийдете на роботу вперше, логічно, що все почнеться з посади тестувальника. І якщо ви будете один у своїй компанії, ця схема вам взагалі не знадобиться. Але для роботи у великій компанії необхідно грамотно взаємодіяти з усіма ролями в тестуванні, розуміти, на кому яка відповідальність лежить і хто за який аспект роботи відповідає.

Активності процесу тестування ПЗ
  • Планування тестів Визначення вимог до тестів Оцінка ризиків Розробка стратегії тестування Визначення ресурсів Створення розкладу/послідовностей Розробка Плану тестування
  • Дизайн тестів (Design Test) Аналіз обсягу робіт Визначення та опис тест-кейсів Визначення та структурування тестових процедур Огляд та оцінка тестового покриття
  • Розробка тестів (Implement Test) Запис або програмування тестових скриптів Визначення тестокритичної функціональності в Дизайні та Моделі реалізації Створення/підготовка зовнішніх наборів даних
  • Виконання тестів (Execute Test) Виконання тестових процедур Оцінка виконання тестів Відновлення після збійних тестів Перевірка результатів Дослідження неочікуваних результатів Опис виявлених дефектів
  • Оцінка тестів (Evaluate Test) Оцінка покриття функціональності застосунку або системи тест-кейсами Оцінка покриття коду Аналіз дефектів Визначення критеріїв завершення та успішності тестування (аналіз метрик)
Практичні аспекти тест-дизайну

Нижче перелічено найпоширеніші техніки тест-дизайну:

  • Еквівалентне розбиття (Equivalence Partitioning — EP). Ви розбиваєте всі можливі діапазони значень на коректні та некоректні й вибираєте по одному значенню з кожного діапазону. Наприклад, у вас є діапазон допустимих значень від 1 до 10: ви маєте вибрати одне коректне значення (усередині інтервалу), скажімо, 5, і два некоректні значення поза інтервалом: -3 і 12.
  • Аналіз граничних значень (Boundary Value Analysis — BVA). Якщо взяти наведений вище приклад, то як значення для позитивного тестування виберемо мінімальну й максимальну межі (1 і 10) та значення, більші й менші за межі (0 і 11). Аналіз граничних значень можна застосовувати до полів, записів, файлів або будь-яких сутностей, що мають обмеження.
  • Причина / Наслідок (Cause/Effect — CE). Це, як правило, введення комбінацій умов (причин) для отримання відповіді від системи (наслідок). Наприклад, ви перевіряєте можливість додати клієнта за допомогою певної екранної форми. Для цього вам необхідно буде ввести кілька полів, таких як "Ім'я", "Адреса", "Номер телефону", а потім натиснути кнопку "Додати" — це "Причина". Після натискання кнопки "Додати" система додає клієнта до бази даних і показує його номер на екрані — це "Наслідок".
  • Передбачення помилок (Error Guessing — EG). Це коли тест-аналітик використовує свої знання системи та здатність інтерпретувати специфікацію, щоб "передбачити", за яких вхідних умов система може видати помилку. Наприклад, специфікація каже: "Користувач повинен ввести код". Тест-аналітик думатиме: "А що, якщо я не введу код?", "А що, якщо я введу неправильний код?" і так далі. Це і є передбачення помилок.
  • Вичерпне тестування (Exhaustive Testing — ET) — це крайній випадок. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і, в принципі, це має знайти всі проблеми. На практиці застосування цього методу неможливе через величезну кількість вхідних значень.

Практика

Просто не терпиться застосувати надважливі знання на практиці. Давайте розберемо класичний приклад контактної форми, застосувавши до нього техніки тест-дизайну.

Увага, завдання:

Протестувати функціональність форми приймання заявок. Посилання на форму.

Отже, з чого починається тестування? Запитання аж ніяк не риторичне. Тестування починається з вимог.

Розкрию вам секрет вимог: вимоги не завжди подано у явному вигляді, більше того, їх може взагалі не бути або вони можуть бути описані в усній формі. Тому досвідчений тестувальник повинен уміти самостійно сформувати вимоги до ПЗ, виходячи з опису, ТЗ, мокапів, обговорення продукту на нараді та здорового глузду.

Розглянемо вимоги до тестування цієї форми. Для зручності їх подано в наступній таблиці:

Елемент

Тип елемента

Вимоги

Тип звернення

combobox

Набір даних:

  1. Консультація
  2. Проведення тестування
  3. Розміщення реклами
  4. Помилка на сайті

* - на процес виконання операції приймання заявок не впливає.

Контактна особа

editbox

1. Обов'язкове для заповнення

2. Максимум 25 символів

3. Використання цифр і спецсимволів не допускається

Контактний телефон

editbox

  1. Обов'язкове для заповнення
  2. Допустимі символи: "+" і цифри
  3. "+" можна використовувати лише на початку номера
  4. Допустимі формати: починається з плюса — 11-15 цифр
    +31612361264
    +375291438884
    без плюса — 5-10 цифр, наприклад:

0613261264
2925167

Повідомлення

text area

1. Обов'язкове для заповнення

2. Максимальна довжина 1024 символи

Відправити

button

Стан:

1. За замовчуванням — неактивна (Disabled)

2. Після заповнення обов'язкових полів стає активною (Enabled)

Дії після натискання

1. Якщо введені дані коректні — відправлення повідомлення

2. Якщо введені дані НЕ коректні — валідаційне повідомлення

Визначення набору тестових даних
  • Відштовхуючись від вимог до полів і використовуючи техніки тест-дизайну, починаємо визначення набору тестових даних: залежно від того, обов'язкове поле чи ні, визначимо, які поля необхідно перевірити на порожнє значення, оскільки воно може викликати помилку (У результуючій таблиці позначено [1])
  • Оскільки вичерпне тестування неможливе через величезну кількість усіляких комбінацій значень, насамперед необхідно визначити мінімальний набір даних. Це можна зробити, використовуючи такі техніки, як Еквівалентне розбиття та Аналіз граничних значень. Позначимо як [2].
  • На формі є поле складеного типу (цифри використовуються разом із символами), яке має спеціальний формат даних, і тому добір тестових даних для нього — досить трудомістке завдання. У межах цієї статті обмежимося лише простою перевіркою форматів і основних вимог, описаних у формі приймання заявок.
  • Після завершення генерації даних за стандартними техніками можна додати певну кількість значень на основі особистого досвіду (техніка Передбачення помилок) — це використання спецсимволів, дуже довгих рядків, різних форматів даних, регістрів у рядках (Upper, Lower, Mixed cases), від'ємних і нульових значень, кейвордів Null - NaN - Infinity тощо. Сюди можна включити все, що, на вашу думку, може вивести застосунок з ладу (У результуючій таблиці [2])
Результат застосування тест-дизайну

запасне посилання, якщо таблиця не працює

На підставі техніки Причина-Наслідок та, за можливості, наявних варіантів використання (Use case) створимо шаблон запланованого тесту. Цей документ міститиме кроки й очікувані результати тесту, але без конкретних даних, які підставляються на наступному етапі розробки тест-кейсів.

Дії

Очікуваний результат

1. Відкриваємо форму надсилання повідомлення

  • Форму відкрито
  • Усі поля за замовчуванням порожні
  • Обов'язкові поля позначено *
  • Кнопка "Відправити" неактивна

2. Заповнюємо поля форми:

  • Тип звернення
  • Контактна особа
  • Контактний телефон
  • Повідомлення
  • Поля заповнено
  • Кнопка "Відправити" — активна (Enabled)

3. Натискаємо кнопку "Відправити"

  • Якщо введені дані коректні: Повідомлення "Заявку відправлено" виведено на екран. Нова заявка з'явилася в списку на сторінці "Заявки".
  • Якщо введені дані НЕкоректні: Валідаційне повідомлення з усіма помилками виведено на екран. Заявка НЕ з'явилася в списку на сторінці "Заявки".