Позитивне та негативне тестування: основи та нюанси

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

Всім привіт, мене звуть Влад Голівер. Я Senior AQA в ІТ-компанії Customertimes. У тестуванні я працюю вже понад 6 років і сьогодні хотів би обговорити з вами одну з базових тем у тестуванні, але не менш важливу ніж інші, — поняття позитивних та негативних тестів.

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

Початок розмови про тестування

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

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

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

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

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

У цій статті ми будемо розмірковувати про порядок виконання тестів і їх групування на основі типів тестів, а саме «Позитивні» і «Негативні» тести.

Позитивні і негативні тести — про що це

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

У позитивних тестах користувач вводить правильні дані та взаємодіє з системою належним чином. Розглянемо це на практиці.

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

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

Розгляньмо тепер визначення другого типу тестів. Негативний тест — це тест, в якому система правильно реагує на некоректні запити користувача.

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

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

Отже, система повинна правильно реагувати, коли користувач починає виконувати дивні та неправильні дії з її функціоналом.

Окремі типи негативних тестів

Перший тип таких негативних тестів ми формуємо на основі технік тест-дизайну та наявності проєктної документації.

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

До таких перевірок нескладно дійти своїм розумом або, щоб не забути всі комбінації цього типу перевірок, можна використовувати такі техніки тест-дизайну, як граничні значення (Boundary values analysis), еквівалентні класи (equivalence partitioning), таблиця рішень (decision table) та інші.

Другий тип негативних тестів формується на основі техніки тест-дизайну «Error Guessing». Але, на жаль, в цій техніці тест-дизайну немає жодних правил і методик. Тестувальник тут користується своїм логічним мисленням і уявою.

Через цей момент рівень мануальних тестувальників часто відрізняється, оскільки в одному і тому ж функціоналі початківець може знайти одну помилку, а Senior QA — 10 помилок. Хоча іноді ситуація може бути повністю зворотною. Іншими словами, у рамках цієї техніки тест-дизайну тестувальник повинен придумати нестандартний спосіб, щоб спровокувати помилку.

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

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

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

Ще кілька прикладів негативних тестів рамках функціоналу логіну в особистий кабінет звичайного інтернет магазину:

• Спроба увійти під користувачем, профіль якого був раніше видалений.
• Використання старого пароля після того, як ми змінили його на новий.
• Введення неправильного логіна і/ або пароля (відсутність одного символу або неправильне використання верхнього/ нижнього регістру).
• Та інші. Негативне тестування обмежується лише вашою уявою та наявністю часу.

Варто знати

А зараз розглянемо окремі аспекти та неписані правила, які варто враховувати, щоб вдало поєднувати позитивні і негативні тести в роботі:

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

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

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

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

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

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

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

Таким чином, виникають ситуації, коли середовище постійно змінюється різними тестувальниками, що може призвести до ’False positive’ тестів (тест-кейс, який помилково не виявить баг, який насправді існує) або ’False negative’ тестів (тест-кейс, який не повинен був виявити баг, оскільки насправді функціональність працює правильно).

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

7) Наявність позитивних тестів не скасовує і не зменшує важливість негативних тестів. Ці два типи тестів лише доповнюють один одного. Кількість позитивних і/або негативних тестів залежить від наступного:

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

В кінці статті зазвичай звучать глибокі думки, але я обмежуся фразами, які були освітлені в цій статті, але краще проговорити їх ще раз, оскільки часто їх хочуть почути на співбесідах від майбутніх тестувальників:

«Позитивні тести виконуються у першу чергу, негативні тести — одразу після них».

«Позитивні та негативні тести не замінюють один одного, а доповнюють».

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