Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2019 09-23-snidane qa-public

40 views

Published on

Záznam odborné snídaně společnosti PROFINIT na téma testování software, quality assurance a softwarové kuchyně.

Published in: Software
  • Be the first to comment

  • Be the first to like this

2019 09-23-snidane qa-public

  1. 1. Podívejte se nám do softwarové kuchyně Bohumír Zoubek, Tomáš Mojžíš, Martin Hasaj 19. září 2019
  2. 2. 3 Série odborných snídaní › Pohled na projekty ze strany dodavatele › Připomenutí si best practices vývoje a údržby SW › Relevance a jejich zásadní význam i v dnešním „agilním světě“
  3. 3. 4 Témata 1. Odhady a práce s nimi 2. Architektura 100x jinak 3. Klíč k úspěšným projektům – zvládnuté QA
  4. 4. 5 Architektura 100x jinak 09:05 – 10:00 Pragmatický pohled na zajištění kvality a testování software Připomeňme si základní pravidla pro zajištění kvality software a podívejme se detailněji na primární i podpůrné aktivity, bez kterých se při kvalitním vývoji neobejdeme, ať dodáváme projekt agilně, iterativně nebo i jakkoliv jinak. 10:00 – 10:15 Přestávka 10:15 – 11:10 Nasazení produkční opravy do 12 vteřin? Chtěli byste to také umět? V této části se zaměříme na nasazení produkčních změn tak, aby případná chyba nezasáhla všechny zákazníky najednou a případné zotavení z chyby bylo co nejjednodušší. Dalším tématem bude také fenomén Technického dluhu a techniky, jak s ním pracovat. 11:10 – 11:30 Závěr, diskuze u kávy
  5. 5. Tomáš Mojžíš 19. září 2019 Quality assurance a testování
  6. 6. 7 KVALITA TESTOVÁNÍ QUALITY ASSURANCE Pojmy (a dojmy) ?
  7. 7. 8 Co je kvalita? › Suchá definice: Souhrn vlastností nebo charakteristik produktu či služby, které souvisí s jeho či její schopností splnit explicitně uvedené či implicitně předpokládané potřeby (ISO 8402-1986). › V podstatě to znamená mít spokojeného zákazníka/uživatele
  8. 8. 9 Co je zajištění kvality? › Aktivity s cílem zajistit kvalitu produktu či služby systematickým způsobem. › Nedokáže na 100% zajistit tvorbu kvalitního software, zvýší ale pravděpodobnost, že se tak stane. › V podstatě proaktivně děláme vše pro to, aby se minimalizovali problémy.
  9. 9. 10 Co je testování? › Aktivity s cílem změřit kvalitu dodávaného produktu nebo služby. › Simulujeme reálný provoz systému. › Ale pozor, není to pouze „proklikání aplikace“
  10. 10. 11 Proč kvalita? krátký kvíz › Druhá nejmenší › Má dva měsíce › Čtvrtá planeta sluneční soustavy
  11. 11. 12 Mars Polar Lander › 3. 1. 1999 Mys Canaveral › 3. 12. 1999 vstup do atmosféry • 40 metrů na povrchem vypnuty motory • Volný pád • Víc se neví... • Falešný signál od jedné nohy vyhodnocen jako informace o tom, že modul přistál • Chyba identifikována na 1 řádku kódu • Cena mise 327,6 mil. USD (celý Mars Surveyor ’98)
  12. 12. 13 Víc? › Mars Climate Orbiter (MCO) – metric/imperial (náklady viz MPL) › Ariane 5 – 64 floating point  16 bit signed integer (7 billion USD/10 let vývoje) › Procesor Pentium – chybný algoritmus dělení › Obranný raketový systém Patriot (28 obětí) › Disney/Lví král › Procesory Intel – chyba implementace TLB (Translation Lookaside Buffer) – dopad na výkon a bezpečnost › …
  13. 13. 14 Proč kvalita? Kvalita je finančně efektivní › Základní cena (za práci samotnou) › Cena za nízkou kvalitu – Náklady na prevenci – Náklady na posouzení/zhodnocení – Náklady na opravu chyb nalezených zákazníkem nebo při posouzení/zhodnocení › Často více než 50 % nákladů na projekt nebo produkt je důsledek nízké kvality!
  14. 14. QA v praxi
  15. 15. 16 Poznatky z praxe › QA je nutné naplánovat › Proces musí být pragmatický › O kvalitě je nutné uvažovat na všech úrovních od organizace až po jedince › Přezkoumání je efektivní (a mnohdy jediný) způsob zajištění kvality › Začínat s QA ve fázi vývoje je pozdě
  16. 16. 17 INICIALIZACE ANALÝZA DESIGN KONSTRUKCE TESTOVÁNÍ PROVOZ INICIALIZACE PROVOZ ANALÝZA DESIGNKONSTRUKCE TESTOVÁNÍ INICIALIZACE PROVOZ ANALÝZA DESIGNKONSTRUKCE TESTOVÁNÍ INICIALIZACE PROVOZ ANALÝZA DESIGNKONSTRUKCE TESTOVÁNÍ
  17. 17. 18 Co zahrnujeme do QA? › Požadované praktiky softwarového procesu › Systematický přístup k odhadování (definovaná metodika, unifikovaná, založená na best practices) › Evidence (projektů, lidí, zdrojů, znalostí, apod.) › Publikace (projektová stránka, wiki, apod.) › Revize (projektu, specifikace, architektury a designu, kódu, peer-to-peer apod.)
  18. 18. 19 QA příklady INICIALIZACE ANALÝZA DESIGN KONSTRUKCE TESTOVÁNÍ PROVOZ MINIMÁLNÍ NÁROKY / PROJEKTOVÉ REVIZE / CHECKLISTY / PROJEKTOVÁ STRÁNKA / EVIDENCE PROJEKTŮ METODIKA ODHADŮ REVIZE SPECIFIKACE REVIZE DESIGNU REVIZE KÓDU REVIZE TESTŮ PROVOZNÍ DENÍK
  19. 19. 20 Praktické doporučení › Konfigurační management - všechno máme uložené centrálně, nad vším máme kontrolu › Revize kódu (a jiné) - nepustíme si žádné záškodníky › Tracking – víme, jaké máme úkoly, chyby, kdo je řeší, kdo a zda vůbec je testuje › Spolupráce – zákazník/uživatel je s námi a testuje, nebo se spoléhá na kvalitní dodávku – nedílná součást všech agilních metodik
  20. 20. Testování
  21. 21. 22 Co je chyba? › Systém nedělá něco, co by podle specifikace vysloveně dělat měl › Systém dělá něco, co by podle specifikace vysloveně dělat neměl › Systém dělá něco, o čem se specifikace nezmiňuje › Systém nedělá něco, o čem se specifikace nezmiňuje, ale měla by se zmiňovat › Systém je obtížně srozumitelný, těžko se s ním pracuje, je pomalý › Systém je podle uživatele nepoužitelný
  22. 22. 23 Specifikace Návrh Kód Jiné Ron Patton, Testování softwaru, Cpress 2002 Kde chyby vznikají? Requirements Definition Design Build Test Operations YO! Over here!
  23. 23. 24 Náklady na odstranění chyb Specifikace Návrh Kódování Testování Provoz
  24. 24. 25 Základní principy v otázkách › Co dělat v projektu, když se zkrátí termín? › Existuje software bez chyb? › Je možné software otestovat úplně? › Odpovídá za kvalitu software pouze testovací tým? › Je práce testerů nezáživná a nekvalifikovaná? › Je vůbec potřeba testování plánovat? › Máme dostatek času a zdrojů? › Není měření průběhu a pokrytí testování zbytečná otrava? › Jak zahrnout do testování riziko? › ...
  25. 25. Trocha teorie testování
  26. 26. 27 Typy testů › Tři různé dimenze – co testujeme za konfigurační jednotku – jaký aspekt konfigurační jednotky testujeme – s jakým cílem testujeme - Unit testy - Integrační testy - Systémové testy - Akceptační testy - Uživatelské - Operační - … - Regresní testy - Kvalifikační testy - … - Funkční testy - Výkonové testy - Bezpečnostní testy - Testy dostupnosti - Testy spolehlivosti - …
  27. 27. 28 Testovací techniky Testovací techniky/paradigmata › Definuje typy testů, které jsou relevantní a zajímavé › Existuje velké množství technik, cca 150 › Překrývají se Výběr vhodné techniky › Na základě cíle testů (najít chybu, shoda se specifikací, interoperabilita, rozhodnutí o release…) › Na základě hlavní funkce (web, závory, kardiostimulátor…) › Function, Specification, Domain, Scenario, User, Stress…
  28. 28. 29 Plánování a řízení testování Plánování testů Strategie Plán Na co si dát pozor Řízení a měření Projektový management/existuje odpovědná osoba Víme, jak na tom jsme Reportujeme
  29. 29. 30 Provádění testů Test analýza a test design – Co potřebujeme? – Co vytváříme? – Na co si dát pozor Realizace – Kdy začít testovat? – Jak dlouho testovat? Defekty – Co je velká a co malá chyba? – Priorita vs. Severita – Evidence, reprodukce, fixace Náležitost Poznámka Název defektu Stručný název vystihující podstatu defektu v několika slovech. Detailní popis defektu Detailní postup, jak chybu vyvolat včetně testovacích dat. Jméno testera Jméno vývojáře který chybu opravil Stav chyby Datum vystavení chyby Datum opravení chyby Verze SW Verze SW ve které byla chyba nalezena. Verze SVN revize opravy Verze například SVN, ve které je uložen kód fixující danou chybu. Testovací prostředí Logy Screenshoty obrazovky Pouze pokud to usnadní pochopení chyby, či její nasimulování, u chyb UI povinné. Odkaz na test Odkaz na test, ve kterém byla chyba nalezena. Příčina vzniku chyby Velmi důležité pro sledování efektivity testování. Příčina neodhalení chyby vývojářem/ testerem Velmi důležité pro sledování efektivity testování. Severita Závažnost chyby typicky A - High, B - Major, C – Low. Priorita Slouží k určení priority opravy defektu vývojem. Tedy pokud z pohledu testera je defekt severity B, ale je blokující pro další testy dáme prioritu A a defekt je přednostně opraven.
  30. 30. 31 Kde testovat - testovací prostředí Produkční Dostupnost Data Změny Integrace Budoucí release VývojovéTestovací Stabilita Reputační riziko Obchodní ztráta ...existují výjimky Oddělené od produkce Oddělené od vývoje Integrované Vhodná data Pravidelná "hygiena"
  31. 31. 32 Pomůcky - SW podpora testování Co a jak testovatAutomatizace Jak to probíháPříprava dat Komunikace s okolím Měření a reportování
  32. 32. Testování pragmaticky
  33. 33. 34 Jak se pozná dobrý tester? Zvídavý Diplomatický Kreativní Analytický Perfekcionista Vytrvalý Pragmatický
  34. 34. 35 Postřehy z agilního prostředí › Kontinuální proces › Dělá se pouze co je potřeba › Testujeme každou iteraci › Kontinuální zpětná vazba › Testuje celý agilní tým › Sekvenční proces › Víc dokumentace › Testujeme po ukončení vývoje › UAT až na konci › Vývoj a testy jsou oddělené Agilní vývoj (vodopádový) vývoj Řemeslná a procesní znalost testování zůstává klíčová!
  35. 35. 36 Programátor není nepřítel aneb Posaďte je k sobě! Sdílení zkušeností Společný cíl Rychlejší opravy Vzájemné vzdělávání Lepší vztahy Méně administrativyMéně komunikačního šumu
  36. 36. 37 Automatizace testování › Proč automatizovat Opakovatelné a konzistentní › Proč neautomatizovat Drahé, technická zkušenost, stabilita okolí › Co a jak automatizovat Smoke testy, regresní testy, testování zátěže, příprava testovacích dat › Nástroje pro automatizaci Unit a integrační nástroje, statická analýza kódu, testování výkonu a zátěže, testování webů, komplexní nástroje
  37. 37. 38 R.O.B.O.T. Zdroj: www.testdevlab.com
  38. 38. 39 Shrnutí Včasné zavedení a systematické zajištění kvality šetří čas, peníze a nervy Testování nesmí být Popelkou projektu, v projektu má svoje místo
  39. 39. 40 Diskuze
  40. 40. Přestávka
  41. 41. Martin Hasaj 19. září 2019 BizDevOps
  42. 42. 43 Osnova 1. Historie BizDevOps 2. Business vs Development vs Operations 3. Je to o nástrojích 4. Je to o lidech 5. Je to o procesech 6. Co je to technický dluh a jak mu čelit
  43. 43. Historie BizDevOps 1
  44. 44. 45 Všechno to začalo… › Přirozená dělba práce – muži loví a ženy udržují oheň › Společenská dělba práce – zemědělci a pastevci › Dělba práce v pracovních operacích – se zavedením manufakturní výroby – specializace › Vždy je důraz kladen na vzájemnou komunikaci
  45. 45. 46 Jak to funguje u vás?
  46. 46. 47 Jak si myslíte, že by to mělo fungovat?
  47. 47. Business <> Development <> Operations 2
  48. 48. 49 Gartner 2015 Zdroj: Gartner, July 2015
  49. 49. 50 BizDevOps Ilustrační foto zdroj Stackify
  50. 50. 51 Role BizDevOps › Business přichází s požadavky, které potřebuje vyřešit – Schopnost konkurovat a plnit regulace – plní KPI – Co nejkratší Time-To-Market – Co nejlevněji › Development se snaží vyřešit požadavky Businessu – Co nejrobustnější řešení – Dobře udržovatelné, minimalizovat přepisování kódu – Zajímavá práce, zajímavé technologie › Operations se snaží udržet systémy v chodu – Co nejmíň změn, cílem je stabilita – Garantují SLA – musí plánovat kapacity v čase
  51. 51. 52 Kdo z vás zažil chybu v produkci?
  52. 52. 53 Byla to chyba Biz/Dev/Ops?
  53. 53. 54 BizDevOps a QA OPS BIZ DEV
  54. 54. Nástroje CI/CD 3
  55. 55. 56 Nástroje Ilustrační foto zdroj Google
  56. 56. 57 CD – Kdo z vás má E2E deployment pipeline?
  57. 57. 58 GitLab CI a CD – from idea to production
  58. 58. 59 GitLab CI/CD - stages Ilustrační foto zdroj GitLab
  59. 59. 60 GitHUB Flow Ilustrační foto zdroj GitHUB
  60. 60. 61 Azure DevOps Ilustrační foto zdroj Microsoft
  61. 61. Ukázka 1
  62. 62. 63 Virtualizace a Kontejnery Ilustrační foto zdroj Google
  63. 63. 64 Kanárci › Také se říká Dark Launching › Proč jsou a nejsou vhodní zaměstnanci? – Nulové reputační riziko – Typicky korporátní stroje, stejná síť, naučené postupy – Nemusí být vypovídající podmnožina › Je nutné správně zvolit segmentaci – musím znát uživatele › Je nutné správně zvolit velikost – pro potřeby škálování › Je nutné udržet konzistenci Front Endu
  64. 64. 65 Strategie nasazování Ilustrační foto zdroj THENEWSTACK
  65. 65. 66 Přepínače Zpřístupnění jedné funkcionality Zpřístupnění skupině lidí Ilustrační foto zdroj Google
  66. 66. 67 Chaos Monkey Ilustrační foto zdroj Netflix
  67. 67. 68 Jak dlouho trvá vám nasadit změnu na PROD?
  68. 68. Ukázka 2
  69. 69. Týmy a komunikace 4
  70. 70. 71 Conwayovo pravidlo › Společnosti vytváří organizační struktury, které zrcadlí komunikační struktury společnosti › Tyto struktury se typicky přenesou také do organizace IT vývoje a IT systémů jako takových › BizDevOps je potřeba vnímat jako transformaci společnosti jako takové, ne jenom nasazení nástrojů
  71. 71. 72 Organizace společnosti › Functional-oriented (“Optimalizace nákladů”) – Organizace lidí dle specializace BIZ / DEV / OPS – Hierarchie odpovědností – „Dělám to, protože mi to bylo nařízeno!“ › Matrix-oriented – Oddělení rolí Produktového a Organizačního managera – Sdílení zdrojů a informací napříč organizací › Market-oriented (“Optimalizace rychlosti dodávky”) – Malé týmy orientované na přidanou hodnotu pro zákazníka – Kultura odpovědnosti a důvěry
  72. 72. Procesy a Frameworky 5
  73. 73. 74 SAFe Agile framework Ilustrační foto zdroj SAFe
  74. 74. Technický dluh 6
  75. 75. 76 Nekvalitní Release Chyby na PROD Ambiciózní požadavky a nereálné sliby Zrychlený vývoj HotFixy a Patche Zrychlené testování a QA Rychlé nasazení Spirála smrti
  76. 76. 77 Technický dluh › Požadavky na vysokou obrátkovost – Nalezená chyba/Požadavek na změnu – Nasazení změny/Opravy › Entropia systému se stále zvyšuje › Typicky se šidí QA (trojúhelník Čas-Rozsah-Náklady  Kvalita) › Jak z toho ven? – Vyměnit za nový systém – technický dluh vznikne dřív než nasadíme do PROD › Pokusit se automatizovat a získat čas na QA
  77. 77. 78 Je váš tým ve spirále smrti? › Váš tým není schopný dodávat slíbené závazky načas › Nejste schopní se shodnout na nákladech a časech potřebných na implementaci mezi BIZ a DEV › Obecně jsou vnímaní náklady na dodávky jako příliš vysoké › Časté okamžité požadavky na nové funkcionality › Prioritizace všechno hned › Poddimenzované IT oddělení › Tým tráví hodně času v práci nad rámec pracovní doby
  78. 78. 79 20% DAŇ - dle The DevOps Handbook › Nebát se přistoupit k rozbitým oknům čelem – Sepsat backlog potřebných změn – Zavést automatizaci › Udržet tým kvalifikovaných odborníků znalých systémů – Doplňovat o novou krev – nové znalosti z akademické půdy › Nebát se refaktorovat a neustále vylepšovat kód › Psát automatické testy › Udržovat Code Coverage v rozumné míře › Poučit se z historie
  79. 79. Shrnutí
  80. 80. 81 Shrnutí › Kvalitu je potřeba řešit po celou dobu projektu › Bez důrazu na QA vyvíjíme metodou Code&Fix – A tak lze vyvíjet iterativně, agilně, sekvenčně… › Nástroje jsou dostupné a jejich zavedení je stále jednodušší › Podceněné QA se vždy vymstí
  81. 81. Zdroj: Steve McConnell - Software Project Survival Guide (Developer Best Practices)
  82. 82. Zdroj: Steve McConnell - Software Project Survival Guide (Developer Best Practices)
  83. 83. Zdroj: Steve McConnell - Software Project Survival Guide (Developer Best Practices)
  84. 84. Zdroj: Steve McConnell - Software Project Survival Guide (Developer Best Practices)
  85. 85. 86 Diskuze
  86. 86. Profinit EU, s.r.o. Tychonova 2, 160 00 Praha 6 | Telefon + 420 224 316 016 Web www.profinit.eu LinkedIn linkedin.com/company/profinit Twitter twitter.com/Profinit_EU Facebook facebook.com/Profinit.EU Youtube Profinit EU Děkujeme za pozornost

×