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

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

Вітаю учасників поважної спільноти.


Я працюю тестувальником (інтернет-магазин). Вектор - управління тест-кейсами, 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.

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

Так, у мене вже є деяке уявлення про обсяги тестування. Його буде багато...

Перше, з чого я почав, вказування розділу «Сторінки» і глобальні елементи (наскрізні елементи - елементи шапки, підвал):

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

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

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

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

Далі - перерахування назв елементів, що належать до відповідного типу елемента:

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

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

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

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

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

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

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

Всім спасибі за увагу!

Image