Як тестувати те, що бачиш перший раз у житті. П’ять підходів

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Всім привіт, мене звуть Михайло, я працюю у продуктовій компанії RocketHash тестувальником. Хочу поділитися п’ятьма підходами до тестування того, що бачиш вперше у житті. Ці підходи допоможуть тестувальникам-початківцям уникнути страху перед незрозумілим і новим функціоналом, а також стануть у пригоді для підготовки до співбесід.

Моя трудова кар’єра склалася так, що більшу частину часу я працював в аутсорсингових компаніях. Специфіка роботи полягала в тому, що проєкти, які потрібно було тестувати, постійно змінювалися.

На одному тижні могло бути кілька дуже різнопланових проєктів: як вебзастосунків, так і мобільних, від ігор до онлайн-магазинів та систем управління персоналом. Одного разу навіть довелося тестувати — ви все одно не повірите — шоколадні цукерки.

Така вервечка проєктів з одного боку не давала дуже глибоко поринути у контекст кожного конкретного застосунку, але водночас дозволила виробити деякі особливі підходи до тестування чогось нового і невідомого.

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

Для статті я зібрав п’ять підходів, які будуть йти послідовно: від найпростіших до складніших. Список не вичерпний та не заперечує й інші підходи до тестування.

1. Тисни на всі кнопки

Найпростішим підходом до тестування чогось невідомого є Ad-Hoc, який ще називають інтуїтивним тестуванням. Про нього знають усі, хто хоч трохи практикував тестування, але про всяк випадок я поясню суть цього підходу простими словами.

Це тестування, до якого заздалегідь не готувалися, не збирали вимоги, не писали жодних планів. Насправді воно полягає в тому, щоб натиснути на все, що можна натиснути, перевірити переходи, екрани, форми. Загалом повзаємодіяти з усіма частинами проєкту, до яких зможете дотягнутися і подивитися, що станеться.

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

Для проведення такого типу тестування не потрібні особливі знання і його можуть робити будь-які члени команди розробки. Власне, так з проєктом будуть знайомиться його майбутні користувачі.

2. Йдемо у розвідку

Наступним за рівнем складності йде «дослідницьке тестування», його іноді також називають «розвідувальним» тестуванням (звучить кумедно). Воно схоже на Ad-Hoc, але має важливу відмінність.

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

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

3. Діємо за сценарієм

Наступним підходом за рівнем складності можна вказати тестування за сценаріями. Тестувальник передбачає, за якими сценаріями користувач може користуватися системою.

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

Головна вада цього підходу полягає в тому, що у користувачів може виявитися такий сценарій використання вашого проєкту, про який ви не здогадуєтеся. Але як початковий план для тестування, цей підхід цілком підійде.

4. Орієнтуємось на вектори

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

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

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

Переконавшись, що нова функціональність працює, ми проводимо тестування «назад» — проводимо регресію для підтвердження працездатності старого функціоналу.

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

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

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

5. Вимоги — понад усе

Найінтелектуальнішим, принаймні з цього списку, є «тестування на основі вимог». Як випливає з назви, первинним для цього підходу є набір вимог для проєкту чи системи.

Звідки можна отримати інформацію про вимоги? Зі спеку, з макета, зі стандартів, з попередніх реалізацій подібного функціоналу, кращих практик, та й зі здорового глузду, так)

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

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

На кожну таку вимогу складаються тест-кейси з позитивними та негативними сценаріями. Так, поступово, вся функціональність виявляється покрита тестами. Згодом вони можуть змінюватись і додаватись у міру накопичення досвіду в тестуванні та експлуатації системи.

Така система тест-кейсів дозволяє з вакууму невизначеності вибудувати зрозумілий і відчутний план тестування.

***

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

Якщо вам всі ці підходи були і так відомі, то ви, по-перше, молодець, а по-друге, не валите сильно на співбесіді)

Можливо, у вас є підходи до тестування чогось невідомого? Напишіть у коментарях, гадаю, що всім буде корисно дізнатися.