Видовете тестване
Накратко: Нивото казва къде тестваш, а видът какво и как. Функционалното проверява какво прави системата, нефункционалното колко добре. Черната кутия гледа поведението, бялата структурата. След поправка се пуска потвърждаващ тест за дефекта и регресионни тестове за всичко около него.
Проблем
Поправиха едното, счупиха другото
Клиент се оплаква: поръчка за точно 50,00 € плаща доставка. Програмистът поправя сравнението, тестерът пробва 50,00 € и вижда 0,00 €. Поправено.
На следващия ден счетоводството вижда, че промо кодът вече се вади два пъти. Поправката е сменила функцията за сумата, която ползва и промо кодът. Никой не е пуснал тестовете за промо кода, защото „пипахме доставката“.
Идеята
Видът е какво и как
Предишният урок каза къде тестваш: компонент, интеграция, система, приемане. Видът (test type) казва какво проверяваш и откъде идват тестовите случаи:
- Функционално тестване: какво прави системата. Таксата при 50,00 €, отказът на празна количка.
- Нефункционално тестване: колко добре. Бързина, достъпност, сигурност, надеждност: осемте характеристики на ISO/IEC 25010 извън функционалната пригодност.
- Черна кутия (black-box): тестовите случаи идват от спецификацията и поведението. Кодът не се гледа.
- Бяла кутия (white-box): тестовите случаи идват от структурата: разклоненията на функцията, пътищата през процеса.
Видовете се комбинират с нивата. Функционален тест по черна кутия на ниво система, нефункционален тест на ниво компонент: всяка двойка е възможна.
По-точно, за любопитните
В ISTQB CTFL v4.0.1 видовете са в раздел 2.2.2: функционално, нефункционално, черна кутия и бяла кутия. Програмата казва изрично, че всеки вид може да се прави на всяко ниво, но с различен фокус. Техниките за черна и бяла кутия (класове на еквивалентност, граници, покритие на разклонения) са в модула за тестов дизайн.
Пробвай
Какъв е тестът?
Идеята
След поправката: два въпроса
Когато дефект е поправен, пускаш тестове по два различни повода:
- Потвърждаващо тестване (confirmation testing): поправен ли е дефектът? Пускаш теста, който го показа, с точно същите стъпки. 50,00 € → 0,00 €.
- Регресионно тестване (regression testing): поправката счупи ли нещо, което работеше? Пускаш тестовете за всичко, до което промяната може да стигне. Сумата се ползва от промо кода, лоялността и плащането. Значи и техните тестове.
Грешката в нещо, което работеше, се казва регресия. Тя е най-неприятната, защото никой не гледа там: „пипахме доставката, не промо кода“.
По-точно, за любопитните
Потвърждаващото и регресионното тестване са в CTFL раздел 2.2.3. Регресионният набор расте с всяка версия, затова програмата препоръчва да се автоматизира и да се подбира по анализ на въздействието: кои части зависят от променената. Матрицата на проследимостта от модула „Проследимост“ отговаря точно на този въпрос.
Пробвай
Какво пускаш след поправката?
Идеята
Системата, която вече работи
Магазинът е пуснат. Оттук нататък всяка промяна е в работеща система с истински клиенти и данни. Тестването в нея се казва тестване при поддръжка (maintenance testing). Поводите са три:
- промяна: поправка, ново правило (прагът става 60 €), обновена библиотека, нова версия на операционната система;
- миграция: нова платформа, нов сървър, пренос на данни от стария магазин;
- извеждане от употреба: спира се старото приложение, а данните трябва да останат четими години наред.
Колко широко се тества зависи от два въпроса: колко голям е рискът от промяната и колко голяма е системата около нея. Поради това поддръжката винаги започва с анализ на въздействието: какво пипа промяната?
По-точно, за любопитните
Тестването при поддръжка е CTFL раздел 2.3. При миграция програмата споменава и проверката на пренесените данни (data conversion), а при извеждане от употреба и тестването на архива и на процедурите за възстановяване, когато данните трябва да се пазят дълго.
Упражнение
Видове и поводи
1. Тества ли се при поддръжка? За всяка промяна в работещия магазин кажи дали е повод за тестване и защо.
Тест