Jak na testování?

Transkript

1 Jak na testování?

2 Proč? Vnímáme konstatní zájem zákazníků o problematiku testování Máme dlouholeté zkušenosti s testováním na mnoha zajímavých projektech

3 Naše zkušenosti Datamasking Procesní konzultace Synchronizace test. dat Automatizace testů QA Migrace Strategie testování Plně automatizované Vykonání testů Manuální

4 Program 9:00 9:10 Úvod 9:10 9:50 Otakar Ertl: Metodika testování internetového bankovnictví 9:50 10:30 Lukáš Mejdrech: Zátěžové testování Liferay portálu 10:30 11:00 Přestávka/občerstvení 11:00 11:40 Radek Václavík: Přístup k automatickému testování 11:40 11:50 Závěr

5 Testování IB České spořitelny Nový přístup k testování MCI Otakar Ertl

6 Agenda Představení IB České spořitelny Původní stav vývoje a testování Organizační změny Miniteamy Nová metodika Enterprise architect Propojení HPQC Dry Run testy Mockování Výsledky Diskuze

7 Servis24 & Business24

8 Servis24 & Business24 rychlá fakta 1,35 miliónu? uživatelů Cca 80% všech jednorázových příkazů realizovaných Českou spořitelnou Cca 5,3 mil. finančních transakcí za měsíc Více než 1000? obrazovek 4 velké release ročně Architektura připravena na paralelní vývoj minimálně na dvou nezávislých projektech

9 IB České spořitelny 4 vrstvy Rozsáhlá integrace 10 frontendů 18 backendů

10 Původní stav -vývoj Dokumentace v textové formě Pouze inkrementální postihování změn V rámci vývoje není prostor pro otestování nové funkcionality Oddělené teamy Veškerá komunikace s test teamem pouze přes HPQC defekty

11 Původní stav - testy Test dokumentace v excelu HPQC pouze na evidenci defektů Obrovské testy až 1500 řádek V exekuční fázi probíhalo až 7 překrývajících se kol Vysoká relativní chybovost evidováno cca 1200 chyb na release Testeři odděleni od vývojového teamu Na začátku testů cca 1. týden stovky showstoperů +

12 Současný stav Profinit jako systémový integrátor zastřešuje: Analýzu Vývoj Testování Systém testy (Funkční testy) Regresní testy Core testy

13 Organizační změny Miniteamy Jsou složeny z analytiků, vývojářů, testerů Pro každou novou funkcionalitu jeden mini team Vývojáři a testeři validují práci analytiků Testeři neformálně s vývojáři testují (DryRun test) Povinné buildování vývojářů Povinnost vývojářů po sobě vyzkoušet, že základní funkčnost funguje Výsledek odstranění showstoperů v prvním týdnu testů

14 Dry Run testy DESIGN IFAT SIT Dry Run Testy probíhající před SIT testy Neformální přístup Nutná koordinace termínů dodání vývoje a testingu Cíl: Odstranění show stoperů, základní otestování funkcionality, kontrola správnosti testovací dokumentace Prostředí: AT (vývojové) lokální build u vývojáře Mockování Organizace: miniteamy (analytik, vývojář, tester)

15 Mockování Simulace MW zpráv Vybrané zprávy nejsou odeslány na backendy ale jsou přesměrovány na mockovací simulátor Použití: Testy nové funkcionality, která ještě není na backendech vyvinuta. AT i ST2 prostředí

16 Nová metodika Enterprise architect Veškeré informace o fungování aplikace uloženy v EA EA obsahuje jedinou a jednoznačnou pravdu o aplikaci (odstranění inkrementů) HP Quality center Namapování HPQC na EA Plné využití HPQC jako jediného nástroje pro testování +

17 Informace uložené v EA Activity diagram

18 Informace uložené v EA Activity diagram Obrazovka

19 Informace uložené v EA Activity diagram Obrazovka Toky obrazovek

20 Mapování EA do QC

21 Přenos informací z EA do QC Export z databáze EA: Activity diagram Dílčí activity Obrazovky Toky obrazovek Pro všechny předchozí prvky umístění ve struktuře. Exportovány jsou pouze prvky pro daný release Vyexportovaný file ve formátu csv Import do QC: Standardní importovací tool QC

22 Namapování EA - QC

23 Namapování EA - QC

24 Namapování EA - QC

25 Namapování EA - QC

26 Namapování EA - QC

27 Struktura Totožné uložení objektů ve struktuře Objekty svázány přes unikátní ID převzaté z EA

28 Pokrytí REQ testy

29 Pokrytí REQ testy

30 Přínosy propojení EA a QC

31 Testy knihovny Volání vnořených testů z knihoven Využití - zejména navigace Výhody při změně stačí updatovat na jednom místě v knihovně

32 Testy - atributy

33 Testy životní cyklus

34 Testy - měříme

35 Coverage analysis

36 Dashboard

37 Výsledky přínosy - organizační změny Zvýšení kvality kódu vstupujícího do testů Pouze 2 testovací kola + 3 regresní Významné snížení chybovosti Snížení počtu showstoperů v prvním kole => rychlejší a efektivnější otestování

38 Defekty Defekty Porovnání vývoje defektů v21 a v V21 vs v23 První týden v21 vs v v21 v23 All v21 All v21 All v23 All v23 A Defects v23 A Defects v23 A Defects v A Defects v Dny

39 Výsledky přínosy - metodické změny Snadnější identifikace testů k modifikaci pro další verzi na základě propojení EA a HPQC Jednoduché vyhledávání Regresních testů k nové funkčnosti Jednoduché vyhledávání Core testů Benefity HPQC (reporting, navázání chyb na testy) Možnost přesného a rychlého plánování Snadné dohledávání jak se má aplikace chovat (jediná pravda v EA) Transformace na novou metodiku proběhla bez zvýšení nákladů => prostor pro budoucí úspory

40 Diskuze

41 Děkuji za pozornost

42 Zátěžové testování Liferay portálu Lukáš Mejdrech

43 Zátěžové testy

44 Zátěžové testy co znamenají? Znamenají Testování systému pod zátěží Více než jednotky uživatelů najednou Více než jednotky dotazů za sekundu Zpravidla automatizované testy Neznamenají Testy funkčnosti

45 Zátěžové testy co umožňují? Load testing

46 Zátěžové testy co umožňují? Load testing Endurance testing

47 Zátěžové testy co umožňují? Load testing Endurance testing Volume testing

48 Zátěžové testy co umožňují? Load testing Endurance testing Volume testing Stress testing

49 Zátěžové testy co umožňují? Load testing Endurance testing Volume testing Stress testing Capacity testing

50 Zátěžové testy co umožňují? Load testing Endurance testing Volume testing Stress testing Capacity testing Spike testing

51 Zátěžové testy co potřebují? Funkční systém Definovat oblast testování Definovat zátěž Definovat přípustná kritéria Definovat testovací scénáře Vytvořit transakční mix testovacích scénářů Připravit data Umožnit automatizovaný průchod Nastavit měření Zajistit exkluzivní přístup

52 Zátěžové testy jak probíhají? Příprava Vyhodnocení Provedení

53 Kontext

54 Architektura Testované webové portály Liferay Obdobné portály na aplikačním serveru Propojovací middleware Autentizační a autorizační systém Databáze Datový sklad Liferay Dokumentový server Externí rozhraní ESB IDM ODS Document Server Server SMS gateway

55 Příprava

56 Příprava Analytické schůzky Definice rozsahu, zátěže, kritérií Workshopy Definice procesů jako testovacích scénářů Příprava 14 testovacích scénářů Samostatné procesy, komponenty Sestavení transakčního mixu Opakovatelné testovací scénáře dohromady Úpravy aplikace Povolení jakýchkoli potvrzovacích kódů doručovaných v SMS Zobrazení odkazů doručovaných v ech Více než dvě stovky testovacích uživatelů Zatěžovací server s velmi rychlým připojením

57 Provedení

58 Provedení Nastavení Přístup z vnější sítě Exkluzivní přístup Provedení Postup Inicializace dat Nasazení upravené verze aplikace Spuštění monitorování serverů Spuštění testovacího scénáře převedení registrace Postupné spouštění samostatných testovacích scénářů se stejnou zátěží Transakční mix spouštěný postupně se vzrůstající zátěží Opakování po nápravě nalezených problémů

59 Apache JMeter Nástroj umožňující testovat: Webové aplikace přes protokoly HTTP a HTTPS Webové služby přes protokol SOAP Databáze pomocí JDBC LDAP JMS FTP y přes protokoly SMTP(S), POP3(S) a IMAP(S) Příkazy a skripty Open source

60 Testovací scénáře v JMeter Vytvářeny Na základě důležitých procesů S důrazem na pokrytí komponent Obsahovaly Konfiguraci pro jazykové mutace rozhraní Konfiguraci testovacích uživatelů Simulaci prohlížeče Hlavičky Cache Cookies Prodlevu mezi dotazy Čítače pro tvorbu unikátních ů a telefonních čísel Vyhledávání parametrů pro další dotazy Automatické kontroly odpovědí dotazy

61 Vyhodnocení

62 Vyhodnocení JMeter harmonogram JMeter dotazy Vytížení procesoru Využití paměti Swapování Využití síťových rozhraní Volání metod Vyhodnocení

63 Vyhodnocení samostatných scénářů Které dotazy trvají nejdéle? Kdy se přenáší nejvíce dat? Kolik dotazů nevyhovuje definovaným kritériím? Měnily se časy dotazů v průběhu testu? Která volání jsou nejpomalejší nebo dokonce kolabují?

64 Statistika dotazů - registrace Průměrná odezva serveru (ms) Průměrný čas odpovědi (ms) Průměrná velikost (KB)

65 Odezvy dotazů v průběhu testu Login 02 - Login.Prihlasit 03 - Registrace.Poslat_sms 04 - Registrace.Dalsi_krok 05 - Registrace.Dokoncit 10 - Registrace Registrace4.Dalsi_krok Čas

66 Odezvy dotazů v průběhu testu Problém při paralelním zpracování Login 02 - Login.Prihlasit 03 - Registrace.Poslat_sms 04 - Registrace.Dalsi_krok 05 - Registrace.Dokoncit 10 - Registrace Registrace4.Dalsi_krok Čas

67 Dotazy nevyhovující kritériím - vyhledávání Podle čísla smlouvy Podle u 100,00% 100,00% 90,00% 90,00% 80,00% 80,00% 70,00% 70,00% 60,00% 50,00% 40,00% 60,00% 50,00% 40,00% 01 - LoginCC 02 - LoginCC.Prihlasit 10 - Vyhledani.Vyhledat 11 - Odznaceni_klienta 20 - Vyhledani.Odhlasit 30,00% 30,00% 20,00% 20,00% 10,00% 10,00% 0,00% Odezva >2s Odezva >4s Odpověď >2s Odpověď >4s 0,00% Odezva >2s Odezva >4s Odpověď >2s Odpověď >4s

68 Metody volané portálem Počet volání Průměrný čas odpovědi (ms) authenticationbypassword getclient getclient - NO_DATA getidentity

69 Metody volané portálem Databázový problém u čísla smlouvy Počet volání Průměrný čas odpovědi (ms) authenticationbypassword getclient getclient - NO_DATA getidentity

70 Vyhodnocení transakčního mixu Jak se vyvíjí podíl chybových dotazů s rostoucí zátěží? Které části systému jsou vytíženy nejvíce? Jak se vyvíjí podíl dotazů nevyhovujících definovaným kritériím? Kolik dotazů zvládne systém rozumně obsloužit? Co se stane po opadnutí velké zátěže?

71 Podíly jednotlivých typů chyb 4% 3% 2% Nekompletní stránka HTTP Timeout HTTP Connection reset HTTP Connection refused SSL peer not authenticated 404 Not Found 502 Bad Gateway 1% 0% Počet souběžných uživatelů

72 Podíly jednotlivých typů chyb 4% 3% Systém dle požadavků obsluhuje 80 souběžných uživatelů 2% Nekompletní stránka HTTP Timeout HTTP Connection reset HTTP Connection refused SSL peer not authenticated 404 Not Found 502 Bad Gateway 1% 0% Počet souběžných uživatelů

73 Propustnost 25,0 20,0 19,9 16,4 15,0 14,3 10,0 9,7 Úspěšných požadavků/s 5,0 0, Počet souběžných uživatelů

74 Propustnost 25,0 Systém dle požadavků obsluhuje 16 dotazů za sekundu 20,0 19,9 16,4 15,0 14,3 10,0 9,7 Úspěšných požadavků/s 5,0 0, Počet souběžných uživatelů

75 Vytížení procesoru 100 Liferay Čas ESB IDM Čas 0 Čas

76 Vytížení procesoru 100 Liferay 75 Nejvytíženější je jednoznačně aplikační server Liferay Čas ESB IDM Čas 0 Čas

77 Závěr Byla zjištěna nejvyšší zátěž vyhovující požadavkům 80 souběžných uživatelů, 16 dotazů za sekundu Bylo odhaleno několik problémů Dlouhé dokončení převodu registrace při paralelním přístupu Dlouhé přihlášení se k nové registraci kvůli číslu smlouvy Dlouhé dokončení nové registrace Dlouhé vyhledávání podle čísel smluv Byla odhalena slabá místa Dlouhé stahování všech souborů při zobrazení prvních stránek Vytížení procesoru aplikačního serveru Liferay Velké prodlevy komunikace mezi Liferay a IDM

78 Diskuze

79 Děkuji za pozornost

80 Diskuze u občerstvení

81 Přístup k automatickému testování Radek Václavík

82 Agenda Základní body o automatickém testování (dále jen AT) Náklady a výnosy zavedení AT Metodika AT Technologie a nástroje pro AT Business cases příklady Jak začít s AT

83 Základní body

84 Definice Automatizace testů je použití software na řízení vykonávání testů, porovnávaní aktuálních výstupů testů s předpokládanými výstupy, nastavení testovacích podmínek a reportování výsledků.

85 Proč ANO? Opakovatelnost a konzistence testů stejné vstupy a podmínky nezávislé na počtu opakování, odpadá problém s motivací lidí k opakování stejných testů Praktická znovupoužitelnost testů lze opakovat stejný test v různých prostředích, v různých konfiguracích, s mírně modifikovanými vstupními daty, a znovuspuštění testu je levné Praktické baseline testy automatizace umožňuje spustit velmi hutnou sadu testů, umožňují efektivně provádět regresní testování Eliminace lidských chyb testy jsou vykonávány vždy naprosto stejně

86 Proč NE? Vyšší počáteční náklady analýza, implementace, SW licence, HW Nutná pravidelná údržba adaptace na novou funkcionalitu SW. Nutná podmínka použitelnosti! Nevhodnost pro dynamicky se měnící funkcionality lépe se hodí pro regresní testy

87 3 základní tvrzení ROI automatizovaných testů není založeno na automatizaci existujících testů versus nákladů jejich manuálního vykonání Za normálních okolností se bude testování skládat jak z automatizované tak z manuální části + Typicky má smysl uvažovat o regresních, výkonnostních a smoke AT 3

88 Náklady a výnosy

89 3 základní výnosy (hard $$) Úspora nákladů za manuální testování [% opak. testů * počet opakování * cena testů] Úspora nákladů na kvalitu [snížení počtu chyb * cena opravy chyby] Redukce time-to-market [časová úspora ve dnech * ztráta revenue na den]

90 3 základní náklady (hard $$) HW a SW infrastruktura [cena licencí nástroje AT + cena HW] Analýza a implementace AT [cena feasibility study + cena tvorby scénářů AT + cena implementace AT + cena úprav testované app] Údržba a rozvoj AT [cena podpory licencí AT + roční inkrement AT + roční údržba AT]

91 4 další výnosy (soft $$) Posun v kvalitě testů a jejich scenářů Možnost kdykoliv a prakticky zdarma přetestovat funkcionalitu aplikace Detailní logovací a auditní záznamy (lehká reprodukovatelnost chyby) Profesionalita: Automatizované testování je intelektuálně přitažlivější než manuální -> motivační faktor pro profesionalitu

92 Náklady na testy 4 4 Náklady

93 Naše metodika

94 Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba testů

95 Úvodní analýza Stanovuje technologické a funkční varianty, vymezuje rozsah pokrytí testy a náplň dalších etap Výstupy Definice požadavků na systém automatického testování Vymezení hranic testovaného systému Varianty pro technologický návrh systému automatického testování Specifikace okrajových podmínek automatizovaných testů Návrh přístupu k tvorbě a rutinnímu spouštění automatizovaných testů za specifikovaných okrajových podmínek Přibližné vymezení rozsahu požadovaných testovacích případů Business case, je-li požadován

96 Studie proveditelnosti Prověřuje a hodnotí stanovené alternativy, navrhuje řešení Výstupy Detailní technologický návrh systému aut. testování Popis způsobu hlášení chyb ze systému automatických testů Specifikace úprav existující testovací infrastruktury Vzorek aut. testů na ukázku, v rámci možností neupravené infrastruktury Popis tvorby/programování a rutinního spuštění automatizovaných testů za specifikovaných okrajových podmínek, Upřesnění rozsahu požadovaných testovacích případů, Plán projektu pro vlastní vývoj/implementaci testů.

97 Analýza a implementace Rozdělení projektu na fáze (výsledky jsou vidět průběžně) Data driven testing (test = scénář + data) Lze vytvářet sady testů dle potřeby Validace analýzy např. pojistní matematici, testovací oddělení Validace vlastních testů testovací oddělení

98 Údržba Testy JE POTŘEBA UDRŽOVAT Pravidelné spouštění Kontrola výsledků Aktualizace testů dle změn systému Další rozvoj testů dle potřeb zákazníka

99 Technologie

100 Dva přístupy k AT Code-driven testování Testování kódu na nižší úrovni GUI testování Princip simulace klienta Princip automatizace klienta

101 Simulace klienta Server Client/Browser Automat

102 Simulace klienta Užívaný zejména na webové aplikace, které podporují princip request response Výhodami jsou robustnost řešení, podobnost s vývojem aplikací a jednoduchost a přehlednost testovacích aplikací Nevýhodami jsou nemožnost capture replay a obtížné provádění operací jen na straně klienta (javaskript)

103 Automatizace klienta Server Client/Browser Automat

104 Capture - Replay Metoda, při níž se monitorují uživatelské aktivity (capture), které se následně opakují (replay) K obsluze zpravidla nejsou nutné žádné technické znalosti Pořízení testu znamená provedení testu, což znamená nejnižší možné náklady na pořízení Nízká robustnost provádění testů Získané skripty jsou často prakticky neudržovatelné, což vede k problémům při parametrizaci a navýšení nákladů při změnách

105 Automatizace klienta Většina řešení na bázi Automatizace vychází z metody capture replay a odstraňuje její nedostatky K ovládání klientské aplikace se používají zpravidla prostředky operačního systému Výhodou je obecnost nasazení nezáleží na typu testované aplikace Nevýhodou je opět potenciální složitost nasnímaných skriptů Rovněž je třeba zvážit programovací jazyk

106 Gartner Magic Quadrant for Integrated Software Quality Suites Zdroj: Gartner (Leden 2011)

107 Business case příklady

108 Seznam příkladů Česká pojišťovna core systém pro správu smluv životního pojištění ČSOB S-Cube Česká spořitelna Partner24 unit testy ČSOB Pojišťovna testování core systému

109 Příklad č. 1 Automatizace testů, Česká Pojišťovna GUI testy

110 Situace Core systém pro správu smluv životního pojištění Porovnání nákladů na manuální a automatické vykonávání Cca. 60 komplexních testů Manuální Cca. 100 MD/release 5 release/rok Automatické Implementace testů Pravidelné spouštění a kontrola výsledků Aktualizace testů dle změn systému

111 Propojení s jinými systémy SAP R3 SPS Printnet DACP SAP FSCD DWH KCČ IMO KDP JOK/CCD OCE JOK PWB CZP JOK PK JOK JOK/CCM SUP-ISP...

112 Projekt automatizace testů KDP Úvodní analýza (10 dní) Studie proveditelnosti, analýza a implementace vzorku testů (3 měsíce) Analýza a implementace testů, dělená na části (9 měsíců) Údržba Testů (roky)

113 Rozsah studie proveditelnosti Volba rozsahu automatizace Návrh architektury Změny aplikace KDP a ATest Plán projektu POC

114 Volba rozsahu automatizace Kritičnost = f (business důležitost, chybovost, náklady na testování, náklady na odstraňování chyb,potenciální náklady na AT) Funkce Systémy

115 Pokrytí systému automatizací Pokrytí 80% funkcí systému Integrační testy 6 funkcí Kritičnost 2 31 funkcí Kritičnost 5 66 funkcí Kritičnost 4 Funkce systému 18 funkcí Kritičnost 3 Pokrytí systému testy

116 Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba Testů

117 Plán projektu Fázování zajistí vyšší přidanou hodnotu pro zákazníka Fáze 1 11 testů nejvyšší kritičnosti Analýza Tvorba scénářů a kroků Ostatní podpůrné činnosti Milník 2 Milník 3 Milník 4 Fáze 2 dalších testů Analýza Tvorba scénářů a kroků Milník 5 Milník 1 Fáze 3 integrační testy a testy práv Analýza Tvorba scénářů a kroků

118 Testy a jejich validace Data driven testing (test = scénář + data) Lze vytvářet sady testů dle potřeby Validace analýzy pojistní matematici, testovací oddělení Validace vlastních testů testovací oddělení

119 Čísla 60 plně automatizovaných regresních testů Z toho 10 testů práv a integračních Infrastruktura pro automatizované testy Dokumentace pro vývoj a údržbu systému Cca. 700 čd. Doba běhu celé sady cca. 24 h.

120 Nalezené chyby Nevygenerování záznamu pro požadavek na finální odkup. Duplicitní storna předpisů při přerušení placení. Chyba v účetnictví. Chyba v právech (přístup na správu front úkolů). Další chyby menšího dopadu.

121 Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba Testů

122 Nároky na údržbu Zkušenosti z přechodu na R3 a dále na R4 Velké změny úrazového pojištění cca. 1 čd/test (R2 -> R3) Technické změny cca. 0,2 čd/test (R3 -> R4) Dáno dobře navrženou architekturou (knihovna pro GUI, atp.).

123 Nároky na interní zdroje Vlastní know-how pojišťovnictví nižší náklady na interní zdroje odběratele. Pojistný analytik kompletní analýzy testů Zapojení strany odběratele zejména na připomínkování a akceptaci.

124 Údržba 1 rok 1 člověk na plný úvazek. Kontrola výsledků, reporty chyb. Aktualizace testů dle změn systému KDP. Další rozvoj testů mírný a řízený aktuálními potřebami zákazníka.

125 Další projekty

126 Automatizace testování S-Cube PoC S-Cube Obsah dodávky: Ověření technologické kompatibility testovacího nástroje HP Quick Test Professional verze 11 s aplikací S-Cube Návrh přístupu strojové identifikace objektů (Descriptive Programming vs. Object Repository) Zavedení unikátních ID objektů ze strany vývoje do aplikace pro bezproblémovou identifikace napříč verzemi (nulové náklady) Ověření přenositelnosti testů mezi verzemi aplikace a verzemi vývojové technologie Návrh architektury aut. Testů Granularita testů Knihovny Metodika psaní testů Testovací data a jejich úklid Návrh kritérií pro výběr manuálních testů vhodných pro automatizaci

127 Partner24 Aplikace pro back office externího prodeje externí partnery Kritická modulární platforma, nad kterou vznikají další aplikace Charakteristiky Partner24 Rozsah systému: cca 350 obrazovek, cca 200 tabulek Počty uživatelů: Integrace s core systémy České spořitelny Funkční testování kompletně v režii zákazníka! Implementace a údržba testů: cca 5% Pokrytí testů: cca 30 40% funkčnosti

128 Balíčky Agenda povinného ručení, pojištění vozidel, nemovitostí a domácností. Automatizace celého životního cyklu smluv v systému kalkulačky pojistného, vznik, změny, storna, upomínky, výročí, tisky atd. Charakteristiky Rozsah systému: 1,8 milionu SLOC 400 obrazovek 2 4 releases ročně Počet uživatelů: tisíce Počet smluv: miliony Implementace a údržba testů: cca 5 % Pokrytí testů: cca 30 % funkčnosti

129 Jak začít s AT

130 Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba Testů

131 Úvodní analýza Stanovuje technologické a funkční varianty, vymezuje rozsah pokrytí testy a náplň dalších etap Výstupy Definice požadavků na systém automatického testování Vymezení hranic testovaného systému Varianty pro technologický návrh systému automatického testování Specifikace okrajových podmínek automatizovaných testů Návrh přístupu k tvorbě a rutinnímu spouštění automatizovaných testů za specifikovaných okrajových podmínek Přibližné vymezení rozsahu požadovaných testovacích případů Business case, je-li požadován

132 Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba Testů

133 Studie proveditelnosti Prověřuje a hodnotí stanovené alternativy, navrhuje řešení Výstupy Detailní technologický návrh systému aut. testování Popis způsobu hlášení chyb ze systému automatických testů Specifikace úprav existující testovací infrastruktury Vzorek aut. testů na ukázku, v rámci možností neupravené infrastruktury Popis tvorby/programování a rutinního spuštění automatizovaných testů za specifikovaných okrajových podmínek, Upřesnění rozsahu požadovaných testovacích případů, Plán projektu pro vlastní vývoj/implementaci testů.

134 Diskuze

135 Děkuji za pozornost

136 Děkujeme za pozornost