Тестването в жизнения цикъл
Накратко: Моделът на разработка сменя кога се тества, а не дали. В каскадния модел тестването е фаза накрая, в Agile е във всяко стори, в DevOps е в конвейера при всяка промяна. Shift-left мести проверката към изискването. Пирамидата казва колко тестове на кое ниво, а квадрантите какви видове.
Проблем
Тестерите получиха магазина в последния месец
Проектът за новия магазин е по план: 3 месеца изисквания, 6 месеца програмиране, после тестване. В последния месец тестерите намират 140 дефекта. 30 от тях не са в кода, а в изискванията: „до 14 дни“ без от кога, „над 50 €“ без дали е включително.
Да се поправи изискване в 10-ия месец значи да се пипа код, писан в 4-ия. Пускането се отлага с 3 месеца.
Идеята
Моделът сменя кога, а не дали
Във всеки модел на разработка (software development life cycle) тестването го има. Различно е кога и как:
| Модел | Къде е тестването |
|---|---|
| Каскаден (waterfall) | Отделна фаза накрая, след целия код. |
| V-модел | Всяка фаза има свое ниво на тестване, планирано от началото: изискванията → приемане, архитектурата → интеграция. |
| Итеративен (iterative, incremental) | Във всяка итерация се тества новото и с регресионни тестове всичко старо. |
| Agile (Scrum, Kanban) | Във всяко стори. QA е в екипа, а „готово“ значи и тествано (Definition of Done). |
| DevOps | В конвейера (CI/CD): всяка промяна минава автоматично през тестовете, преди да стигне до клиентите. |
Едно правило важи за всички: за всяка дейност по разработката има съответна дейност по проверката. Изискването има рецензия, кодът има тест, сторито има критерии за приемане.
По-точно, за любопитните
Това е CTFL v4.0.1, раздел 2.1. Програмата изброява добрите практики, които важат за всеки модел: всяка дейност по разработката има съответна тестова дейност; всяко ниво има свои цели; анализът и дизайнът на тестовете започват по време на съответната фаза на разработката; тестерите преглеждат работните продукти веднага щом има чернова. DevOps е в 2.1.4, а shift-left в 2.1.5.
Пробвай
Кой модел?
Идеята
Shift-left: наляво по времето
Нарисувай проекта като линия: изискване, дизайн, код, тест, пускане. Shift-left значи проверката да се мести наляво, към началото.
В магазина това са неща, които вече видя в курса:
- рецензия на изискването „безплатна доставка над 50 €“, преди кода: включително ли е 50,00 €?
- Example Mapping и примери за всяко правило, преди сторито да влезе в работа;
- сценарии, написани преди кода, които после стават автоматични тестове;
- тестове на компонент, които програмистът пуска при всяка промяна.
Shift-left не значи по-малко тестване накрая. Значи, че накрая намираш по-малко, защото повечето дефекти са хванати там, където струват най-малко.
По-точно, за любопитните
Shift-left има цена: обучение, време в началото, автоматизация. CTFL v4.0.1 казва и това: подходът изисква усилие в началото, а спестяването идва по-късно. Обратното понятие, shift-right, е тестване и наблюдение след пускането: мерене при истинските клиенти, постепенно пускане на нова функционалност. За него е модулът „Валидиране с клиента“.
Идеята
Пирамидата: колко тестове на кое ниво
Пирамидата на тестовете (test pyramid) казва колко тестове да има на всяко ниво:
- Основата: много тестове на компонент. Хиляди, пускат се за секунди, сочат точно грешката.
- Средата: по-малко тестове на интеграцията и на услугите. Проверяват договорите между частите.
- Върхът: малко тестове от край до край през целия магазин и браузъра. Бавни са, чупят се от смяна на един бутон, а когато паднат, още не знаеш къде е грешката.
Колкото по-нагоре, толкова по-бавни, по-скъпи и по-крехки са тестовете, и толкова по-малко трябва да са. Обърнатата пирамида, с хиляди тестове през браузъра и няколко на компонент, се казва фунийка за сладолед.
По-точно, за любопитните
Пирамидата е на Майк Кон (Mike Cohn, „Succeeding with Agile“, 2009). Не е закон: броят на нивата и имената им се различават. Програмата CTFL v4.0.1 я описва в раздел 5.1.6 като модел, който показва, че тестовете в по-ниските нива са по-малки, по-бързи и повече, а в по-високите по-бавни, по-големи и по-малко.
Идеята
Квадрантите: какви видове
Пирамидата брои. Квадрантите на тестването (testing quadrants) подреждат видовете по два въпроса: насочен ли е тестът към бизнеса или към технологията, и подкрепя ли екипа, докато прави, или критикува готовия продукт.
| Подкрепят екипа | Критикуват продукта | |
|---|---|---|
| Бизнес | Q2: сценарии и примери, прототипи, функционални тестове | Q3: изследователско тестване, използваемост, UAT, демо |
| Технология | Q1: тестове на компонент и на интеграцията | Q4: производителност, натоварване, сигурност |
Q1 и Q2 обикновено са автоматизирани. Q3 е ръчен: човек гледа продукта. Q4 се прави с инструменти. Екип, който има само Q1, има бърз код, но не знае дали е правилният продукт.
По-точно, за любопитните
Квадрантите са на Брайън Марик (Brian Marick, 2003), популярни от книгите на Лиза Криспин и Джанет Грегъри за Agile тестване. В CTFL v4.0.1 са в раздел 5.1.7.
Упражнение
Квадрантите в магазина
1. В кой квадрант? Подреди тестовете на магазина.
Тест