Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

Copyright (c) 2005 – 2007 Cleverbee s. r. Software Quality Engineering Ing. Zdeněk Jonáš Cleverbee s.r.o.

Podobné prezentace


Prezentace na téma: "Copyright (c) 2005 – 2007 Cleverbee s. r. Software Quality Engineering Ing. Zdeněk Jonáš Cleverbee s.r.o."— Transkript prezentace:

1 Copyright (c) 2005 – 2007 Cleverbee s. r. Software Quality Engineering Ing. Zdeněk Jonáš Cleverbee s.r.o

2 Copyright (c) 2005 – 2007 Cleverbee s. r. Co nás čeká Motivace Fakta z historie Lidi v kvalitě Řízení kvality Testování software Defekty Analýzy Statistiky TMM Diskuse?

3 Copyright (c) 2005 – 2007 Cleverbee s. r. Kde nastala chyba?

4 Copyright (c) 2005 – 2007 Cleverbee s. r. Proč se zabývat ověřováním kvality Použití softwarových produktů ze zkoumaného vzorku: 2% bylo použito tak, jak byly vytvořeny 4% byly použity po mírném přepracování 19% bylo použito po zásadním přepracování 47% nebylo použito nikdy 28 % nebylo dokončeno (zdroj Borland, 2003)

5 Copyright (c) 2005 – 2007 Cleverbee s. r. Historie varuje Ve vzorku bylo zachyceno 47% defektů, které nějak souvisely (s Requirements) s požadavky Nejčastější důvody těchto chyb: Nepřesné požadavky Nesprávné požadavky Zapomenutý návrh či implementace požadavků Pozdě zachycený, navržený či implementovaný požadavek Rozporuplné (nekonzistentní) požadavky Neshoda ve vyjadřování mezi zadavatelem a tvůrcem a tím nepochopení požadavků (zdroj Borland, 2003)

6 Copyright (c) 2005 – 2007 Cleverbee s. r. Výsledky jiného průzkumu 8000 projektů, realizovaných 350 americkými firmami 33% projektů nedokončeno 50% projektů dokončeno jinak oproti plánu (implementována pouze částečná funkcionalita, vysoce překročeny finanční náklady, závažné zpoždění apod.) Nejčastější příčiny nedodržení plánu: 13% nedostatek uživatelské spolupráce 12% nekompletní požadavky 11% změna požadavků 6% nerealistická očekávání 5% nejasné cíle a plány (zdroj Sten, 1995) (obdobné údaje ukázal výzkum ESI, 1996 – 3800 firem v 17 evropských zemích)

7 Copyright (c) 2005 – 2007 Cleverbee s. r. Kde nastala chyba?

8 Copyright (c) 2005 – 2007 Cleverbee s. r. Cena opravy v závislosti na čase nalezení chyby

9 Copyright (c) 2005 – 2007 Cleverbee s. r. Testing, quality assurance (QA), and quality engineering Software Quality Engineering Quality Assurance Testing

10 Copyright (c) 2005 – 2007 Cleverbee s. r. Role v QA a co by měli zvládat Tester Schopnost testovat do „Zlomení programu“ Umět se podívat na program pohledem zákazníka Přísné zaměření na kvalitu a detail Užitečný je takt a diplomacie Schopnost komunikace technicky i netechnickými lidmi Dobrá je předchozí zkušenost z IT a znalost vývojového procesu QA Engineer Stejné kvality jako u testera, navíc Detailní znalost vývojového procesu Plní cíle projektu i byznys plány organizace

11 Copyright (c) 2005 – 2007 Cleverbee s. r. Role v QA – QA manažer QA manažer Vše předchozí kombinovat Být familiérní v softwarovém procesu Schopen týmové práce a vedení týmu Schopnost motivace týmu a poskytovat pozitivní atmosféru Diplomat při prosazování technik pro zlepšování QA procesů Schopnost říci „NE“ managementu Schopnost přijímat a odhadovat nové uchazeče Schopnost vést jednání a schůzky

12 Copyright (c) 2005 – 2007 Cleverbee s. r. Ukázka z pohovoru – několik otázek Co je cílem testování softwaru Co je to QA (Quality Assurance) Jaká je role QA ve vývojovém procesu Definujte kvalitu software a jak jí rozumíte Vysvětlete mi rozdíl mezi verifikací a validací? Jaké druhy Testování softwaru znáte? Co by jste otestoval na webové aplikaci?... Pokud programátorů je málo, tak dobří testeři jsou ohrožený druh na vymření

13 Copyright (c) 2005 – 2007 Cleverbee s. r. Řízení kvality projektů Plánování kvality (Quality Planning) Na úrovni manažerů a vedoucích Hlavním cílem prevence defektů Zajištění kvality (Quality Assurance) Aktivity směřující k zabezpečení realizace plánů kvality Aktivity vedoucí k neustálému zlepšování kvality Kontrola kvality (Quality Control) Testování, ověřování (měření)

14 Copyright (c) 2005 – 2007 Cleverbee s. r. Plánování kvality Zejména prevence defektů Zahrnuje vhodný výběr školení zaměstnanců (i účastníku projektu) Součástí i plánování a validace firemních procesů V rámci plánování kvality je třeba identifikovat pro každý projekt vhodné normy a postupy, které jsou relevantní k danému projektu. Začlenit kvalitu přímo do vznikajících produktů Začlenit kvalitu přímo do procesů při řízení projektu Lidé, primárně odpovědní za kvalitu: Quality manager Project manager.... (celý management) Tito lidé mají největší vliv na kvalitu..

15 Copyright (c) 2005 – 2007 Cleverbee s. r. Zajištění kvality QA Konkrétní postupy pro zajištění kvality Vychází z plánů kvality pro projekt Postihuje celý životní cyklus projektu Definuje metriky kvality (Co je ještě kvalitní...) Provádí se audity kvality Zpětná analýza projektu a snaha o detekci problémů Náleží sem měření postupu na projektu a srovnávání s projektovým plánem Zpoždění samo o sobě povětšinou znamená přímé ohrožení kvality produktu

16 Copyright (c) 2005 – 2007 Cleverbee s. r. Kontrola kvality Hlavními výsledky kontroly kvality jsou Rozhodnutí o přijetí Rozhodnutí o přepracování Rozhodnutí o úpravách procesů Prostředky Testování Měření projektů Statistika Analýzy

17 Copyright (c) 2005 – 2007 Cleverbee s. r. Řízení testování na projektu

18 Copyright (c) 2005 – 2007 Cleverbee s. r. Testování softwaru

19 Copyright (c) 2005 – 2007 Cleverbee s. r. Testování Co je cílem testování? a. Ověřit zda software funguje dle návrhu? b. Ověřit zda software splňuje požadavky zákazníka?

20 Copyright (c) 2005 – 2007 Cleverbee s. r. Cíl testování Co je cílem testování? a. Ověřit zda software funguje dle návrhu? b. Ověřit zda software splňuje požadavky zákazníka? B je správně ! Proč? Od testerů většinou očekáváme seznam chyb. Je to správně? NE! Primárně chceme vyjádření: zda hotový produkt splňuje požadavky zákazníka Nalezené chyby jsou sekundárním výstupem testování (avšak neméně důležité) Testování pouze proti modelu může ověřit, že zákazník dostane správně fungující software, který nechtěl

21 Copyright (c) 2005 – 2007 Cleverbee s. r. Řízení kvality na projektu

22 Copyright (c) 2005 – 2007 Cleverbee s. r. Prevence chyb – validace požadavků Požadavky Funkční (Functional) Mimo funkční (Non-functional) Alfa a omega kvality Je nutné mít kvalitně zachycené požadavky Požadavky typu: Systém poskytne přiměřenou odezvu při přeměřené zátěži. Synchronizace uživatelů proběhne přes noc (toto jsem viděl u systému provozovaném mezinárodně)

23 Copyright (c) 2005 – 2007 Cleverbee s. r. Úrovně ověření kvality Validace: zda to, co zákazník chce, též skutečně potřebuje zda stanovené požadavky na kvalitu produktu skutečně dokáží naplnit potřeby zákazníka Verifikace: zda návrh řešení splňuje požadavky na kvalitu zda implementace (a nasazení) jsou provedeny dle návrhu produktu (a návrhu jeho nasazení) Doporučená literatura Ian Sommerville: Software Engineering Ian Sommerville & Pete Sawyer: Requirements Engineering – A Good practice guide

24 Copyright (c) 2005 – 2007 Cleverbee s. r. Požadavky na požadavky Potřebnost Jednoznačnost Poskytující pouze jednu možnou interpretaci Stručnost Konzistentní Není v rozporu s jinými požadavky Kompletnost Pochopení požadavku by nemělo vyžadovat studium dalších materiálů Dosažitelnost Je realizovatelný Ověřitelnost Dosažení požadavku lze prokázat (požadavky jsou testovatelné)

25 Copyright (c) 2005 – 2007 Cleverbee s. r. Prevence chyb – Kontroly specifikací Kontroly na „zakázaná slova“ Určitě, tudíž, zřejmě, evidentně….. ve výsledků určitě ne A tak dále, jako například……. a co třeba tehdy…? Dobrý, rychlý, efektivní, laciný, stabilní……. takže pomalá líná potvora….? Ošetřeno, přeskočeno, vyloučeno….. Co všechno se skrývalo za tím, co bylo vyloučeno? Jestliže pak…. ale co když jestliže nenastane? Vždy, nikdy atd… takže zcela určitě někdy ano.

26 Copyright (c) 2005 – 2007 Cleverbee s. r. Řízení kvality na projektu

27 Copyright (c) 2005 – 2007 Cleverbee s. r. Prevence chyb – Kontrola designu Formální inspekce Autor prochází svoje dílo a vysvětluje jednotlivé návrhy Často najde chybu v momentě, kdy vysvětluji řešenou funkčnost Role: Moderátor a zapisovatel Max 3 – 4 lidi

28 Copyright (c) 2005 – 2007 Cleverbee s. r. Řízení testování na projektu

29 Copyright (c) 2005 – 2007 Cleverbee s. r. Detekce chyb – testování SW White Box Testing Ověření spustitelnosti a proveditelnosti kódu Automatizované testy (JUnit) Provádí development team Black Box Testing Kontrola shody produktu s požadavky Testy splněním Provádíme na začátku testování a v raných fázích vývoje SW Pracujeme se softwarem v rukavičkách Testy selháním Zde je snahou ověřit, zda software je dostatečně robustní proti uživatelům Program nesmí končit takovou chybou – která znamená konec běhu SW

30 Copyright (c) 2005 – 2007 Cleverbee s. r. Nelze otestovat vše Literatura o testování uvádí náročnost testování 30 – 50 % celkových nákladů na tvorbu a nasazení produktu a ani při takové podpoře testování není možno provést komplexní testování, je tedy nutno: Vhodně vybrat zaměření testování Nepodceňovat přípravu testování Zvýšit produktivitu testování vhodnými nástroji a metodikou Zvýšit produktivitu testování trasováním potřeb zákazníka a požadavků na kvalitu celým životním cyklem tvorby SW

31 Copyright (c) 2005 – 2007 Cleverbee s. r. Prokázání bezchybnosti - není možné Testování může prokázat přítomnost chyb - nikoliv bezchybnost Na lécích se dnes už neuvádí: „nemá vedlejší účinky“ ale „vedlejší účinky nejsou známy“ Chyba nemusí být zachycena hned napoprvé Spoléhat na jedinou iteraci testů – kritické riziko Toto riziko navíc zvětší: Nedostatečné specifikace produktu Nepředávání informací Nízká spolupráce v rámci týmu Neporozumění potřebám zákazníka (tím i zanesení chyb v dalších fázích) Neprovedená validace produktu

32 Copyright (c) 2005 – 2007 Cleverbee s. r. Defekty software Defekt: rozdíl v chování aplikace oproti očekávanému chování aplikace Defekt je způsobený chybou Defekt může způsobit selhání systému Defekt Popíšeme Ohodnotíme Prioritizujeme

33 Copyright (c) 2005 – 2007 Cleverbee s. r. Nalezení a reportování defektů Nalezené defekty reportujeme do Bug-Trackeru (Bugzilla, Mantis, TestTrack...) Nalezený defekt musí obsahovat: Vhodné summary Popis rozdílu mezi očekávaným a skutečným chováním aplikace. Reprodukce defektu Severita (Závažnost) jak velký problém představuje defekt pro zákazníka Priorita Jak rychle bude defekt opraven

34 Copyright (c) 2005 – 2007 Cleverbee s. r. Invalid bug

35 Copyright (c) 2005 – 2007 Cleverbee s. r. Relativně dobře zadaný bug

36 Copyright (c) 2005 – 2007 Cleverbee s. r. How software developers fix defects (bugs) - QA point

37 Copyright (c) 2005 – 2007 Cleverbee s. r. Zajímavosti z testování Definovat třídy ekvivalence Chůze po straně útesu Testování stavů Kumulace chyb – jako houby, je tam jedna, někde bude další Paradox pesticidů Šedá zóna Co je a co není change request Triage Bugů

38 Copyright (c) 2005 – 2007 Cleverbee s. r. Nástroje pro testování Jmeter – performance JConsole – součásti JDK Selenium TPTP Test Maker Mercury Test Center Profilery

39 Copyright (c) 2005 – 2007 Cleverbee s. r. Měření projektů Není součástí této přednášky, pouze krátce Testovat – znamená měřit Je třeba měřit rozumné hodnoty Používat pro zpětnou kontrolu odhadů a nikoliv pro hodnocení lidí U programátorů lze například měřit počet reopenů (Znovuotevřených úkolů) U testerů může napovědět poměr relevantních a invalid bugů Pro měření je nutné stanovit předpoklady Nesdělovat konkrétní metody programátorům – přizpůsobí se (vždy najdou způsob, jak danou metriku obejít „Řekni jak mě budeš hodnotit takové dostaneš výsledky“ Výsledky sdělovat za projekt a nikoliv za lidi Před nešvary varovat obecně

40 Copyright (c) 2005 – 2007 Cleverbee s. r. Performance testy Problematika na celou přednášku, tak pouze krátce jak to děláme u nás Používáme aplikaci JMeter Měříme odezvu v závislosti na zatížení serveru uživateli Lze měřit závislost spotřeby paměti na počtu uživatelů. Pokud stoupá lineárně, máte problém

41 Copyright (c) 2005 – 2007 Cleverbee s. r. JMeter in action

42 Copyright (c) 2005 – 2007 Cleverbee s. r. Test pomocí Regulárních výrazů

43 Copyright (c) 2005 – 2007 Cleverbee s. r. JConsole

44 Copyright (c) 2005 – 2007 Cleverbee s. r. Statistika Nutné mít dostatečné množství dat Vyžaduje měření vývojového procesu Pozor na pravidlo: Existuje malá lež, velká lež a statistika Statistika může pomoci a napovědět. Plně důvěřovat je ovšem chybou. Neboť měření je nepřesné, při výpočtu mohou vzniknout chyby.

45 Copyright (c) 2005 – 2007 Cleverbee s. r. Analýza Paretova analýza Tvrdí, že 80 procent problémů je způsobeno 20 procenty příčin. Definuje nejčastější problémy uživatelů Odpoví na otázku, co opravit jako první

46 Copyright (c) 2005 – 2007 Cleverbee s. r. Princip Six Sigma Definován jako: Rozsáhlý a flexibilní systém pro dosahování, udržování a maximalizaci obchodního úspěchu, který je jednoznačně veden přesným pochopením potřeba zákazníka, disciplinovaným využitím faktů, daty, statistickou analýzou a trvalým důrazem kladeným na řízení, zdokonalování a inovaci obchodních procesů. Řada organizací hlásí po zavedení této metody úspěchy Motorola, Inc – přežila na trhu Allied Signal General Eletric Company

47 Copyright (c) 2005 – 2007 Cleverbee s. r. Sig Sigma DMAIC Define, Measure, Analyze, Improve, Control Metoda využívá bohatě statistiky Pro zájemce kniha: What You Need to Know About Six Sigma, Productivity Digest, dec 2001 Bohužel tyto metody nejsou vhodné pro malé projekty a firmy

48 Copyright (c) 2005 – 2007 Cleverbee s. r. Ishikawa a diagramy „rybích kostí“

49 Copyright (c) 2005 – 2007 Cleverbee s. r. Paradox při tvorbě SW Od mnoha IT managerů, kteří si objednají tvorbu SW uslyšíte následující: „Když kvalitní programátoři poctivě udělají pouze to, co chceme, nebude třeba žádného testování, žádných analytiků apod.“ Vzpomeňte si na statistiku Borland. To všichni mají nepoctivé a špatné programátory?

50 Copyright (c) 2005 – 2007 Cleverbee s. r. Paradox při tvorbě SW Přitom, když si nechají stavět vlastní dům, chtějí: Aby architekt nejdříve navrhnul, jak dům naplní jejich potřeby. A oprávněnost, důležitost a stav naplnění těchto potřeb sáhodlouze s architektem nad návrhem validují. Aby architekt v projektu popsal každý požadavek na to, jak má co vypadat, i jak a jaké potřebě sloužit, jakou má mít životnost apod. Toto vše pak použije jako základní materiál pro akceptaci. Aby architekt nakreslil plány a rozepsal používaný materiál (a pokud možno co nejvíce čerpal z normovaných postupů a hotových dílů). A toto předá stavebnímu dozoru, ať ověřuje, zda stavební firma použila skutečně ty správné materiály. A kromě firmy, která dům staví, přirozeně najmou stavební dozor A dům je převzat až po důkladné kolaudaci.

51 Copyright (c) 2005 – 2007 Cleverbee s. r. TMM – test maturity model Definuje stupně zralosti, které jsou dosahovány v průběhu zdokonalování procesu testování Level 1: Initial Chaotické testování zaměřené pouze na nalezení chyb Level 2: Definition Definovaný a plánovaný proces Level 3: Integration QA plně integrováno do životního cyklu vývoje software Level 4: Managment and Measurement Důkladně definováno a testování je měřitelné Level 5: Optimisation Postupné zlepšování získané na základě minulých zkušeností z projektu. Integruje všechny postupy quality engeneering. Plánování, zajištění a řízení. Zaměřuje se na prevenci defektů. Optimalizace samotného průběhu testování

52 Copyright (c) 2005 – 2007 Cleverbee s. r. A to je vše přátelé Diskuse?

53 Copyright (c) 2005 – 2007 Cleverbee s. r. Cleverbee s.r.o. Radlická 740/113d Avenir Business Park Praha 5 Tel: Fax:


Stáhnout ppt "Copyright (c) 2005 – 2007 Cleverbee s. r. Software Quality Engineering Ing. Zdeněk Jonáš Cleverbee s.r.o."

Podobné prezentace


Reklamy Google