2.1.2 SDLC a osvedčené testovacie postupy Flashcards
Čo patrí medzi osvedčené testovacie postupy , nezávisle na zvolenom modeli SDLC ?
- Ku každej vývojovej činnosti existuje zodpovedajúca testovacia činnosť, takže všetky vývojové
činnosti podliehajú riadeniu kvality. - Existujú rôzne úrovne testovania (pozri kapitolu 2.2.1) a každá má svoje špecifické (a niekedy aj
odlišné) ciele. Tým je testovanie primerane detailné a zároveň nedochádza k nadbytočnostiam. - Testovacia analýza a návrh testov pre danú úroveň začína počas zodpovedajúcej vývojovej fázy
SDLC, takže je splnený princíp včasného testovania (pozri kapitolu 1.3) - V okamihu, kedy je k dispozícii pracovná verzia (draft) ľubovoľného pracovného produktu, sú do jeho
revízie zapojení testeri, čo (ako forma včasného testovania a včasnej detekcie defektov) podporuje
prístup shift-left (pozri kapitolu 2.1.5).
Aké prístupy patria k vývoju riadeného testovaním?
TDD, ATDD, BDD
Čo majú spoločné prístupy pre vývoj softvéru riadené testovaním?
TDD, ATDD a BDD sú podobné prístupy k vývoju, keď sú testy definované ako prostriedok na riadenie
vývoja.
Každý z týchto prístupov je aplikáciou princípu včasného testovania (pozri kapitolu 1.3) a uplatňuje
prístup shift-left (pozri kapitolu 2.1.5) – testy sú definované pred tvorbou samotného kódu.
Všetky podporujú iteratívny model vývoja a sú charakterizované nasledovne:
Opíš dvomi vetami Vývoj riadený testami TDD
- Písanie kódu je riadené pomocou testovacích prípadov (namiesto rozsiahleho návrhu softvéru)
(Beck, 2003). - Najprv sú spísané testy a až následne kód, a ten tak, aby týmto testom vyhovoval. Následne môžu
(ale nemusia) byť testy a kód refaktorované.
Opíš Vývoj riadený akceptačnými testami (ATDD)
- Odvodzuje testy z akceptačných kritérií ako súčasť procesu návrhu systému (Gärtner, 2012).
- Daná časť aplikácie je vytvorená tak, aby vyhovovala testom napísaným pred samotným vývojom.
Popíš prístup DevOps
DevOps je prístup k vývoju softvéru, ktorý je postavený na synergii medzi oddeleniami vývoja (vrátane
testovania) a prevádzky s cieľom dosahovania definovaných spoločných cieľov. DevOps vyžaduje zmenu
kultúry v rámci organizácie tak, aby sa medzi týmito dvoma organizačnými jednotkami preklenuli medzery
a zároveň sa k nim pristupovalo s rovnakou dôležitosťou. DevOps podporuje autonómiu tímu, rýchlu
spätnú väzbu, integrované sady nástrojov a použitie technických prístupov ako je kontinuálna integrácia
(CI – continuous integration) a kontinuálne dodávanie (CD – continuous delivery). To umožňuje tímom
vytvárať, testovať a vydávať kvalitný kód rýchlejšie prostredníctvom definovanej DevOps pipeline (Kim et
al., 2016).
Opíš vývoj riadený BDD
- Požadované správanie aplikácie je popísané testovacími prípadmi napísanými v jednoduchej
forme prirodzeného jazyka zrozumiteľného pre zainteresované strany. Obvykle je využitý formát
Given/When/Then (Daná podmienka/Podmienka/Akcia) (Chelimsky, 2010). - Testovacie prípady sú následne automaticky preložené do spustiteľných testov.
Aké má DevOps výhody z pohľadu testgovania?
- Poskytuje rýchlu spätnú väzbu o kvalite (nového) kódu a o nepriaznivom vplyve na doterajšiu
funkčnosť systému/komponenty. - Vďaka CI podporuje prístup shift-left pri testovaní (pozri kapitolu 2.1.5) tým, že motivuje vývojárov k
písaniu kvalitného kódu podporovaného testovaním komponentov a statickou analýzou. - Propaguje automatizované spracovanie (napr. CI/CD), ktoré uľahčuje vytváranie stabilných
testovacích prostredí. - Zvyšuje dôraz na nefunkcionálne charakteristiky kvality (napr. výkon alebo spoľahlivosť).
- Automatizáciou prostredníctvom pipeline znižuje potrebu opakovaného manuálneho testovania.
- Minimalizuje riziko regresie vďaka rozsahu a miere automatizovaných regresných testov.
Aké má DevOps riziká a nevýhody?
- Musí byť definovaná a zavedená DevOps pipeline.
- Musia byť zavedené a udržiavané nástroje CI/CD.
- Automatizované testy vyžadujú dodatočné investície a môže byť ťažké ich vytvoriť a udržiavať.
- Hoci DevOps predpokladá vyšší rozsah automatizovaného testovania, nemožno zabúdať ani na
manuálne testovanie, a to najmä z pohľadu koncového užívateľa
Definuj prístup shift -left
Princíp včasného testovania (pozri kapitolu 1.3) je niekedy označovaný ako shift-left (posun doľava v
zmysle časovej osi), kde je testovanie vykonávané v skorších fázach SDLC. Shift-left odporúča začať s
testovacími činnosťami skôr (napr. nečakať na implementáciu kódu alebo na integráciu komponentov), ale
neznamená to, že by testovanie v neskorších fázach malo byť zanedbávané.
Aké sú existujúce osvedčené postupy na ktorých je možné demonštrovať aplikáciu tohto prístupu?
- Revidovanie špecifikácií z pohľadu testovania, ktoré nachádza potenciálne defekty ako sú
nejednoznačnosti, neúplnosti a nezrovnalosti. - Písanie testovacích prípadov pred napísaním kódu a spustenie kódu v sade testovacieho vybavenia
(test harness) počas vývoja kódu. - Používanie CI alebo lepšie CD, pretože prichádza s rýchlou spätnou väzbou a automatizovanými
testami komponentov, ktoré sú spoločne s kódom uložené do repozitára. - Spúšťanie statickej analýzy zdrojového kódu pred dynamickým testovaním, alebo ako súčasť daného
automatizovaného procesu. - Vykonávanie nefunkcionálnych testov hneď na úrovni testovania komponentov (pokiaľ je to možné).
Ide tiež o formu shift-left princípu, pretože obvykle sú tieto typy testovania vykonávané v neskorších
fázach SDLC, keď je k dispozícii kompletný systém a zodpovedajúce testovacie prostredie.
čo može spôsobiť zavedenie prístupu shift left v počiatočných fázach ?
Zavedenie shift-left prístupu môže v počiatočných fázach znamenať potrebu preškolenia tímu, zvýšenia
prácnosti a/alebo nákladov, ale v neskorších fázach naopak šetrí vynaložené úsilie a/alebo náklady.
Je dôležité, aby boli všetci zástupcovia zainteresovaných strán presvedčení o užitočnosti tohto konceptu a
podporovali ho.
Definuj retrospektívy a zlepšovanie procesov?
Retrospektívy (známe tiež ako po-projektové schôdzky alebo projektové retrospektívy) sa často konajú
na konci projektu alebo iterácie, pri dosiahnutí míľnika alebo podľa potreby (ad-hoc). Načasovanie a
organizácia retrospektív závisí od konkrétneho modelu SDLC. Účastníci týchto schôdzok (nielen testeri,
ale aj napr. vývojári, architekti, vlastníci produktov, biznisoví analytici) obvykle preberajú:
* Čo bolo úspešné a malo by sa zachovať?
* Čo sa nepodarilo a dalo by sa zlepšiť?
* Ako implementovať návrhy na zlepšenie a zabezpečiť v budúcnosti trvalú úspešnosť?
Výstupy z retrospektív by mali byť zaznamenané, zvyčajne sú súčasťou súhrnnej správa z testovania
(pozri kapitolu 5.3.2). Retrospektívy sú z hľadiska nastavenia procesu kontinuálneho zlepšovania kritické a
je dôležité, aby boli všetky odporúčané opatrenia sledované (a dodržiavané).
Typické prínosy retrospektív?
- Zvyšovanie efektivity / účinnosti testov (napr. z dôvodu implementácie návrhov na zlepšenie
procesov). - Zvyšovanie kvality testwaru (napr. spoločnou revíziou testovacích procesov).
- Stmeľovanie tímu a vzájomné učenie (napr. ako výsledok možnosti hlásiť problémy a navrhovať
zlepšenie). - Zlepšovanie kvality testovacej bázy (napr. vyriešením nedostatkov v rozsahu a kvalite požiadaviek).
- Zlepšovanie spolupráce medzi vývojom a testovaním (napr. vďaka pravidelným revíziám a
optimalizácii vzájomnej spolupráce).
Čo je uroven testovania?
Úrovne testovania sú skupiny testovacích činností, ktoré sú organizované a riadené spoločne. Každá
úroveň testovania je inštanciou procesu testovania tvorenou činnosťami vykonávanými vo vzťahu k
softvéru v danej fáze vývoja, od jednotlivých komponentov až po celé systémy, alebo prípadne aj systémy
systémov.
