Quality Assurance. Ondřej Suchý Competency Consultant

Transkript

1 Quality Assurance Ondřej Suchý Competency Consultant

2 Agenda Obsah Představení Definice Quality Assurance Aspekty kvality Teoretický rámec Příklad QA v Profinitu Příklady projektů QA Diskuze

3 Představení Ondřej Suchý Historie zaměstnavatelů: 2011 Profinit Competency Consultant Unicorn Consultant Project Manager Marketing Director Vzdělání: Vysoká škola ekonomická Fakulta Mezinárodních vztaů Mezinárodní obchod Management v informační společnosti Specializace: Metodika SW vývoje Procesní modelování a optimalizace Business Analýza Klienti: Banky a finanční instituce Komerční banka, Všeobecná úverová banka, Factoring České spořitelny, ŠkoFIN, Santander Consumer Finanace Pojišťovny Allianz pojišťovna Telekomunikace T-Mobile Czech Republic Státní organizace Státní zemědělský intervenční fond Know-How: Metodika RUP, UML, Prince2, ITIL, BPMN, UBML, Zachmanův Framework Case Enterprise Architect, Corporate Modeler, ARIS Toolset, MEGA, MS Visio DBMS MySQL

4 Profinit Produktivita Profinit Poslání Profinitu: přinášet našim zákazníkům řešení s prokazatelnými přínosy pro jejich efektivní fungování a růst. Chybovost Průměr SLOC/hod Obrat 2010 (mil. Kč): 273 CZ + 42 SK Počet zaměstnanců: 160 CZ + 40 SK Profinit Průměr Chyb/KSLOC

5 Profinit Produkty a služby Distribution Channels EPM Operations Software Development IT Governance Business Intelligence

6 Nabídka Profinitu Business řešení Performance Mangement Business Execution Čistota dat Elektronické dokumenty Informační bezpečnost Správa podnikového obsahu Datové schránky Finanční plánování Elektronická faktura Objednávkové formuláře Oracle IRM Řešení pro nestrukturované informace IT řešení Vývoj software na zakázku Testování a QA Integrace SW systémů Datový sklad Data Management Outsourcing IT specialistů Desktop aplikace Webové aplikace Mobilní aplikace Strategie a rozsah testování Automatizované testy Nezávislé externí testování Datová integrace ETL Transformace Aplikační integrace ETL, Reporting SW proces v datovém skladu Metadata a Master Data Management Datová kvalita

7 Zákazníci Ministerstvo spravedlnosti ČR

8 Spolupráce Profinitu s vysokými školami Naším cílem je sblížit požadavky budoucích zaměstnavatelů s tím, čemu se mladí lidé věnují v rámci studia. ACM SPY VÝUKA A DALŠÍ Profinit spolu s českými a slovenskými technickými vysokými školami organizuje soutěž ACM SPY (Czech ACM Chapter & Slovakia ACM Chapter Student Project of the Year ), v níž je vybírána nejlepší diplomová a nejlepší bakalářská práce v oblasti informatiky a informačních technologií. Záštitu převzala odborná organizace Czech ACM a Slovakia ACM. Od roku 2007 zajišťuje Profinit výuku semestrálních předmětů na ČVUT a MFF UK, a to včetně garantování odborného obsahu. Naši odborníci jsou také často vysokými školami zváni jako speakeři na jednorázové přednášky, většinou s cílem přiblížit studentům vývoj software v praxi. Profinit s vybranými studenty spolupracuje na jejich semestrálních projektech, opět s cílem přiblížit studentům potřeby praxe. Sponzorujeme vysokoškolská pracoviště nákupem knižních titulů s počítačovou tématikou a podporujeme účast škol na prestižních soutěžích a odborných konferencích.

9 Quality Assurance

10 Quality Assurance Definice Wikipedia: Systematické sledování a hodnocení různých aspektů projektu, služby nebo zařízení s cílem maximalizovat pravděpodobnost, že budou ve výrobním procesu dodržovány minimální standardy. American Society for Quality: Quality Assurance je soubor plánovaných a systematických aktivit, které mají za cíl zajistit, že budou splněny požadavky na vyvíjený produkt nebo službu.

11 Quality Assurance Aspekty kvality Kvalita Produkt nebo poskytnutá služba splňuje požadavky nebo očekávání svých uživatelů a zadavatelů Kvantita Produkt nebo služba svým rozsahem nebo množstvím odpovídá požadavkům Termín Produkt nebo služba je dodána v očekávaném nebo dohodnutém čase Rozpočet Produkt nebo služba je dodána za očekávanou nebo dohodnutou cenu

12 Teoretický rámec ISO Systém managementu kvality Formální uznání potřeby řídit kvalitu managementem i zaměstnanci společnosti Závazek průběžně zlepšovat kvalitu na základě naměřených dat a pravidelně ověřovat soulad se standardem (recertifikace) Evidence záznamů průběhu produkce a komunikace s klienty Vývoj nových produktů po ověřitelných krocích Zajištění průběžného měření výkonu a kvality Existence postupů pro řešení zjištěných závad

13 Teoretický rámec Capability Maturity Model Původně vyvinut na posuzování spolehlivosti dodavatelů Definuje 5 úrovní dospělosti organizace Skóre určuje množství atributů z oblasti definic procesů a jejich dodržování

14 Teoretický rámec CMM Vybrané KPA (Key Process Areas) KPA Validace Příprava na validaci Výběr produktů k validaci Ustanovení prostředí Ustanovení postupů a kritérií Validace produktu Provedení validace Analýza výsledků Nároky na proces testování generují nepřímo i další KPA Plánování projektu Organizace práce (delegace kompetencí a odpovědnosti, ) Konfigurační řízení Školení, vzdělávání KPA Verifikace Příprava na verifikaci Výběr produktů k verifikaci Ustanovení prostředí Ustanovení postupů a kritérií Provedení přezkoumání Příprava na přezkoumání Provedení přezkoumání Analýza dat z přezkoumání Verifikace produktů Provedení verifikace Analýza výsledků

15 Teoretický rámec V-Model Ilustruje souvislost mezi jednotlivými úrovněmi validace zadání a verifikace výstupů Validace - vyhovuje produkt zákazníkovi? Verifikace - vyhovuje produkt specifikaci?

16 Teoretický rámec IBM Rational Unified Process Metodika SW vývoje Doporučuje postupy, formu dokumentace a zodpovědnost

17 Teoretický rámec Six Sigma Strategie řízení s cílem minimalizovat chyby v procesech výroby a obchodu Pracuje s metodami DMAIC a DMADV: DMAIC se používá na projektech zaměřených na optimalizaci existujících procesů DMADV se používá na návrh nových produktů nebo procesů

18 Teoretický rámec ITIL Information Technology Infrastructure Library Sada konceptů a nejlepších praktik pro vývoj, údržbu a provoz IT/IS Doporučuje mj. i postupy z oblastí: Servisní podpora Změnové řízení Konfigurační řízení Správa infrastruktury Řízení bezpečnosti

19 Teoretický rámec COBIT Control Objectives for Information and related Technology Soubor obecně uznávaných opatření, indikátorů, procesů a nejlepších praktik určených k maximalizaci prospěchu z IT a k vytvoření vhodného procesu řízení IT v podniku. Pokrývá 4 základní domény: Plánování a organizace Pořízení a implementace Dodávka a podpora Monitoring a hodnocení

20 Příklad Hypotetická situace: Byli jste pověření zajištěním QA na projektu vývoje nového informačního systému pro VŠE Vyjmenujte oblasti, kterým se budete věnovat Neřešte konkrétní postupy, pouze oblasti Projektový plán bude podle šablony Budou určeny šablony projektové dokumentace

21 QA v Profinitu Řízení Dokumentace Standardy a praktiky Audity a review Testování Monitoring chyb a oprav Nástroje a technologie Konfigurační řízení Řízení subdodávek Řízení záznamů Školení Řízení rizik

22 QA v Profinitu Minimální nároky Pragmatické a efektivní Základ firemního procesu Projekt se vůči nim vymezuje

23 QA v Profinitu Ve většině oblastí QA jde hlavně o zdravý rozum. ŘÍZENÍ DOKUMENTACE STANDARDY A PRAKTIKY AUDITY A REVIEW KONFIGURAČNÍ ŘÍZENÍ ŘÍZENÍ SUBDODÁVEK ŘÍZENÍ ZÁZNAMŮ ŠKOLENÍ ŘÍZENÍ RIZIK Aktivity v daných oblastech jsou plánovány, prováděny a vyhodnocovány Průběh aktivit je formalizován metodikou, která odpovídá nejlepším praktikám, prostředí zákazníka a typu projektu Průběh aktivit je dokumentován vhodnou formou a na odpovídající úrovni podrobnosti V každé z oblastí existuje mechanizmus detekující případné nedostatky a umožňující nápravu

24 QA v Profinitu Testování Do předmětu QA patří minimálně: Verifikace, že veškerý vykonatelný kód prošel unit testy a že ke všem požadavkům byly připraveny a provedeny systémové, integrační a uživatelské akceptační testy. Verifikace, že existují adekvátní testovací postupy, scénáře, procedury a reporty, jak je definované v plánu (strategii) testování. Verifikace, že plán (strategie) testování existuje a je efektivně implementován. Participace QA týmu na testování ve všech kontextech, kde je to vhodné a možné. Verifikace, že zvolený mechanismus testování je pro daný typ projektu/výstupu vhodný a že splňuje normativní požadavky na tuto oblast definované v daném projektu, nebo organizaci.

25 Testování Kontext testování Testování je ověření, že produkt splňuje požadavky, které jsou na něj kladeny. Požadavky jsou kategorizovány: Funkcionality (funkčnost) Usability (použitelnost) Reliability (spolehlivost) Performance (výkon) Supportability (podporovatelnost) V některých případech jsou kategorizovány i další typy požadavků, například technologická omezení či business pravidla. Požadavek musí dle koncepce SMART být: Specifický (přesný, jasný) Měřitelný Akceptovatelný (a dosažitelný) Realizovatelný (a relevantní, tedy věcně správný) Termínovaný (a také testovatelný) Typy požadavků = typy testů Příklad Uveďte příklady k jednotlivým typům požadavků Ověřte, zda požadavky vyhovují koncepci SMART.

26 Typy testů Funkční testy Požadavek: Aplikace umožní přihlášení všem studentům na základě jejich ID a hesla. Funkční specifikace: Student zadá své ID a platné heslo, aplikace ho přihlásí. Student zadá své ID a neplatné heslo, aplikace ho nepřihlásí. Student zadá neplatné ID, aplikace ho nepřihlásí. Student zadá 3x neplatné heslo k danému ID, účet se zablokuje. Kód: public class Login { private boolean userlogin = false; private String userid = ""; private String usertype = ""; UAT: Uživatelé se přihlásí. Uživatelé zkusí použití neplatného ID nebo hesla Funkční testy: Tester zadá platné ID a platné heslo a ověří přihlášení do aplikace. Tester zadá platné ID a neplatné heslo a ověří nepřihlášení do aplikace. Tester zadá neplatné ID a ověří nepřihlášení do aplikace. Tester zadá 3x neplatné heslo k jednomu ID a ověří zablokování účtu. Unit testy Syntaxe kódu, práce s pamětí Krokování, testovací třídy

27 Typy testů Testy použitelnosti Požadavek: Podoba uživatelského rozhraní a použité barvy a fonty budou vycházet z grafického manuálu Aplikaci bude možné shodně používat na prohlížečích Internet Explorer, Mozilla Firefox a Google Chrome. K aplikaci bude dodána uživatelská dokumentace popisující veškerou funkcionalitu. V aplikaci bude dostupná kontextová nápověda. Testy: Podoba uživatelského rozhraní a použité barvy a fonty vychází z grafického manuálu Aplikaci je možné shodně používat na prohlížečích Internet Explorer, Mozilla Firefox a Google Chrome. K aplikaci byla dodána uživatelská dokumentace popisující veškerou funkcionalitu. V aplikaci je dostupná kontextová nápověda.

28 Typy testů Testy spolehlivosti Požadavek: Aplikace bude dostupná 99,5 % času. Neplánovaný výpadek nebude v 95 % případů delší než 10 minut. Plánované odstávky budou realizovány v nočních hodinách, budou schvalovány s předstihem min. 2 týdny a trváním nepřesáhnou 5 hodin. Při běžném provozu se vyskytne maximálně 100 nechtěných ukončení uživatelských session denně. Požadavky na spolehlivost jsou použity při formování SLA pro provoz. Stress testy: Postupné zvyšování zátěže systému za účelem nalezení hranice spolehlivosti a ověření chování systému po jejím překročení. Výkonnostní testy: V průběhu výkonnostních testů se sleduje nejen doba odezvy, ale i její správnost. Monitoruje se využití a uvolňování HW prostředků. Provoz: Monitoring dostupnosti aplikace. Sledování hlášených chyb.

29 Typy testů Výkonnostní testy Požadavek: Aplikace poskytne na všechny mimo vyjmenovaných funkčností odezvu do 5 sec. při 1000 přihlášených uživatelích pracujících rychlostí 1 požadavku každé 3 sec. Ve špičce aplikace poskytne na všechny mimo vyjmenovaných funkčností odezvu do 10 sec. při 2000 přihlášených uživatelích pracujících rychlostí 1 požadavku každých 5 sec. Uvedené hodnoty se očekávají na pracovních stanic definovaného výkonu a rychlosti připojení. Výkonnostní testy: Manuální testování je téměř nerealizovatelné. Při automatizovaném testovaní je nutno zajistit realističnost zátěže. Testy jsou prováděny delší dobu za účelem sledování vývoje výkonu. Testy musí být opakovatelné za stejných podmínek za účelem zjištění dopadu změn.

30 Typy testů Testy podporovatelnosti Požadavek: Součástí dodávky bude systémová dokumentace v rozsahu: - Funkční specifikace. - Use Case a datový model. Součástí dodávky bude kompletní komentovaný zdrojový kód systému. Systém bude disponovat správou číselníků, pomocí níž bude možno upravovat existující parametry. Systém bude průběžně logovat informace o svém chodu, aby bylo v případě selhání možno detekovat jeho důvod. Architektura systému umožní budoucí rozšiřitelnost. Výkonnostní testy: Ověření dostupnosti a použitelnosti předané dokumentace. Kompilace předaného zdrojového kódu a ověření jeho chodu, ověření existence komentářů. Ověření použitelnosti správy číselníků. Ověření funkčnosti logování chodu systému. Ověření rozhraní systému a test rozšiřitelnosti.

31 Typy testů Další typy požadavků a testů Bezpečnost: Autorizace uživatelů bude využívat systém jednotného přihlášení zákazníka. Přístup do systému bude realizován pomocí protokolu SSL při použití 128bitového klíče. Operace vyjmenovaných typů budou logovány pro zajištění dohledatelnosti zodpovědného uživatele. Technologická omezení Systém bude provozován na serveru dle specifikace... Systém bude použitelný i pro stanice připojené rychlostí 64kbit/s. Testy: Ověření použití určených technologií a standardů. Testy zranitelnosti pokus o využití známých bezpečnostních mezer. Penetrační testy pokus o průnik do systému. Ověření logování. Testy instalace a odinstalace. Test použitelnosti při technologických omezeních.

32 Proces testování

33 QA v Profinitu Automatizace testování Příležitosti Opakovatelnost a konzistence testů Stejné vstupy a podmínky nezávisle 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í. Rizika Tvorba testovacích případů je drahá Automatizace vyžaduje větší pracnost přípravy, urychluje pouze opakované spouštění a vyhodnocování testů. Vyžaduje velmi technicky zkušené členy týmu Vyžaduje dobře definované a stabilní rozhraní Vyplácí se zejména u dlouhodobého vývoje. Vyplácí se pozdě, výhody automatizace v release N se vrací až v release N+1 Regresní testy mají často menší sílu než nové testy

34 QA v Profinitu Monitorování chyb a nápravních opatření Neexistuje jedna vypovídající metrika. Nízká počet chyb může indikovat nedostatečné testování a naopak. Pokrytí testy musí balancovat mezi zajištěním kvality a efektivitou. Konkrétní hodnoty obvykle nemají vypovídací schopnost, spíše je třeba sledovat jejich trendy. Chyby musí být klasifikovány dle závažnosti a priority a je nutno dohodnut jejich životní cyklus:

35 QA v Profinitu Příklady metrik Stav Počet chyb ve stavu Schválená / Otevřená / Pozastavená dle závažnosti a priority Pokrytí kódu / funkčností testy vůči plánu projektu Závažnost / Priorita A B C Celkem A B C Celkem Vývoj Počet nahlášených chyb za poslední období (očištěno o duplicitní a zamítnuté) Trend počtu nahlášených chyb (očištěno o duplicitní a zamítnuté) Trend rozdílu mezi počtem nahlášených a uzavřených chyb

36 QA v Profinitu Nástroje a technologie

37 Příklady projektů QA

38 Příklady projektů QA Metodický dozor Zákazník ze státního sektoru vyvíjí aplikaci zajišťující agendu prováděnou po vstupu ČR do EU. Dodavatel systému rozumí zvolené technologii, ale nemá formalizovanou metodiku vývoje. Zákazník si zajistí dodavatele Metodického dozoru, který: Navrhne, popíše a prosadí projektovou metodiku. Prosadí rozdělení projektu do fází a definuje jejich akceptační kritéria. Formalizuje postupy projektového řízení. Navrhne šablony projektové dokumentace. Průběžně kontroluje stav projektu a navrhuje nápravná opatření. Reviduje výstupy dodavatele z pohledu QA.

39 Příklady projektů QA Metodika a automatizace testů Zákazník z bankovního sektoru dlouhodobě vyvíjí pobočkový systém. Testy prováděné dodavatelem nejsou dostatečné pro nasazování nových verzí. Pracovníci zákazníka testují nahodile, nesystémově a obvykle v časové tísni. Výsledkem je vysoká chybovost systému v produkci. V rámci projektu je dodáno: Metodika testování vycházející ze znalosti systému i procesů zákazníka, potřebného pokrytí testů i dostupných zdrojů. Návrh plánu testů a šablon testovacích podkladů. Doporučení nástroje pro automatizaci regresního testování. Pracovníci zákazníka jsou na schválenou metodiku vyškoleni. Jsou zajištěny zdroje pro požadovanou úroveň automatizace testů. Postupy a nástroje jsou v rámci pilotního releasu ověřeny.

40 Diskuze Profinit, s.r.o. Tychonova Praha 6 Tel: