Привіт! Велкам на курс тестування програмного забезпечення української. З вами Попелюха. І сьогодні ми говоримо про підходи тестування. Підходи тестування це така тема, як вступ в типи тестування.
Дуже багато хто в Америці називає їх типами. І вони будуть сьогодні надзвичайно прості. Тому почнемо. Отже, перша класифікація тестування, найелементарніша це позитивне тестування та негативне.
В позитивному тестуванні ми вводимо правильні дані та очікуємо на хороший результат. Наприклад, коли ми реєструємося, ми вводимо ім'я, емейл, пароль, всі правильні, і очікуємо, що коли ми натиснемо «Ок» то нас зареєструє. Негативне тестування це коли ми вводимо невірні дані та очікуємо, що отримуємо повідомлення про помилку, тобто ми робимо щось погано і очікуємо поганий результат. Наприклад, при реєстрації ми вводимо валідний емейл, а пароль повинен бути від 6 символів, а ми вводимо з одного символа. Очікуємо, що нам скажуть занадто короткий пароль.
Ми не можемо вас зареєструвати. Перевірка позитивного флоу, тобто позитивних тестів, завжди обов'язкова. Коли вам кажуть «Створіть тест-кейси», то в першу чергу ви обов'язково повинні створити один позитивний тест.
Далі про негативні. Всі негативні випадки протестувати неможливо. Ми знаємо про наш принцип «Вичерпне тестування не осяжне».
Але пара ключових тестів все-таки маст-хев. Тому потрібно скористатися common sense та техніками тест-дизайну, які ми скоро вивчимо, та створити хоча б два негативних тести. І прикладом позитивного емейлу, тобто емейлу, з яким ми можемо нормально зареєструватися, буде отакий попелюха собачка.gmail.com. А прикладом емейлу, з яким реєстрація мусить не пройти, це емейл без собачки.
Рухаємося далі. Тепер поговоримо про проактивні та реактивні підходи тестування. Ми вже трошечки покривали ці два підходи, коли ми вчили різницю між QA та QC. І от прямо зараз воно вам дуже нагадає різницю між QA та QC.
Проактивне тестування починається на ранніх стадіях, ще тоді, коли появляються тільки вимоги. І в проактивному тестуванні ми робимо все, щоб баги не виникали. А в реактивному ми уже ніби реагуємо на існуючі баги, які ми знайшли. І саме це тестування відбувається вже на фазі тестування. Тобто ми знаходимо баг, ми покриваємо баг тест-кейсом, якщо такого тесту не було, відкриваємо баг-репорт, перетестовуємо його і так далі.
Відповідно, проактивне частіше всіх, не завжди, але частіше всього роблять QA Quality Assurance Інженери, а реактивне тестування проводять Quality Control Інженери. І проактивне тестування більш орієнтоване на процес тестувати вимоги, проводити мітинги, робити все, щоб баги не виникли. А реактивне, відповідно… Воно налаштоване на продукт. Тобто ми тестуємо продукт, коли ми вже знайшли баги, ми робимо все, щоб їх виправили і їх більше не було. Переходимо далі.
Тепер ми поговоримо про різницю між мануальним та автоматизованим тестом. Тут прям здоровений слайд, дуже багато є про що говорити. Мануальне тестування проводиться тестувальником вручну. Все, що ми робили дотепер на цьому курсі, все, що ми тестували, проводилося мануально, оскільки у нас з вами є дві ручки. І ми цими двома ручками клікаємо на кнопочки та вводимо текст по клавіатурі.
Автоматизоване тестування. Інженер пише код і програма проводить тестування. Тобто ми вже нічого не клікаємо, ми натискаємо на кнопку Run.
І комп'ютер проводить тестування, і ми дивимося за результатом. І вже обробляємо готовий результат тестів. Я автомейшн інженер за професією, і я, в принципі, завжди провожу автоматизоване тестування.
І зараз я вам хочу показати елементарне демо. Як воно проводиться, щоб ви просто розуміли суть. Отже, в мене є код, ви щойно його бачили.
В ньому написано всього пару строчок кода, і зараз не будемо доколупуватися до якості цього кода, це просто демо. І цей код зараз відкриє мій YouTube-аккаунт. Тепер поговоримо про підхід білого ящику, чорного ящику та сірого ящику. І знову дякую хлопцю Візи з попереднього відео, який малював всі ці класні малюночки.
Вони знову тут. Він дуже класно зобразив різницю між чорним та білим ящиками. Отже, спочатку розповім своїми простими словами. Чорний ящик це коли ми тестуємо програму, не маючи доступу до коди, до бази даних і взагалі до всього, до чого мають доступ програмісти. Ми з вами весь цей час проводили тестування чорного ящику, адже ми не знаємо код всіх тих сайтів, інтернет-магазинів і всього того, для чого ми писали чек-ліст, тест-кейси і відкривали баги.
Тому ми проводили Black Box Testing. Тестування білого ящику це коли ми бачимо все, що знаходиться в нас під капотом. Ми бачимо код, ми маємо доступ до бази даних, які ми можемо селекти звідти запити, ми маємо доступ до API і так далі. І відповідно тут на картинці дуже класно зображено, що вимоги переходять в тести, і в нас не видно, що знаходиться в ящику.
І далі в нас є актуальні результати і очікувані, і ми їх порівнюємо. А в білому ящику в нас є тест-кейси, і є доступ до коду, є доступ до бази даних, і ми бачимо, що знаходиться під цим ящиком. І тоді ми порівнюємо актуальні та очікувані результати. Білий ящик також називають прозорим, тому що під прозорим ящиком також видно всі результати.
І Alice QB. Те джерело інформації, з якого ми весь цей час вчилися, говорить нам, що інших кольорів в нас немає. Але я знаю, що є сірий ящик. Він є не по STQB, але в багатьох теоріях його згадують, тому його згадаю і я. Сірий ящик це комбо чорного та білого.
Тобто щось нам може бути видно, а щось ні. Наприклад, в нас є доступ до бази даних, але ми не маємо доступу до вихідного коду, тому ми не можемо користуватись кодом. І, відповідно, ми можемо тестувати програму.
методами чорного ящику, і також ми можемо залізти в базу даних і подивитися, що ж там є. І останні підходи, про які ми сьогодні поговоримо, це статичне та динамічне тестування, або верифікація та валідація. Статичне тестування це те саме, що верифікація, а динамічне це те саме, що валідація, тому це треба запам'ятати.
Розкажу, в чому між ними різниця. Статичне тестування, воно ж верифікація, це тестування, яке проводиться без виконання програми. Зазвичай тестувальники виконують програми, скажете ви, і тестують також програми, правильно?
Але ні, тестувальники також можуть тестувати документи, тобто щось, для чого не потрібно виконувати програму. Динамічне тестування це тестування з виконанням програми, тобто простими словами тестування програми. Тепер розповім, як це нормально запам'ятати. Згадуємо в нашій голові те, що ми знали про статику та динаміку до того, як ми вчили цей курс. Статичне це щось, що ніколи не змінюється, а динамічне це те, що завжди змінюється.
Правильно? Що ніколи не змінюється? Згадуємо приказку, що написано пером, те не виробиш це пером. Трошки воно російське, але хай буде.
Тобто статичне тестування це все, що може бути написане пером. Все, що може бути написане та надруковане на папері. Що відноситься до таких типів документів?
Це можуть бути вимоги, це можуть бути тест-кейси, чек-лісти, можуть бути баги. У програмістів це може бути код, який вони написали, і вони можуть його, в принципі, надрукувати і не виконувати. Звичайно, що потрібно виконувати, але можна перевіряти код і просто не виконуючи його. Отже, до статичного тестування відноситься статичний аналіз коду та перевірки.
Тобто все, що ми можемо надрукувати, ми перевіряємо за допомогою статичного тестування, воно ж верифікація. А за допомогою динамічного ми просто... тестуємо програму.
Ми включаємо нашу програму або відкриваємо наш сайт, тикаємо кнопочки, вводимо з клавіатури. Це динамічне тестування. Сподіваюсь, ви запам'ятали цю різницю. Її часто питають на інтерв'юхах.
Причому окремим питанням різницю між статичним та динамічним і окремим різницю між верифікацією та валідацією. Тому, будь ласка, запам'ятайте. На цьому все. Я дуже дякую вам за перегляд. Якщо у вас залишились питання, то не соромтеся задавати їх в коментарях.
Дякую за ваші коментарі більше 4 слів, лайки та підписки. Підтримуйте українське та до зустрічі в наступному відео.