Привіт! Сьогодні ми розберемо функціональні типи тестування, або ж їх ще називають рівнями тестування. Це важлива тема, її питають на співбесідах, тому беріть ручку, блокнот і конспектуйте.
Почнемо із розбору невеликої картиночки, а потім перейдемо до деталей. Ми бачимо тут мінімум 4 назви зі словом testing. Unit testing, integration testing, system testing та acceptance testing.
Це є рівні тестування. І на цій картиночці... Більш-менш зрозуміло показано, як воно працює. Юніт-тестинг це один маленький квадратик, з чим ми можемо порівняти цей квадратик з одним компонентом програми, тобто один мінімальний якийсь кусок, модуль, юніт програми.
І ми щось робимо, і в нас виходить якийсь результат із цього куска програми. Тепер інтеграційне тестування. Бачите, тут вже три таких самих квадратика і є певні стрілочки. Інтеграційне тестування, воно перевіряє взаємодію. оцих юнітів із юніт тестування.
Тобто цей самий квадратик використовується в інтеграційному тестуванні, але цього разу ми перевіряємо взаємодію між цими квадратиками, між кусочками системи, між маленькими функціоналами. Далі ідея систем тестінг тестування системи в цілому. В системному тестуванні ми перевіряємо всю-всю-всю програму з всіма квадратиками і з шляхами, тобто з трілочками, які їх з'єднують, тобто ми перевіряємо просто програму.
І далі йде acceptance testing. Тут вже немає системи в цілому, тут є тестувальниця, яка слизь за комп'ютером і перевіряє програму на відповідність вимогам. До речі, acceptance testing ми з вами проходили в темі вимог. Є acceptance criteria, яка показує собою найголовніший документ по вимогах.
І є acceptance testing, де ми просто тестуємо програму на відповідність acceptance criteria, тобто цьому документу. Тепер перейдемо до деталей. Юніт-тестування, модульне тестування або компонентне тестування. Ці три слова являються синонімом. Це маленькі тести, які тестують найменшу одиницю функціоналу.
Якщо брати, до прикладу, калькулятор, то вони тестують, наприклад, додавання або віднімання, тобто якусь одну дію. Одна дія додавання, і ми знаємо, що якщо до першого числа додати друге, то має вийти сума. Відповідно, юніт-тест буде, якщо 2 плюс 2 дорівнює 4, то тест...
якщо 2 плюс 2 не дорівнює 5, то тест також пройшов. Ці тести пишуть програмісти для того, щоб перевірити свою роботу. І, як каже сертифікація iCQB, вони роблять це для того, щоб не втрачати відчуття quality, відчуття якості.
Тому що, якщо вони просто будуть програмувати, а тестувати будемо тільки ми, то програмісти втратять будь-які відчуття якості і будуть писати неякісний код. Тому вони покривають свій код юніт-тестами, І є правило, що цих юніт-тестів має бути дуже багато. Про це ми поговоримо в наступних уроках.
Поки що переходимо до інтеграційного тестування. Поки що ми не читаємо інтеграційне тестування теорію, ми дивимося на картиночку з краником і раковиною. Бачите, в нас є кран, в нас є раковина, вони класні, вони протестовані, але щось не так. Вони погано взаємодіють. Вода л'ється, але вона л'ється не в раковину, а на раковину, і тим самим вона мочить.
Все навколо. Тут було проведено два класних юніт-теста, але жодного інтеграційного тесту, тобто жодного теста взаємодії між краном та раковиною. Інтеграційне тестування також проводять програмісти, тому все, що нам потрібно про нього знати, це те, що це перевірка взаємодії двох або більше модулів.
Рухаємося далі, переходимо до системного тестування. Його проводять тестувальники. Системне тестування спрямоване на перевірку всього додатку, всієї програми, всього веб-сайту, як єдиного цілого, зібраного з частин, перевірених на двох попередніх стадіях, на модульному та інтеграційному тестуваннях. Тут не тільки виявляються дефекти на стиках компонентів, як в інтегрейшн-тестуванні, але й виявляється можливість повноцінно взаємодіяти з додатком з поля до кінцевого користувача, тобто нашого клієнта, при цьому застосовуючи безліч інших видів тестування перерахованих у цьому розділі.
І тут, пом, ви думали, що все легко? Ага. До систем тестування можна віднести всі інші види тестування.
Майже всі, але дуже багато із них. Security тестування, usability тестування, installation тестування, functional, recovery, interoperability і так далі. Всі ці типи тестування можна віднести до системного.
Це факт вам для того, щоб ви розуміли, що ми не можемо взяти тест і сказати, що це тест. Це тільки один тип тестування. Тільки, наприклад, систем. Ні, один тест може складатися із дуже багатьох видів тестування і відноситися до багатьох видів тестування.
Тепер Acceptance тестування. Його можуть перекладати на приймальне, прийомки і так далі, але краще не перекладати, краще залишати назви англійською і вивчати їх англійською. Acceptance тестування проводять тестувальники.
Ми вже знаємо, що це тести, які перевіряються на відповідність Acceptance критерія. І якщо Acceptance тестування не пройшло, то ми не можемо релізати програму, тому що ми маємо виправити всі баги і зробити так, щоб програма повністю відповідала вимогам. і тільки тоді продовжувати тестування. Далі йдуть три дуже цікавих типи тестування, тому що багато з вас їх вже знають. Це альфа-тестинг, бета-тестинг та гамма-тестинг.
Поки ми не будемо читати текст, згадайте, будь ласка, чи чули ви колись фразу «Я бета-тестувальник». Бета-тестувальники це ті люди, які тестують програму, хоча вони не являються тестувальниками, вони прості користувачі. Це як суд присяжних.
Присяжні це люди, які працюють на своїх роботах, лікарі, вчителі, програмісти, але вони являються присяжними. Тобто і в бета-тестуванні люди являються тестувальниками, але це не їх основна професія. Отже, альфа, бета та гама тестування, вони виконуються, коли продукт вже готовий. І нам потрібно, щоб кінцеві користувачі протестували цей продукт. Альфа-тестування виконується всередині організації, тобто виконує команда, яка працювала над...
цим продуктом, або програмою, або грою, або веб-сайтом. І також можливе часткове залучення клієнтів, кінцевих користувачів. Альфа-тестування може бути формою приймального тестування, тобто може бути як частина акцептност-тестування.
В деяких джерелах зазначається, що це тестування має проводитися без залучення команди розробників. Інші джерела не висувають такої вимоги. Чому повинно проводитися без залучення команди розробників?
Тому що у розробників є така штука, вони написали цей код, і для них їхня дитина найкраща. Це психологія тестування і психологія розробників. І, відповідно, розробники ніколи не будуть шукати недоліки в своїй роботі. Вони будуть сидіти, дивитись на неї, думати, боже, яка вона класна. Для цього потрібні тестувальники, і для цього в альфа-тестування іноді не залучають розробників.
Суть цього виду в тому, що продукт уже можна періодично показувати клієнтам, Але він ще досить сирий, тому основне тестування ще виконується організацією, яка розробляє продукт. Переходимо до бета-тестування. Воно виконується поза організацією і з активним залученням кінцевих користувачів або замовників. Я думаю, багато із вас, хто грає в ігри, знають, що таке бета-тестування, що ігри виходять в бету, це означає, що будь-яка людина, яка може отримати ключ, написати там розробникам, сказати, я хочу бути бета-тестувальником, починає грати в цю ігру перша.
Для таких людей це класно, тому що вони перші поринають в світ цієї гри, перші дізнаються, яка там історія у гри, які персонажі і що вони роблять. А для організації, яка написала програму, плюс в тому, що кінцевий користувач тестує цю програму з своєї точки зору, не професійної, але конкретно так, як він буде використовувати дану гру або дану програму. І це може допомогти знайти якісь додаткові баги. Коротко, суть цього виду тестування продукт вже можна відкрито показувати зовнішнім користувачам, він вже досить стабільний, але проблеми все ще можуть бути, і для їх виявлення потрібен зворотній зв'язок від реальних користувачів. І гамма-тестування це фінальна стадія тестування перед випуском продукту, і вона спрямована на виправлення незначних дефектів, виявлених у бета-тестуванні.
Як правило, гамма-тестування також виконують з залученням кінцевих користувачів, тобто клієнти програми. може бути формою зовнішнього приймального тестування, тобто acceptance тестування, яке проводять клієнти. Суть цього виду в тому, що продукт вже майже готовий, і зараз зворотній зв'язок від реальних користувачів використовується для усунення останніх недоробок. Так виглядає повна картина оцих рівнів тестування. Значить, спочатку в самому низу у нас є дуже багато юніт-тестихів.
Юніт-тестів має бути прям супер багато. Юніт-тести об'єднуються в інтегрейшн, тобто перевірку взаємодії двох або більше модулів. Потім багато інтегрейшн-тестів, вони об'єднуються в системні тести, де тестується система в цілому. Після системного тестування йде аксептенс-тестування, яке можуть перекладати як приймальне тестування, тобто тестування на відповідність аксептенс-критерії. Після того, коли аксептенс-тестування пройшло, всередині команди проводять альфа-тестування, тобто першу версію такого кінцевого тестування, на якому шукають недоліки.
Після того, як всі ці недоліки виправлені, залучають кінцевих користувачів. які з задоволенням проводять бета-тестування, відкривають баги і відчувають себе справжніми тестувальниками. І після того ще є гама, якої немає на цій картинці, в якій виправляють баги із бета і перевіряють, щоб не знайшли нових багів.
Порівняно тестування це все. Я дякую вам за увагу та за перегляд. Також буду вдячна за запитання в коментарях, лайки та підписки. До зустрічі в наступному відео. Буде цікаво.