Specification by Example (SbE)

Specification by Example (SbE) on koostööl põhinev lähenemine tarkvaranõuete ja äriliste testide määratlemiseks. Selle asemel, et kirjutada abstraktseid spetsifikatsioone, kasutatakse konkreetseid näiteid, et luua ühine arusaam arendajate, testijate ja äripoole vahel.

Mis etapid seal on?

SbE protsess ei ole rangelt lineaarne, vaid pigem tsükliline. Gojko Adzici järgi on peamised sammud:

Eesmärkide seadmine: Määratletakse, miks me midagi teeme ja mis on äriline väärtus.
Spetsifitseerimine (Collaborative Specification): "Three Amigos" (arendaja, testija, tooteomanik) arutavad nõudeid ja loovad konkreetseid näiteid.
Illustreerimine: Näited kirjutatakse üles struktureeritud kujul (nt Gherkin keeles).
Automatiseerimine: Näited seotakse koodiga, muutes need käivitatavateks testideks.
Valideerimine: Testide käivitamine veendumaks, et süsteem vastab näidetele.
Elav dokumentatsioon (Living Documentation): Edukalt läbitud testid muutuvad usaldusväärseks dokumentatsiooniks.

Kas see on arendusmudel ja kas tal on alamvariante?

SbE on pigem metoodika või praktika kui täiemahuline arendusmudel (nagu Waterfall või Scrum), kuid see integreerub tihedalt Agile protsessidega. See on osa laiemast perekonnast:

Alamvariandid ja seotud terminid:

ATDD (Acceptance Test-Driven Development): Väga sarnane SbE-le. Fookus on vastuvõtutestide kirjutamisel enne koodi kirjutamist.
BDD (Behavior-Driven Development): SbE edasiarendus, mis keskendub süsteemi käitumise kirjeldamisele inimkeeles (nt "Given-When-Then" formaat). BDD on sageli see tehniline raamistik, mida SbE rakendamiseks kasutatakse.

Milline näeb välja arendusmudel joonisena?

Kuna SbE on tsükliline protsess, võib seda visualiseerida järgmise ahelana, mis kordub iga uue funktsionaalsusega:

Äriline eesmärk ➜ Arutelu & Näited ➜ Täpsustatud Spetsifikatsioon ➜ Käivitatav Test (Kood) ➜ Elav Dokumentatsioon

Joonise keskne idee on see, et spetsifikatsioon ja test on üks ja seesama asi.

Arendusmudeli tähtsaim omadus ja miks

Elav Dokumentatsioon (Living Documentation)

Miks? Traditsioonilises arenduses vananeb paberil (või Wikis) olev dokumentatsioon kohe, kui kood muutub. SbE puhul on dokumentatsiooniks automatiseeritud testid. Kui kood muutub ja testid enam ei läbi, siis "dokumentatsioon" karjub punaselt. See tagab, et dokumentatsioon on alati tõene ja sünkroonis tegeliku süsteemiga (Single Source of Truth).

Head ja Vead (Plussid ja Miinused)

Omadus	Plussid (Head)	Miinused (Vead)
Kommunikatsioon	Vähendab drastiliselt arusaamatusi äri ja IT vahel. Kõik räägivad "sama keelt".	Nõuab suurt kultuurilist muutust ja aktiivset osalust äripoolelt (mis võib olla raske).
Kvaliteet	Vähem vigu (bugisid), kuna nõuded on algusest peale selged ja testitud.	Esialgne ajakulu on suurem, kuna analüüs on põhjalikum enne koodi kirjutamist.
Hooldatavus	Tekib "Elav dokumentatsioon", mis on alati ajakohane.	Testide (näidete) haldamine võib muutuda koormavaks, kui neid on tuhandeid ja neid ei refaktoreerita.
Selgus	Konkreetsed näited välistavad mitmeti mõistetavuse (nt "kiire" vs "vastab 200ms").	Liiga keeruliste ärireeglite puhul võib näidete arv muutuda liiga suureks ja raskesti loetavaks.

Viited ja lisalugemist

Alljärgnevalt lingid usaldusväärsetesse allikatesse, kust info pärineb:

Wikipedia - SbE Martin Fowler - SbE