Нивата на тестване
Накратко: Тестването не е едно нещо. На ниво компонент се проверява едно правило само, на интеграция дали частите си говорят, на система цялото поведение, а на приемане дали това е, което бизнесът иска. Всяко ниво хваща свои грешки, които другите пропускат.
Проблем
Всичко минава, а парите не стигат
Програмистите на магазина имат 400 теста за доставката и промо кода. Всички минават. Тестерът е минал целия път на поръчката: количка, доставка, плащане. Всичко е наред.
В първия ден след пускането банката превежда 0,50 € за поръчка от 50,00 €. Количката праща сумата в евро, а услугата за плащане я чете в центове. Всяка част е правилна сама. Грешката е между тях, и никой тест не гледа там.
Идеята
Четири нива, четири въпроса
Тестването се прави на няколко нива (test levels). Всяко пита различен въпрос и хваща различни грешки:
| Ниво | Въпросът | В магазина |
|---|---|---|
| Компонент (component) | Вярно ли е едно правило само? | Функцията за доставката при 49,99 €, 50,00 € и 50,01 € |
| Интеграция (integration) | Говорят ли си частите правилно? | Количката и услугата за плащане: евро или центове? |
| Система (system) | Прави ли цялото това, което е описано? | Целият път: количка, промо код, доставка, плащане, имейл |
| Приемане (acceptance) | Това ли иска бизнесът? Може ли да се ползва? | Счетоводството проверява справката за кодовете |
Нивата не са по-добри и по-лоши. Те са различни мрежи с различни дупки.
По-точно, за любопитните
ISTQB CTFL v4.0.1 описва нивата в раздел 2.2.1 и ги дели на пет: компонентно тестване (component testing, наричано и unit testing), тестване на интеграцията на компонентите (component integration), системно тестване (system testing), тестване на интеграцията на системите (system integration: магазинът с куриера, с банката) и приемно тестване (acceptance testing). За всяко ниво програмата казва какво е обектът на теста, целта, базата (от какво се взимат тестовите случаи), типичните дефекти и кой отговаря.
Идеята
Колкото по-ниско, толкова по-точно сочи
Тестът на ниво компонент вика една функция с 50,00 € и вижда 4,90 €. Знаеш точно къде е грешката. Пуска се за милисекунди и няма нужда от база, браузър или банка.
Системният тест вижда същата грешка, но през целия магазин. Падне ли, още не знаеш дали е доставката, промо кодът или страницата. А някои случаи там изобщо не се стигат лесно: за да провериш 49,99 €, трябва да напълниш количка точно за толкова.
Обратното също е вярно. Тестът на компонента не вижда, че количката и банката броят в различни единици. Затова трябват и двете нива.
По-точно, за любопитните
Тестовете на ниво компонент обикновено ги пишат програмистите, често преди кода (TDD). Ако си минал някой от курсовете по програмиране, там ги видя като тестове с JUnit, xUnit, pytest или node:test. Тук не пишем код: в модула за автоматизация ще видиш същите правила като тестове на компонент на четирите езика.
Пробвай
Кое ниво го хваща?
Идеята
Приемането не е едно нещо
Приемното тестване пита „може ли да се ползва“, но „ползва“ значи различно за различни хора. Затова има няколко вида:
- Потребителско (user acceptance testing, UAT): хората, които ще ползват системата, вършат истинската си работа с нея. Счетоводителката прави месечната справка.
- Експлоатационно (operational acceptance testing): тези, които ще поддържат системата в работа, проверяват архива, възстановяването, наблюдението, обновяването.
- По договор и регулации (contractual and regulatory): мерилото е договорът с клиента или законът. Пазят ли се съгласията за бисквитки? Има ли всичко, което договорът изброява?
- Алфа и бета (alpha, beta): хора извън екипа пробват продукта. Алфа е в среда на разработчика, бета е при самите клиенти, на техните телефони и мрежи.
Мерилото на приемането са критериите за приемане на сторитата. Затова ги пишем заедно с бизнеса, преди кода.
Пробвай
Какъв вид приемане?
Идеята
Нивото не е времето, а целта
Лесно е да си представиш нивата като стъпала: първо компонент, после интеграция, накрая приемане. В каскадния модел често е така. Но в Agile екип всичките четири могат да се случат за едно стори в една седмица: програмистът пише тест на компонент, QA пуска сценария на системата, а собственикът на продукта го приема на демото.
Нивото се познава по целта: какво проверяваш и срещу какво. Не по това кога и кой.
По-точно, за любопитните
Нивата вървят заедно с видовете тестване (следващия урок). Функционално и нефункционално тестване има на всяко ниво: производителността на една функция е на ниво компонент, а производителността на целия магазин при 200 клиенти е на ниво система.
Упражнение
Нива в магазина
1. Кое ниво хваща грешката? За всяка грешка избери най-ниското ниво, на което тя се вижда.
Тест