Основні підходи до ефективного тестування ПЗ

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

Усім привіт! Мене звати Вероніка, я General QA Engineer, маю понад чотири роки досвіду роботи. Свою кар’єру в ІТ я розпочала ще навчаючись в університеті, з позиції AQA. Згодом окрім автоматизації, я почала займатись і мануальним тестуванням. Я переконана, що успішне тестування вимагає від нас усвідомлення та дотримання певних принципів.

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

Що таке принципи тестування

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

Принцип 1. Тестування показує наявність дефектів, а не їх відсутність

Що нам каже посібник Foundations of Software Testing: ISTQB Certification:

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

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

Один з випадків, з мого досвіду роботи:

Після випуску нової версії мобільного застосунку виявляється, що нова фіча не працює на конкретній версії Android (Android 7.0 — буду пам’ятати тебе завжди). Під час тестування дефектів виявлено не було, оскільки для тестування використовувались інші версії Android, більш популярні.

Цей дефект підтверджує принцип, що якщо проблему не було виявлено, це не є доказом того що її немає.

Принцип 2. Вичерпне тестування неможливе

Знову звертаємось до посібника Foundations of Software Testing:

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

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

Розглянемо приклад:

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

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

Принцип 3. Раннє тестування економить час і гроші

З посібника Foundations of Software Testing: ISTQB Certification:

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

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

Раннє тестування також економить час. Наприклад Unit testing або Integration testing можуть швидко виявити недоліки, які можуть спричинити значні затримки розробки, якщо їх виявити пізніше під час тестування системи.

Такі історії, мабуть, траплялись у всіх, я не виняток:

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

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

Цієї проблеми можна було б уникнути, розпочавши роботу над тестуванням на етапі, коли формування вимог.

Принцип 4. Скупчення дефектів

З Foundations of Software Testing: ISTQB Certification:

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

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

Цей принцип 80:20 також називається принципом Парето — 80% дефектів пов’язані з 20% коду. Хоча багато хто вважає, що він базується на спостереженні, що 80% користувачів використовують 20% програмного забезпечення. Саме ці 20% програмного забезпечення найбільше будуть містити дефектів.

У моїй практиці найчастіше були проблеми з онлайн-оплатою (як просто картою, так і Apple Pay/Google Pay), аутентифікацією користувача та логуванням дій користувача.

Головна задача — визначити найбільш проблемні місця у ПЗ або системі, і далі приділяти більше часу їхньому тестуванню.

Принцип 5. Парадокс пестициду

Звертаємось до нашого посібника Foundations of Software Testing: ISTQB Certification:

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

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

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

Наприклад, маємо логін-форму, де у поле «Пароль» користувачі можуть вводити свої паролі без врахування верхнього або нижнього регістру, тобто «Password» = «password».

Маємо тест-кейс:

Передумови:

Відкрита сторінка входу до системи.

Існують дійсні облікові дані для входу (логін та пароль).

Кроки:

  1. Ввести коректний логін у поле «Логін».
  2. Ввести коректний пароль у поле «Пароль».
  3. Натиснути «Увійти».

Очікуваний результат: Користувач успішно авторизується і переходить на головну сторінку системи.

Для тесту завжди використовуємо логін — test@user.com та пароль — password.

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

Принцип 6. Тестування залежить від контексту

З посібника Foundations of Software Testing:

Тестування проводиться по-різному в різних контекстах. Наприклад, критичні для безпеки ПЗ будуть тестуватися інакше, ніж ecommerce-сайт.

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

Тестувальники повинні мати це на увазі. Є велика різниця, що тестувати, ПЗ для медичних цілей чи інтернет-магазин.

Для прикладу розглянемо наступні ситуації:


  1. Маємо дві компанії, які продають товари або послуги. Перша — з дорогими товарами/послугами, наприклад, середній чек складає 5000 грн, а у другої 500 грн — у десять разів дешевше. Чи є сенс для обох компаній мати однакові процеси контролю якості? Найімовірніше, ні. Перша компанія стягує плату за якість і, отже, матиме більш жорсткі стандарти та контроль якості.
  2. Маємо два сайти: на один заходить велика кількість користувачів одночасно, а іншим завжди користується мала кількість. Для сайту із великою кількістю юзерів, обов’язково має бути load testing, щоб показати можливості роботи в умовах великого навантаження. А для сайту, де, як ми знаємо, не буває великого навантаження, такий тип тестування застосовувати не має сенсу.

Принцип 7. Відсутність помилок оманлива

З посібника:

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

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

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

Приклад з особистого досвіду

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

Проте, після випуску оновлення, який використовувався робітниками на заводі, одразу почали надходити скарги. Користувачам не сподобались кнопки на екранах, бо їм було важко на них натискати, як було зазначено у листі-скарзі, через fat fingers.

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

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

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую! Гарна стаття. І наче все знаєш про ці принципи, але викладено просто й зрозуміло. Дякую за приклади! Поділюся із друзями, що тільки навчаються.
І про Android 7.0🫠Працюю в компанії з виходом на американський ринок. Виявилося, що у 20% відсотків користувачів ще й досі 7 версія. І після оновлення додатку він просто перестав працювати на цих девайсах. То був біль))

Тут навіть не тільки версія системи грає роль, як і виробник пристрою.
Дуже часто зустрічаю в коді умову  if (isSamsung) { // just die } 

Підписатись на коментарі