Когато таблицата е по-ясна
Накратко: Текстът е добър за едно правило, но лош за много случаи. Процесът показва кой какво прави и в какъв ред, случаят на употреба показва целта и отклоненията, машината на състоянията показва живота на поръчката, а таблицата на решения показва всяка комбинация.
Проблем
Три изречения, два отговора
Собственикът пише правилото за отстъпките:
Промо кодът дава 10 % отстъпка. Кодът не важи за продукти в намаление. Лоялните клиенти имат 5 % отстъпка винаги. Отстъпките не се събират.
Програмистът и тестерът го четат. Лоялен клиент, с валиден код, купува продукт, който не е в намаление. Програмистът смята 10 %. Тестерът смята 15 %, защото „винаги“. Всяко изречение е ясно само по себе си. Комбинацията не е.
Три условия с по два отговора правят осем случая. Текстът ги описва на части. Таблица ще ги покаже всичките.
Идеята
Кога картинката е по-ясна
Текстът е добър за едно правило. Когато има ред, много участници, много състояния или много комбинации, моделът казва повече:
| Въпросът | Моделът | В магазина |
|---|---|---|
| Кой какво прави и в какъв ред? | бизнес процес (business process) | поръчката от количката до куриера |
| Как един човек постига една цел, и какво може да се обърка? | случай на употреба (use case) | „Поръчай“ |
| Какъв е животът на едно нещо? | машина на състоянията (state machine) | нова → платена → изпратена → доставена |
| Какво става при всяка комбинация от условия? | таблица на решения (decision table) | промо код, намаление и лоялност |
Моделът не заменя изискванията. Той е изискване, записано в друга форма, и затова може да се рецензира и тества като всяко друго.
Идеята
Бизнес процесът
Бизнес процесът показва стъпките на една работа, в ред, по участници. Стандартната нотация е BPMN. Тук стигат четири знака: събитие (кръг: нещо се случва, например начало или край), дейност (правоъгълник: някой прави нещо), разклонение (ромб: въпрос с няколко изхода) и пътеки (ленти: по една за всеки участник).
Процесът на поръчката, записан като таблица:
| № | Пътека | Знак | Стъпка |
|---|---|---|---|
| 1 | Клиент | събитие (начало) | Клиентът натиска „Поръчай“. |
| 2 | Магазин | дейност | Създава поръчка в състояние „нова“. |
| 3 | Клиент | дейност | Плаща с карта. |
| 4 | Магазин | разклонение | Плащането мина? Не → край „Поръчката чака плащане“. Да → 5. |
| 5 | Магазин | дейност | Отбелязва поръчката като „платена“. Складът печата етикета. |
| 6 | Склад | дейност | Пакетира и предава пратката на куриера. Поръчката е „изпратена“. |
| 7 | Куриер | дейност | Доставя пратката. Поръчката е „доставена“. |
| 8 | Клиент | събитие (край) | Клиентът има пратката. |
Таблицата е по-бедна от рисунката, но казва същото. Най-ценното в нея е стъпка 5: там работата минава от магазина към склада, и там се загуби новият адрес.
По-точно, за любопитните
BPMN (Business Process Model and Notation) е стандарт на OMG, версия 2.0. Има още много знаци: съобщения между участници, таймери, подпроцеси, изключения. В BABOK моделирането на процеси (Process Modelling) е отделна техника. За анализатора и тестера четенето стига: да видиш пътеките, разклоненията и местата, където работата минава от един на друг.
Пробвай
Прочети процеса
Идеята
Случаят на употреба
Случаят на употреба (use case) описва как един актьор (actor: роля извън системата) постига една цел със системата. Има основен поток, по който всичко върви добре, и алтернативни потоци за всичко, което може да се обърка.
Случай: Поръчай. Актьор: клиентът. Предусловие: клиентът е влязъл в профила си.
Основен поток:
- Клиентът отваря количката.
- Системата показва продуктите, сумата и доставката: 0,00 € от 50 € включително, иначе 4,90 €.
- Клиентът избира адрес.
- Клиентът натиска „Поръчай“.
- Системата създава поръчката като „нова“ и показва плащането.
- Клиентът плаща. Системата отбелязва поръчката като „платена“ и праща потвърждение.
Алтернативни потоци:
- 2а. Количката е празна: системата не позволява поръчка и казва защо.
- 2б. Някой продукт е повече от 10 бройки: системата казва колко е най-много и не продължава.
- 4а. Клиентът е въвел промо код, който вече е ползвал: системата отказва кода, сумата остава без отстъпка, и клиентът продължава от стъпка 4.
- 6а. Плащането е отказано: поръчката остава „нова“, а клиентът може да опита отново.
Основният поток го пише всеки. Стойността е в алтернативните. Всяко от тях е правило, което програмистът трябва да направи и тестерът да провери.
По-точно, за любопитните
Формата тук е близка до тази на Alistair Cockburn, „Writing Effective Use Cases“: основен успешен сценарий (main success scenario) и разширения (extensions) с номера на стъпката. UML има и диаграма на случаите на употреба: човече за актьора и овал за случая. Тя показва кои случаи има, но не и какво става в тях. Текстът по-горе казва повече.
Пробвай
Прочети случая
Идеята
Машината на състоянията
Поръчката живее: тя е нова, после платена, после изпратена, после доставена. Всяко такова положение е състояние, а минаването от едно в друго, при някакво събитие, е преход. Заедно те са машина на състоянията (state machine).
Като таблица, машината на поръчката изглежда така:
| От | Събитие и условие | Към |
|---|---|---|
| Нова | клиентът плаща | Платена |
| Нова | клиентът отказва | Отказана |
| Платена | складът предава пратката на куриера | Изпратена |
| Изпратена | куриерът доставя | Доставена |
| Доставена | клиентът заявява връщане, до 14 дни от получаването | Върната |
Таблицата показва и това, което не е позволено. Всяка двойка „от → към“, която я няма, е забранена. Изпратена поръчка не става отказана. Доставена не става нова.
Тук е силата ѝ. В текста „отказът е позволен преди изпращането“ звучи ясно. В таблицата веднага се вижда дали всеки случай „преди изпращането“ има свой ред.
Упражнение
Кой ред липсва?
1. Липсващият преход. Сравни таблицата на преходите с правилата на магазина.
Идеята
Таблицата на решения
Таблицата на решения (decision table) има по ред за всяко условие и всяко действие, и по колона за всяка комбинация. Правилото за отстъпките от началото, след като собственикът е казал, че при две отстъпки важи по-голямата:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| Кодът е валиден | да | да | да | да | не | не | не | не |
| Продуктът е в намаление | да | да | не | не | да | да | не | не |
| Клиентът е лоялен | да | не | да | не | да | не | да | не |
| Отстъпка | ? | 0 % | ? | 10 % | 5 % | ? | 5 % | 0 % |
Таблицата върши две неща. Първо, тя е изискване, което се чете по един начин: всеки случай има точно един отговор. Второ, тя показва дупките в текста. Колона 3 е точно мястото, където програмистът и тестерът не бяха съгласни. Въпросът към собственика („10 или 15 %?“) идва от празната клетка, не от вдъхновение.
По-точно, за любопитните
Таблиците на решения са и техника за тестов дизайн (ISTQB CTFL, техниките на черната кутия). Там всяка колона е тестов случай, а колони с еднакъв резултат се сливат с „—“ (няма значение): например колони 5 и 7 са „код не, лоялен да → 5 %“, независимо от намалението. Модулът „Техники за тестов дизайн“ продължава оттук. В изискването таблицата е пълна, за да не остане случай, който никой не е обмислил.
Упражнение
Моделите като изисквания
1. Попълни таблицата. Трите празни клетки от таблицата на отстъпките, и колко са колоните.
Тест