За план тестування замовте слово

Вітаю учасників поважного співтовариства.

Я працюю тестувальником (web-сервіс). Вектор — управління тест-кейсами, QA — менеджмент, JUnit — тестування, автоматизація, програмування на Java. Мені хотілося б поділитися з колегами своїм досвідом. Може, комусь стане в нагоді.

Предмет статті — план тестування і інструментарій для його складання.

Отже, є завдання — протестувати роботу мобільної версії сайту на фронті. Є власне бажання — залишити нащадкам і колегам осудний мануал по тестуванню, коли не треба буде придумувати, що б таке потестить. Я за взаємозамінність, універсальність, наочність! Постулат — структура сайту повинна бути представлена у вигляді дерева для полегшення сприйняття і отримання перспективи.

Покроковий процес побудови дерева для плану тестування:

1. Перший рівень: вказівка розділу «Сторінки» та глобальні елементи (наскрізні елементи — елементи шапки, підвал).
2. Другий рівень: перерахування сторінок.
3. Третій рівень: перерахування загальних властивостей сторінки і її особливих станів (наприклад, повна або порожня кошик).
4. Четвертий рівень:
— вказівка розділу «Елементи»,
— вказівка розділу «Події» для сторінки,
— перерахування великих блоків елементів (наприклад, блок товарних підкатегорій з великою кількістю елементів),
5. П'ятий рівень: перерахування типів елементів (текстові блоки, посилання, поля, кнопки, чекбокси, лічильники, форми, фото, банери, іконки, значки, капча...).
6. Шостий рівень: перерахування назв елементів, що відносяться до відповідного типу елемента (наприклад, назв полів для типу елемента «Поле»).
7. Сьомий рівень: вказівка на предмет тестування з конкретного елементу і на розділ «Дії» / «Події» для опису функціонального тестування:
7.1. Текстовий блок (конкретний):
— вірне розташування на сторінці,
— коректний формат тексту,
— коректне відображення верстки,
— елемент не можна змінити,

7.2. Посилання:
— вірне розташування,
— можливість натиснути,
— наявність потрібного тексту,
— натискання не викликає помилку,
— посилання веде на потрібну сторінку,
— елемент не можна змінити,

7.3. Поля:
7.3.1. Вірне розташування,
7.3.2. Коректний формат,
7.3.3. Елемент не можна змінити,
7.3.4. Дії (набір залежить від типів даних, які містяться в даному полі — наприклад, числа, — і функціоналу елемента — наприклад, поле для вводу):
7.3.4.1. Приймає вірне значення.
7.3.4.2. Приймає хибне значення.
7.3.4.3. Не приймає текст.
7.3.4.4. Не приймає спецсимволи.
7.3.4.5. Не приймає ін'єкції.
7.3.4.6. Не приймає / інтерпретує число в іншій системі числення.
7.3.4.7. Не приймає формули та операції ділення на 0.
7.3.4.8. Не приймає / інтерпретує в ціле дробове число,

7.4. Кнопки:
7.4.1. Вірне розташування,
7.4.2. Можливість натиснути,
7.4.3. Наявність потрібного тексту,
7.4.4. Елемент не можна змінити,
7.4.5. Дії:
7.4.5.1. Викликає необхідну форму / запускає певний процес.
7.4.5.2. Натискання не призводить до виникнення явної помилки поточної сторінки або в результатах процесу.
7.4.5.3. Натискання не призводить до переміщення на іншу сторінку.
7.4.5.4. Натискання не призводить до зависання,

7.5. Чекбокси / прапори:
7.5.1. Вірне розташування,
7.5.2. Можливість виділити / зняти виділення,
7.5.3. Елемент не можна змінити,
7.5.4. Дії:
7.5.4.1. Виділення не призводить до виникнення помилки на поточній сторінці.
7.5.4.2. Виділення не призводить до запуску стороннього процесу.
7.5.4.3. Виділення не призводить до зависання,

7.6. Лічильники:
— вірне розташування,
— відображення цілого числа (кількості одиниць товару),
— коректний формат відображення,
— елемент не можна змінити,
— відповідність числового значення лічильника вихідною величиною,

7.7. Форми:
7.7.1. Вірне розташування,
7.7.2. Коректний формат відображення,
7.7.3. Елемент не можна змінити,
7.7.4. Елементи:
7.7.4.1. Поля
7.7.4.2. Кнопки
7.7.4.3. Посилання

7.7.5. Події:
7.7.5.1. Очищення полів форми після відправки даних.
7.7.5.2. Очищення полів форми після оновлення сторінки.

7.8. Фото (з механізмом перегляду збільшеної фотографії):
7.8.1. Вірне розташування,
7.8.2. Коректне відображення,
7.8.3. Можливість натиснути,
7.8.4. Елемент не можна змінити,
7.8.5. Події:
7.8.5.1. Натискання приводить до появи збільшеної фотографії,
7.8.5.2. Натискання не призводить до будь-яких помилку,


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

Що дасть мені зручне представлення плану тестування?
— перспективу (майбутній обсяг робіт);
— розуміння структури досліджуваного об'єкта (і не обов'язково сайту — навіть ракети);
— розуміння ступеня покриття тест-кейсами об'єкта тестування;
— уявлення про те, тестування чого я можу автоматизувати;
— зрештою, +1 до ЧСВ (жарт).

Як відомо, навіть хорошому пілотові потрібен літак з крилами.

Мій літак з крилами — це XMind 6.

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



Так, у мене вже є деяке уявлення про обсяги тестування. Його буде багато…
Перше, з чого я почав, вказівка розділу «Сторінки» та глобальні елементи (наскрізні елементи — елементи шапки, підвал):

image

Далі — перерахування сторінок:



Далі (див. Третій рівень — вище) — перерахування загальних властивостей сторінки і її особливих станів (наприклад, повна або порожня кошик):



Далі (див. Четвертий рівень) — перерахування загальних властивостей сторінки, подій для неї:



Далі — перерахування типів елементів (текстові блоки, посилання, поля...):



Далі — перелік назв елементів, що відносяться до відповідного типу елемента:



І останній основний рівень — сьомий: вказівка на предмет тестування з конкретного елементу і на розділ «Дії» / «Події» для опису функціонального тестування:



Такий елемент як форма вимагає додаткових рівнів вкладення, оскільки містить в собі прості елементи — поля, кнопки і т. д.

І так для кожної сторінки. Так, потрібен час на складання. А як же ще? Зате тепер я маю на руках карту, яку зможу проектувати на мобільну версію у разі її поновлення — трохи подкорректирую. А що мені дасть зручне представлення плану тестування — прошу прочитати вище.

Зелений прапор — тест пройшов, червоний — баг. Якщо хоча б один тест завалений, червоний прапор проставляється у всіх батьків — щоб можна було з самого відкриття плану зрозуміти: є проблеми.

Всі зміни по файлу програми можна враховувати за допомогою Git'а.

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

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

Всім дякую за увагу!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.