Ekstreemprogrammeerimisest on saanud alguse kasutajalood (User Story). Neid on nime järgi lihtne segamini ajada kasutuslugudega (Use-Case), kuid sisu poolest on need vägagi erinevad.

Esmane kasutus kasutajalugudel oli seda võtta märkmena, et sellisest funktsionaalsusest on vaja rääkida ja ehitada. Neile lisati märkuseid ja hinnati punktisüsteemis keerukuse järgi või ideaalsetes päevades. Kasutajalood jagati ülesanneteks, millele lisati reaalsem ajakulu juurde.

Kuna kasutajalood olid peamiselt kirjutatud paberile ning see andis võimaluse märkida vastuvõtu testid teisele poole.

Alguses kirjutati neid suhteliselt erinevalt, kuid ajapikku on leitud neile omane muster:

<Rollina> soovin <funktsionaalust>, et saavutada <ärilist väärtust>
As a <role> I want <functionality> so that <business value>

Selle malli järgi näeme, et väärtustatakse oluliselt funktsionaalsust, kuid tõstes seda veidi ümber viime vaatenurga tegelikule väärtusele.

<ärilise väärtuse> saavutamiseks <rollina> soovin <funktsionaalsust>
In order to <business value> as a <role> I want <functionality>

Minimaalne väärtust omav omadus (Minimal Marketable Feature, MMF), mida Lean Software Developmentis kasutakse, on võimalikult väike funktsionaalsus, mis toob juurde ärilist väärtust (lihtsustab tööd, toob raha sisse, vähendab kulusid jms). Kasutajalugude tasemel võime grupeerida need ärilise väärtuse järgi ning saamegi minimaalsed väärtust andvad omadused.

Nende eripäraks on see, et ajaline kulu peaks olema küllaltki sama. Vähemalt nii oleks neid mõistlik luua, sest leani puhul on hindamine raiskamine ja ühtlase tsükli aja saavutamiseks on vaja suuruselt vähe kõikuvaid ülesandeid.

Kui kellelgi juhtub olema mõni “sõjajutt” nende kasutamisest, siis kirjutage julgelt kommentaaridesse. Neid on ikka põnev lugeda.

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , , ,

2 kommentaari

1

Kas oskate siin ära tuua ka konkreetseid realisatsioone erinevates keeltes nagu Cucumber on seda Rubys?

Priit
21:25, 15. september

2

Üldiselt kasutajalood on kasutuseks analüüsis. Selle võib jagada tehnilisteks spetsifikatsioonideks. Kui see on paberile kirjutatud, siis kasutatakse teist poolt, et märkida mida testida ning need oleksid lähedasemad spetsifikatsioonidele.

“Ostukorvi tasumiseks tellijana soovin maksta krediitkaardiga (Visa, MasterCard).”

Selle testid võiksid olla:
Kontrollida krediitkaardi kehtivust.
Tellimus olek muudetakse aktiivseks.

Need testid saaks kirjutada lahti spetsifikatsioonina (Given-When-Then, Context-Because-Should, Arrange-Act-Assert):
Tellimus on kinnitatud ja kui tasun krediitkaardiga, siis tellimuse olek peab olema aktiivne (tellimust hakatakse täitma).

Oled sa muidu proovinud kasutajalugusid Cucumberiga testida? Mulle tunduks, et neid tuleks liialt palju, et jõuaks tellijale neid kõiki läbi töötada ja osa oleks liiga pisikesed.

Marek Tihkan
21:42, 15. september

Lisa kommentaar

  • * Kuvatakse kommentaari juures
  • * Ei publitseerita