Minőségmenedzsment és Informatika Test-Driven Development



Hasonló dokumentumok
extreme Programming programozástechnika

Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata

Ami a vízesésen túl van

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

Agilis projektmenedzsment

Tesztelés az XP-ben Tesztelés az XP-ben. A tesztelés kulcsjellemzői:

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI

Üzletmenet folytonosság menedzsment [BCM]

Mesterséges intelligencia alapú regressziós tesztelés

MIÉRT KELL TESZTELNI?

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

Unit Teszt. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Unit Teszt / 22

Bevezetés a programozásba

Szoftverminőségbiztosítás

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus

A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE

Teszt terv Új funkció implementációja meglévı alkalmazásba

Agilis szoftverfejlesztés és Scrum

Programrendszerek tanúsítása szoftverminőség mérése

Szoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar

TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK

(Teszt)automatizálás. Bevezető

Scrum vagy nem scrum - ahol nem hibázhatunk Röviden a budapesti fejlesztési központról

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

TOGAF elemei a gyakorlatban

Név: Neptun kód: Pontszám:

Ez idézte elı az olyan fejlesztési folyamatokat, amelyek a gyors szoftverfejlesztésre és átadásra összpontosítanak.

Szoftverminőségbiztosítás

Szoftver újrafelhasználás

01. gyakorlat - Projektalapítás

Minőségi téradat-szolgáltatások. fejlesztése és. és üzemeltetése

Cégprofil publikus CÉGPROFIL 1

Szoftverminőségbiztosítás

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK

JUnit. JUnit használata. IDE támogatás. Parancssori használat. Teszt készítése. Teszt készítése

Verifikáció és validáció Általános bevezető

A TANTÁRGY ADATLAPJA

Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.

30 MB INFORMATIKAI PROJEKTELLENŐR

Funkciópont elemzés: elmélet és gyakorlat

Automatikus tesztgenerálás modell ellenőrző segítségével

A legalacsonyabb szintű tesztelés. A programot felépítő egységek tesztelése Unit: egy rendszer legkisebb önálló egységként tesztlehető része.

Szoftverminőségbiztosítás

Webes alkalmazások fejlesztése 10. előadás. Webszolgáltatások tesztelése (ASP.NET Core) Cserép Máté

Szoftverfejlesztés teszteléssel

Fejlesztési projektek menedzselése IBM Rational CLM termékekkel. Ker-Soft Kft. Kaszás Orsolya - üzleti tanácsadó

Kríziskezelés támogatása ORACLE BI eszközzel. ELMŰ-ÉMÁSZ Nagy László

Kis-és nagyvállalatok együttműködésének előnyei és nehézségei a projektmenedzser szemével. Gyutai Balázs Loxon Tessényi András - Supercharge

Rubin SPIRIT TEST. Domino net provisioning tesztelése esettanulmány 1.0. Készítette: Dobó Arnold Jóváhagyta: Varga József. Rubin Informatikai Zrt.

Test Management Strategy Document. Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán

Projektmenedzsment a termelésben

Szoftvertesztelés - Bevezető

Szoftverminőségbiztosítás

Autóipari beágyazott rendszerek Dr. Balogh, András

Indikátorok projekt modellhelyszínein. Domokos Tamás szeptember 13.

Firmware fejlesztés. Mártonfalvi Zsolt Hardware programozó

Statikus technikák: A szoftver átvizsgálása. Statikus technikák: A szoftver átvizsgálása

Test Strategy. Tartalomjegyzék

A TANTÁRGY ADATLAPJA

A TANTÁRGY ADATLAPJA

Projekt specifikus megvalósítás I. Merre tart az informatikai Hogyan érinti ez a megvalósítást Sándor Tamás

Rendszerszemlélet let az informáci. cióbiztonsági rendszer bevezetésekor. Dr. Horváth Zsolt INFOBIZ Kft.

Programtervezés. Dr. Iványi Péter

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Web:

Agilis szoftverfejlesztés és Scrum

Információtartalom vázlata

A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

Eseményvezérelt alkalmazások fejlesztése I 11. előadás. Szoftverek tesztelése

Szoftver-technológia I.

3D számítógépes geometria és alakzatrekonstrukció

IRÁNYTŰ A SZABÁLYTENGERBEN

programozástechnika Kezdetek Fı célja 1. Kommunikáció Kezdetek - Adaptivitás

Modell alapú tesztelés: célok és lehetőségek

S01-9 Szoftverfejlesztés minőségi aspektusai

A TANTÁRGY ADATLAPJA

Miskolci Egyetem Általános Informatikai Tanszék

A tesztelés feladata. Verifikáció

A szoftver tesztelés alapjai

Menedzsment paradigmák és a virtuális vállalat. Virtuális vállalat 2012/13 1. félév 6. Előadás Dr. Kulcsár Gyula

Projektterv. Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi

Az EU 1169/2011 rendeletének hatásai, Esko szoftvermegoldások. Ratkovics Péter Partners Kft

Object Orgy PROJEKTTERV 1 (9) Adattípusok menedzselése Palatinus Endre

Informatikai projekteredmények elfogadottságának tényezői

MICROSOFT DYNAMICS NAV RENDSZER SAAS MODELLBEN

Orvostechnikai eszköz tesztelése DSS Unit test. Taliga Miklós BME-IIT

Vállalati innováció menedzsment? Szükséges ez nekünk? Kérdések, aggályok, válaszok és megoldások! jubileumi kiadványok No. 01.

Szolgáltatás Orientált Architektúra a MAVIR-nál

Univerzális munkafolyamat szimulátor

Szoftverminőségbiztosítás

Információs rendszerek Információsrendszer-fejlesztés

Feladat. Bemenő adatok. Bemenő adatfájlok elvárt formája. Berezvai Dániel 1. beadandó/4. feladat április 13. Például (bemenet/pelda.

Programfejlesztési Modellek

Projectvezetők képességei

MAGYARORSZÁG DIGITÁLIS OKTATÁSI STRATÉGIÁJA

cím: 6725 Szeged Bokor u. 18. telefon: Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: április 1-től

GEOlevel Kft. A stratégiai zajtérkép projektirányítás és minőségmenedzsment. Előadó: Szabó Richárd. Geoinformatikai és Szolgáltató Kft.

Mezőgazdasági külső információs rendszerek fejlesztése

Átírás:

Minőségmenedzsment és Informatika Test-Driven Development Varga Balázs <varga27@gmail.com> G5S8 2008.10.27

Szoftverfejlesztés jellemzői Megrendelői igények Tervezés Implementálás Tesztelés Dokumentálás Karbantartás, támogatás 2

Szoftverfejlesztés 3

Szemléletváltás Sikeresebb fejlesztés szükséges Rossz megközelítés Újabb módszertan megalkotás Következtetés, értékelés Precízebb módszertan A szoftverfejlesztés nem teljesen mérnöki folyamat A módszertanok gúzsba kötik a projektet A követelmények folyamatosan módosulnak 4

Igény a változásra.....hiszen a szoftverfejlesztés NEM gyártás Változások gyors és rugalmas adaptálása Megszabadulni a klasszikus módszertanok hibáitól Cél Minél gyorsabban Minél költséghatékonyabban Az elvárt igényt minél jobban kielégítő végeredmény 5

Agilis fejlesztés Agilitás fürgeség --> gyorsan alkalmazkodó motiváltság káosz és rend közötti egyensúly Kiáltvány az agilis szoftverfejlesztésért személyes kommunkáció <--> módszertanok működő szoftver <--> átfogó dokumentáció együttműködés <--> szerződésben foglaltak változásokra reagálás <--> tervek elfogult követése 6

Összehasonlítás a klasszikus módszertanokkal Agilis Iteratív Vízesés Adaptív (alkalmazkodó) Prediktív (előre megjósolt) Átfedés a módszerek között Iteratív használata Agilis Vízesés -szerű 7

extreme Programming Agilis szoftverfejlesztés Szakít a szoftver gyártás szemlélettel Építő elemei önszabályzó csapatmunka egyedi szakértelem együttműködés hatékony kommunikáció 8

extreme Programming Főbb jellemzői Dolgozz együtt az ügyféllel Tervezz, de ne túl előre! Rövid megbeszélések Egyszerű megoldások Strukturált fejlesztés, hisz a kód mindenkié Pár-programozás ELŐBB ÍRJ TESZTET 9

Test-Driven Development (TDD) TDD = TFD + Refacotring TFD = Test-First Development Egyéb integráció egység tesztelő keretrendszer (pl.: JUnit, NUnit, xunit) ant build (pl.: Apach Ant) Rövid leírás először teszt, azután implementálás, majd kód csiszolgatás 10

Tévhitek, félreértelmezések Tesztelés csak a tesztelőké NEM IGAZ Nem (csak) kipróbálásra szolgál, hanem a fejlesztésre Tesztesetek használata NEM feltétlen ekvivalens TDD-vel 11

Szemlélet Tesztek, tesztesetek, mint specifikáció Üres lap víziói Amíg nincs implementálva semmi, nincs elfogultság Objektív kód rálátás 12

Test-First Development 1) Teszteset írása egy funkcióhoz 2) Szintaktikai hiba feloldása 3) A tesztnek hibásan KELL fordulnia 4) Teszteset kielégítése 5) Ugrás az elejére...vége ha már nincs több teszteset 13

TFD előnyei BUG-ok számának csökkentése Kis lépésben halad A tesztek jó dokumentációk A tesztek korlátozzák az osztályt egyszerűbb kód design; csak ami kell Javítják a kódminőségét az előre írt tesztek Fejlesztés sebessége felgyorsul (globálisan) Csökkentik a félelemérzetet Szórakoztató 14

TFD hátrányai Tesztelés alapismeret hiánya megoldás: workshop, egyéni tanulás, párprogramozás Nem minden esetben írható teszt pl.: GUI fejlesztés Nagy projekt -> sok teszt -> lassan tesztel megoldás: alrendszerek tesztelése Nincs és nem lehet vagy nehézkes tesztet hozzáadni régi kód és/vagy ismeretlen érinthetetlen fekete doboz 15

Nincsen kész szoftver... Új funkciók, követelmények Adaptív viselkedés (agilitás alapelve!) Program mérete növekszik --> kevésbé átlátható Az architektúra erről nem gondoskodik Új funkciók implementálása előtt régi kód átalakítása szükséges KOCKÁZATOS MŰVELETEK!!! De van rá megoldás... 16

Refactoring Jelentése ~Átszervezés, ~átalakítás Objektum-orientált fejlesztésre, speciálisan Feladata gyorsan biztonságosan fegyelmezett módon...átláthatóvá formálni 17

Refactoring definció Szoftver belső struktúráján végrehajtott olyan módosítás, amellyel könnyebben érthetővé illetve módosíthatóvá teszi anélkül, hogy a kívülről megfigyelhető viselkedésen módosítana. 18

Gyakorlati használata Meghatározni, hol kell változtatni! elég nehéz egzakt módon mi a jó és rossz design? Segítség MARTIN FOWLER - Refactoring: Improving the Design of Existing Code (Addison Wesley, 1999) Rossz kód design-ra jellemzők összefoglalása Megoldások, refactoring algoritmusok megmutatása 19

Code smells Flower kódszagok -nak nevezi a rossz design jeleit Duplicate code Large Class Lazzy Class Large method Feature Envy... 20

Refactoring algoritmusok Extract Class Extract Method Pull up field Encapsulate Field www.refactoring.com Nagyobb IDE eszközök integrálják, automatizálják ezeket! 21

Refactoring menete Egység tesztek nélkül LEHETETLEN Test-First elven történik az átalakítás Ha valamihez nincs elég teszteset --> ki kell bővíteni Ha csak EGY teszteset elbukik, vissza kell görgetni Verzió követő rendszerek használata ajánlott 22

Refactoring Előnyök átlátható, érthető kód kis lépesek --> könnyű észrevenni a hibákat Hátrány csak lokális optimum (ld.: hegymászó algoritmus) hozott anyagból dolgozik = strukturálatlan kódból nem képes tökéletesen áttekinthető kódot varázsolni Megjegyzés Architektúrával együtt és NEM helyett használandó! 23

Test-Driven Development TDD = TFD + Refactoring TFD feladata, hogy a zöld legyen a kód Refactoring feladata, hogy strukturált legyen Egymásra épülnek Ha csak TFD volna --> csak a tesztesetek kielégítése volna a cél Refactoring, mint egy fék Így a TDD összességében tesztelt egyszerű design 24

Test-Driven Development 25

Teszt A teszt is része a programnak, vagyis strukturáltnak egyszerűnek kell lennie Technikák ObjectMother tervezési minta pl.: spec gyártófüggvények Mock ha több objektumtól függ az egység valódi objektum utánzása --> erőforrás spórolás pl.: DB kapcsolat 26

Érdekesség Concordion (www.concordion.org) nyílt forrású teszt keretrendszer Java-hoz ajánlott TDD-hez Lényege a teszt esetek megírása, a saját csomaggal HTML-ben adja a végeredményt Mely oldal tartalmazza a szóbeli leírását is a funkciónak Egyfajta élő dokumentáció 27

Statisztika 28

Összefoglalás Egy jó prediktív projekt terv szerint fog haladni, egy jó agilis projekt pedig valami jobbat és mást alkot, mint amit az eredeti terv előre meglátott. /Martin Fowler/ Test-Driven Development átlátható kód egyszerű, de mégis funkcionális védve van a hibáktól 29

Köszönöm a figyelmet! :-) Források TestDriven.com www.testdriven.com Agilis szoftverfejlesztők egyesülete www.agilealliance.hu Az Extreme Programming programozástechnikai elvei (Juhász Sándor) www.inf.unideb.hu/~fattila/hallgatoknak/dokumentumok/j uhaszs.pdf 30