Performance testy v době continuous delivery (ITvečer na FIT ČVUT)SmartMeter.io
Více info o zátěžovém testování na: www.smartmeter.io
Prezentace obsahuje uvedení do problematiky performance testování a tuningu výkonu (nejen) webových aplikací včetně praktické ukázky provedení performance testu.
Nastavení očekávání a předpokladů pro provedení a vyhodnocení performance testů. Životní cyklus a praktické zkušenosti s performance testy prováděnými v rámci týmu, projektu nebo jako služba na dálku.
Tipy a triky z performance testů webových aplikací – investigace a interpretace výsledků testů. Organizace v oblasti performance testingu.
Přednášeno v rámci ITvečera 11.4.2016 na FIT ČVUT
Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)Ondřej Machulda
Záznam přednášky: https://www.webexpo.cz/praha2016/prednaska/funkcni-testovani-chybejici-vrchol-pyramidy/
Automatické testování nejsou zdaleka jenom unit-testy - ty sice tvoří základ takzvané testovací pyramidy, ta by ale neměla zůstat nedostavěná. Přednáška o tom, kdy a jak se během vývoje věnovat také vyšší vrstvě testů - funkčnímu testování alias testům uživatelského rozhraní (end-to-end testům). A naopak v jakých situacích by to byla asi zbytečná práce.
Také popíši, jak vypadá náš rutinní proces psaní funkčních Selenium testů v Jobs.cz a ukáži několik nástrojů převážně (ale nejenom) pro PHP, které můžete při vytváření a spouštění funkčních testů v praxi využít a které vám celou práci mohou usnadnit.
Performance testy v době continuous delivery (ITvečer na FIT ČVUT)SmartMeter.io
Více info o zátěžovém testování na: www.smartmeter.io
Prezentace obsahuje uvedení do problematiky performance testování a tuningu výkonu (nejen) webových aplikací včetně praktické ukázky provedení performance testu.
Nastavení očekávání a předpokladů pro provedení a vyhodnocení performance testů. Životní cyklus a praktické zkušenosti s performance testy prováděnými v rámci týmu, projektu nebo jako služba na dálku.
Tipy a triky z performance testů webových aplikací – investigace a interpretace výsledků testů. Organizace v oblasti performance testingu.
Přednášeno v rámci ITvečera 11.4.2016 na FIT ČVUT
Funkční testování – chybějící vrchol pyramidy (WebExpo 2016)Ondřej Machulda
Záznam přednášky: https://www.webexpo.cz/praha2016/prednaska/funkcni-testovani-chybejici-vrchol-pyramidy/
Automatické testování nejsou zdaleka jenom unit-testy - ty sice tvoří základ takzvané testovací pyramidy, ta by ale neměla zůstat nedostavěná. Přednáška o tom, kdy a jak se během vývoje věnovat také vyšší vrstvě testů - funkčnímu testování alias testům uživatelského rozhraní (end-to-end testům). A naopak v jakých situacích by to byla asi zbytečná práce.
Také popíši, jak vypadá náš rutinní proces psaní funkčních Selenium testů v Jobs.cz a ukáži několik nástrojů převážně (ale nejenom) pro PHP, které můžete při vytváření a spouštění funkčních testů v praxi využít a které vám celou práci mohou usnadnit.
Prezentace z odborné snídaně v Profinitu 19. 6. 2018. Naše metodika přebírání systémů, jak se řídí vývojový tým pro paralelní vývoj ve staré i nové architektuře, změna architektury i přepisování aplikace za běhu, zkušenosti a ponaučení...
Vývoj na poli automatizace testování webů otevírá spousta možností, které by ještě před pár lety byly nereálné. Podíváme se na některé aktuální trendy a ukáži pár moderních technologií a služeb, které vám mohou pomoci automatizovat (a tedy urychlit, zlevnit nebo zlepšit) různé části QA procesu: visual testing, docker, web performance testing.
Slajdy o testování v Ruby on Rails prezentované na setkání příznivců Ruby on Rails 2.8.2007 v Praze.
Prezentace představuje důvody, proč je výhodné testovat, dále tipy, jak s psaním testů začít. Obsahuje také přehled základních i pokročilejších testovacích nástrojů.
Open Monday: Jak správně uspořádat uživatelské testováníH1.cz
Přednáška Davida Špinara ze série Open Monday H1.cz. Týká se uživatelských testování a ukazuje jak správně user testing uspořádat a na co nezapomenout.
Snímky k webináři:
https://www.youtube.com/watch?v=TUmi9HLRzzs&feature=youtu.be
Co vám webinář mimo jiné ukáže?
• provede vás nástrojem - seznámíte se s interface
• jak vkládat kódy
• vše co nástroj umí
• kdy, kde a jak ho použít
• best practices
Jak testovat vaše aplikace, poznatky z praxe a tipy a triky pro každého kdo chce testovat.
Předkrm před přednáškou o Codeception a jeho snadném nasazení v Atoto.cz
Reference data is something we often encounter in our projects. In our experience, it is often underestimated and does not get enough attention. In the webinar, we want to make you aware of some interesting aspects of ‘reference data’ such as how it relates to MDM, which it’s often mixed with.
Cloud in examples—(how to) benefit from modern technologies in the cloudProfinit
The world of cloud services is enormous, rapidly growing, and changing fast, so it can be challenging to choose the right service and architecture to meet your needs.
To help you better navigate the options and inspire you, we’ve made this webinar describing two practical ways to use cloud services and benefit from the out-of-the-box features and infrastructure the cloud provides.
Prezentace z odborné snídaně v Profinitu 19. 6. 2018. Naše metodika přebírání systémů, jak se řídí vývojový tým pro paralelní vývoj ve staré i nové architektuře, změna architektury i přepisování aplikace za běhu, zkušenosti a ponaučení...
Vývoj na poli automatizace testování webů otevírá spousta možností, které by ještě před pár lety byly nereálné. Podíváme se na některé aktuální trendy a ukáži pár moderních technologií a služeb, které vám mohou pomoci automatizovat (a tedy urychlit, zlevnit nebo zlepšit) různé části QA procesu: visual testing, docker, web performance testing.
Slajdy o testování v Ruby on Rails prezentované na setkání příznivců Ruby on Rails 2.8.2007 v Praze.
Prezentace představuje důvody, proč je výhodné testovat, dále tipy, jak s psaním testů začít. Obsahuje také přehled základních i pokročilejších testovacích nástrojů.
Open Monday: Jak správně uspořádat uživatelské testováníH1.cz
Přednáška Davida Špinara ze série Open Monday H1.cz. Týká se uživatelských testování a ukazuje jak správně user testing uspořádat a na co nezapomenout.
Snímky k webináři:
https://www.youtube.com/watch?v=TUmi9HLRzzs&feature=youtu.be
Co vám webinář mimo jiné ukáže?
• provede vás nástrojem - seznámíte se s interface
• jak vkládat kódy
• vše co nástroj umí
• kdy, kde a jak ho použít
• best practices
Jak testovat vaše aplikace, poznatky z praxe a tipy a triky pro každého kdo chce testovat.
Předkrm před přednáškou o Codeception a jeho snadném nasazení v Atoto.cz
Reference data is something we often encounter in our projects. In our experience, it is often underestimated and does not get enough attention. In the webinar, we want to make you aware of some interesting aspects of ‘reference data’ such as how it relates to MDM, which it’s often mixed with.
Cloud in examples—(how to) benefit from modern technologies in the cloudProfinit
The world of cloud services is enormous, rapidly growing, and changing fast, so it can be challenging to choose the right service and architecture to meet your needs.
To help you better navigate the options and inspire you, we’ve made this webinar describing two practical ways to use cloud services and benefit from the out-of-the-box features and infrastructure the cloud provides.
Building big data pipelines—lessons learnedProfinit
What is the power of business departments? What is missing in communication between layers responsible for building big data solutions? What mistakes can happen when IT departments are too proactive in creating solutions for big data?
Understand your data dependencies – Key enabler to efficient modernisation Profinit
Modernising any system is a comprehensive task. Every step has to be estimated, appropriately planned, then carefully executed and verified. Data with its dependencies are the common denominator in almost every case and crucial in understanding the whole initiative.
In this webinar, experts from Profinit and Manta will present their approach to resolving data-related challenges while modernising software systems using Profinit Modernisation Framework in collaboration with Manta tools.
Knowing your clients well and knowing when they need financial support is a key part of a bank’s success in lending. But it is challenging to gather and process information about your customers to know them all entirely. Our senior consultant Lukáš Dvořák will show you how to use data to drive your lending business and improve the conversion rate of loan offers.
What to do when a system stops providing the value that your business needs and an immediate change is necessary? Replacing such a system is usually the first idea that comes to mind. However, is it the only and the best approach you should consider? Not necessarily!
Automating Data Lakes, Data Warehouses and Data StoresProfinit
This webinar discusses automating data warehouses, lakes, and stores. It introduces the speaker, Petr Hájek, and his experience. Profinit, the company hosting the webinar, is introduced along with their competencies and certifications. The webinar then covers challenges with traditional manual approaches and how automation can help through frameworks, templates, and metadata to generate scripts. A case study of automating a data warehouse for a gambling regulator is presented, highlighting benefits like reduced time and costs. Automation is argued to make solutions more transparent, agile, and organized compared to traditional approaches.
When the complexity of all the data in your business exceeds a certain level, it is time to make a sound decision and start taking steps towards professional and systematic data governance and clear data architecture. This step is what we call “data landscape mapping”. At the end of this initial process, you will get something like a Google map of all the data in your company, visualised from different angles and dimensions.
What to do when a system stops providing the value that your business needs and an immediate change is necessary? Replacing such a system is usually the first idea that comes to mind. However, is it the only and the best approach you should consider? Not necessarily!
Profinit Webinar: Benefits of Software Systems Modernization over their Repla...Profinit
Nowadays, many companies are facing challenges linked to their core systems. The systems lack support for the new business models, do not fit-for-purpose anymore or provide poor UX. In general, they are slow to change, risky and costly to enhance and maintain. What would you do, when a system does not provide the value that your business needs? Replacing such a system is usually the first idea that comes to mind. However, is it the only approach you should consider?
In our webinar, Michal Petřík (Profinit's Head of Software Development) will discuss a different approach that is often faster, safer and better suited for many businesses.
Dominik Matula presented Instalment Detector, a tool that reveals clients' payment behaviors from transactional banking data through advanced machine learning techniques. It aims to improve risk scoring, maximize profit, and help clients save through detecting hidden loan payments. The tool engineers complex features from relationships between transactions and uses Bayesian networks to achieve a 100% boost in detecting instalment payments compared to conventional methods. The tool provides interpretable results while adapting to market changes and can be applied to other financial fields.
Prezentace z odborné snídaně v Profnitu 19. 6. 2018. Bitcoin (kryptoměny), burzy, vývoj burzy Coinmate na „zelené louce“, její další rozvoj, aktuální otázky související s boomem kryptoměn.
1. Podívejte se nám
do softwarové kuchyně
Bohumír Zoubek, Tomáš Mojžíš, Martin Hasaj 19. září 2019
2.
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
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“
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!
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.)
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
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ý
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?
› ...
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í
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
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
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
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
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
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
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
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
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í