Vývoj řízený akceptační zkouškou - Acceptance test–driven development

Acceptance test-driven development ( ATDD ) je vývojová metodika založená na komunikaci mezi obchodními zákazníky, vývojáři a testery. ATDD zahrnuje mnoho stejných postupů, jako je specifikace podle příkladu (SBE), vývoj založený na chování (BDD), vývoj řízený příkladem (EDD) a vývoj zaměřený na podporu, nazývaný také vývoj založený na příběhu (SDD). Všechny tyto procesy pomáhají vývojářům a testerům porozumět potřebám zákazníků před implementací a umožňují zákazníkům konverzovat v jejich vlastním doménovém jazyce.

ATDD úzce souvisí s vývojem řízeným testy (TDD). Liší se důrazem na spolupráci mezi vývojářem, testerem a zákazníkem. ATDD zahrnuje akceptační testování , ale zdůrazňuje psaní akceptačních testů, než vývojáři začnou kódovat.

Přehled

Akceptační testy jsou z pohledu uživatele - z vnějšího pohledu na systém. Zkoumají externě viditelné efekty, jako je zadání správného výstupu systému s daným konkrétním vstupem. Akceptační testy mohou ověřit, jak se stav něčeho mění, například objednávky, která přejde z „zaplaceno“ na „odesláno“. Mohou také kontrolovat interakce s rozhraními jiných systémů, jako jsou sdílené databáze nebo webové služby. Obecně jsou nezávislé na implementaci, i když jejich automatizace nemusí být.

Tvorba

Akceptační testy se vytvářejí při analýze požadavků a před kódováním. Mohou být vyvíjeny společně žadatelem požadavků (vlastník produktu, obchodní analytik, zástupce zákazníka atd.), Vývojářem a testerem. Vývojáři implementují systém pomocí akceptačních testů. Neúspěšné testy poskytují rychlou zpětnou vazbu, že požadavky nejsou splněny. Testy jsou specifikovány v podmínkách obchodní domény. Tyto výrazy pak tvoří všudypřítomný jazyk, který sdílejí zákazníci, vývojáři a testeři. Testy a požadavky spolu souvisejí. Požadavek, kterému chybí test, nemusí být správně implementován. Test, který neodkazuje na požadavek, je nepotřebný test. Přijímací test, který je vyvinut po zahájení implementace, představuje nový požadavek.

Strategie testování

Akceptační testy jsou součástí celkové testovací strategie. Jsou to zákaznické testy, které demonstrují obchodní záměr systému. Testy komponent jsou testy technické přejímky vyvinuté architektem, které specifikují chování velkých modulů. Testy jednotek vytváří vývojář pro správu snadno udržovatelného kódu. Často jsou odvozeny z přejímacích zkoušek a jednotkových testů. Cross-funkční testování zahrnuje testování použitelnosti, průzkumné testování a testování vlastností (škálování a zabezpečení).

Kritéria přijetí a testy

Kritéria přijetí jsou popisem toho, co by bylo kontrolováno testem. Vzhledem k požadavku jako „Jako uživatel si chci rezervovat knihu z knihovny“ může být kritériem přijetí „Ověřit, že je kniha označena jako rezervovaná“. Přijímací zkouška pro tento požadavek poskytuje podrobnosti, aby mohla být zkouška spuštěna se stejným účinkem pokaždé.

Formát testu

Akceptační testy mají obvykle tento tvar:

Dáno (nastavení)

Zadaný stav systému

Když (spoušť)

Dojde k akci nebo události

Pak (ověření)

Stav systému se změnil nebo byl vytvořen výstup

Je také možné přidat příkazy, které začínají AND v kterékoli z níže uvedených sekcí (Zadáno, Kdy, Pak).

U ukázkového požadavku mohou být kroky uvedeny jako:

Given Book that has not been checked out
And User who is registered on the system
When User checks out a book
Then Book is marked as checked out

Kompletní test

Předchozí kroky nezahrnují žádná konkrétní příkladová data, takže se přidají k dokončení testu:

Dané:

Kniha, která nebyla odhlášena

Uživatel, který je registrován v systému

Když:

Uživatel rezervuje knihu

Pak:

Kniha je označena jako rezervovaná

Zkouška na zkoušku

Zkouška testu konkrétními údaji obvykle vede k mnoha otázkám. U ukázky to mohou být:

• Co když je kniha již vydána?
• Co když kniha neexistuje?
• Co když uživatel není v systému zaregistrován?
• Existuje datum, kdy má být kniha odbavena?
• Kolik knih si může uživatel rezervovat?

Tyto otázky pomáhají osvětlit chybějící nebo nejednoznačné požadavky. K očekávanému výsledku lze přidat další podrobnosti, například termín splatnosti. Jiné akceptační testy mohou zkontrolovat, že podmínky, jako je pokus o vydání knihy, která je již rezervována, způsobí očekávanou chybu.

Další příklad testu

Předpokládejme, že obchodní zákazník chtěl obchodní pravidlo, že si uživatel může rezervovat pouze jednu knihu najednou. Následující test by prokázal, že:

Scénář: Zkontrolujte, zda je vynucováno obchodní pravidlo pokladny

Dané:

Kniha, která byla rezervována

Když:

Uživatel si rezervuje jinou knihu

Pak:

Došlo k chybě

Akceptační testy projektu

Kromě přejímacích zkoušek požadavků lze na celém projektu použít přejímací zkoušky. Například pokud byl tento požadavek součástí projektu pokladny knih v knihovně, mohly by existovat akceptační testy pro celý projekt. Často se jim říká cíle SMART . Příklad testu je „Když bude nový knihovní systém ve výrobě, uživatelé budou moci knihy přihlašovat a odhlašovat třikrát rychleji než dnes“.

Viz také

• Harmonika
• FitNesse
• Robot Framework
• Měřidlo (software)
• Okurka (software)

Reference

externí odkazy

• Příklad rámců automatizace