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

1. Podívejte se nám
do softwarové kuchyně
Bohumír Zoubek, Tomáš Mojžíš, Martin Hasaj 19. září 2019

3. 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ě“

4. 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

5. 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

6. Tomáš Mojžíš 19. září 2019
Quality assurance a testování

7. 7
KVALITA
TESTOVÁNÍ
QUALITY
ASSURANCE
Pojmy (a dojmy)
?

8. 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

9. 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.

10. 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“

11. 11
Proč kvalita?
krátký kvíz
› Druhá nejmenší
› Má dva měsíce
› Čtvrtá planeta sluneční
soustavy

12. 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)

13. 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
› …

14. 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!

15. QA v praxi

16. 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ě

17. 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Í

18. 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.)

19. 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

20. 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

21. Testování

22. 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ý

23. 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!

24. 24
Náklady na odstranění chyb
Specifikace Návrh Kódování Testování Provoz

25. 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?
› ...

26. Trocha teorie testování

27. 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
- …

28. 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…

29. 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

30. 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.

31. 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"

32. 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í

33. Testování pragmaticky

34. 34
Jak se pozná dobrý tester?
Zvídavý Diplomatický
Kreativní Analytický
Perfekcionista Vytrvalý
Pragmatický

35. 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á!

36. 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

37. 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

38. 38
R.O.B.O.T. Zdroj: www.testdevlab.com

39. 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

40. 40
Diskuze

41. Přestávka

42. Martin Hasaj 19. září 2019
BizDevOps

43. 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

44. Historie BizDevOps
1

45. 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

46. 46
Jak to funguje u vás?

47. 47
Jak si myslíte,
že by to mělo fungovat?

48. Business <> Development <> Operations
2

49. 49
Gartner 2015
Zdroj:
Gartner, July 2015

50. 50
BizDevOps
Ilustrační foto zdroj Stackify

51. 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

52. 52
Kdo z vás zažil
chybu v produkci?

53. 53
Byla to chyba
Biz/Dev/Ops?

54. 54
BizDevOps a QA
OPS
BIZ DEV

55. Nástroje CI/CD
3

56. 56
Nástroje Ilustrační foto zdroj Google

57. 57
CD – Kdo z vás má E2E
deployment pipeline?

58. 58
GitLab CI a CD – from idea to production

59. 59
GitLab CI/CD - stages
Ilustrační foto zdroj GitLab

60. 60
GitHUB Flow
Ilustrační foto zdroj GitHUB

61. 61
Azure DevOps
Ilustrační foto zdroj Microsoft

62. Ukázka
1

63. 63
Virtualizace a Kontejnery
Ilustrační foto zdroj Google

64. 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

65. 65
Strategie nasazování Ilustrační foto zdroj THENEWSTACK

66. 66
Přepínače
Zpřístupnění jedné funkcionality Zpřístupnění skupině lidí
Ilustrační foto zdroj Google

67. 67
Chaos Monkey Ilustrační foto zdroj Netflix

68. 68
Jak dlouho trvá vám
nasadit změnu na PROD?

69. Ukázka
2

70. Týmy a komunikace
4

71. 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ů

72. 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

73. Procesy a Frameworky
5

74. 74
SAFe Agile framework Ilustrační foto zdroj SAFe

75. Technický dluh
6

76. 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

77. 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

78. 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

79. 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

80. Shrnutí

81. 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í

82. Zdroj: Steve McConnell - Software Project
Survival Guide (Developer Best Practices)

83. Zdroj: Steve McConnell - Software Project
Survival Guide (Developer Best Practices)

84. Zdroj: Steve McConnell - Software Project
Survival Guide (Developer Best Practices)

85. Zdroj: Steve McConnell - Software Project
Survival Guide (Developer Best Practices)

86. 86
Diskuze

87. 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