Вітаю учасників поважної спільноти.
Я працюю тестувальником (інтернет-магазин). Вектор - управління тест-кейсами, 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.
Можна посадити колегу або новенького на місце тестувальника і дати йому такий план для ознайомлення зі структурою сайту і процесом тестування. Мій спосіб ні в якому разі не замінює системи управління тест-кейсами, а всього лише додає її.
Всі дані публікації, що стосуються опису структури плану, є загальними для більшості сайтів інтернет-магазинів, тому не несуть якоїсь комерційної таємниці.
Всім спасибі за увагу!