BLOG: Hvorfor ser man fra tid til anden, at udviklere sender kode videre til test-teamet uden selv at have foretaget de første simple tests? Den første test kan spare det samlede udviklingsprojekt for både tid og penge.
Jeg har ikke nogen håndfast forklaring på, hvorfor udviklere i nogle tilfælde undlader at teste koden, inden den ryger videre til de første test af funktionaliteten. Til gengæld har jeg et bud på, hvorfor det er en rigtig god ide at levere en kode til test med så god kvalitet som mulig.
Et klassisk eksempel er, at login-funktionen endnu ikke virker korrekt. Det betyder, at testeren må sende koden retur til udvikleren, fordi der ikke er adgang til de bagvedliggende dele af systemet.
Det giver unødvendigt mange udviklings-cykler, hvor koden sendes fra udvikleren til testeren og tilbage igen.
Billigst at rette fejl tidligt Det amerikanske softwarefirma, Agitar, har lavet et overslag på, hvor fejlene opstår i udviklingsprocessen, og hvor meget de koster.
Agitar vurderer, at omtrent 85 procent af softwarefejlene opstår under den første udvikling af koden. Her koster fejlrettelserne i gennemsnit 25 dollars.
På vejen videre gennem udviklings- og testfaserne stiger prisen på rettelser af fejl nærmest eksponentielt og ligger, ifølge Agitar, i omegnen af 16.000 dollars pr. fejl, når softwaren er gået i produktion.
Unittest er effektivt Softwareudviklerne kan både unit-teste og lave et gennemlæse hinandens kode. Det højner kvaliteten af koden tidligt i udviklingsprocessen.
Samtidig giver det en hurtigere produktionstid, fordi man undgår unødvendig kode-ping-pong mellem testerne og udviklerne.
Jeg snakkede en gang med en testmanager, der havde den faste politik, at hvis der ikke var dokumentation for at koden var blevet unit-testet af udvikleren, ville hun overhovedet ikke acceptere den i test.
En politik der muligvis er svær at gennemføre i praksis, men som helt sikkert vil spare en masse tid og penge.
Dokumentationen behøver jo ikke være en formfuldendt rapport, men kan blot være et dump af output, der angiver hvilket program der er kørt, hvornår, og på hvilket miljø. Det er under alle omstændigheder en god praksis at føre en sådan log af sit arbejde.
Det er åbenbart ikke alle udvikler, der besidder en professionel stolthed? Jeg sætter selv en ære i et grundigt analyse forarbejde, bl.a. hos de personer, der senere skal bruge systemet, for at sikre at det kan det brugeren forventer og kan på den konto remse flere systemer op jeg har leveret, der aldrig er blevet stillet krav til efterfølgende.
Jeg sad lige og skrev et længere indlæg, som blev spist under post. Og naturligvis virkede tilbageknappen ikke, da webudvikleren er et fjols. Den mest typiske fejl, som man ser overalt.
Jeg har arbejdet som webudvikler i 11 år for mindre virksomheder.
Yderst sjældent sammen med andre udviklere. Der har aldrig været budget til ordentlig test. Ofte er ting røget direkte i produktion uden anden test end min egen.
Hvorfor ser man fra tid til anden, at udviklere sender kode videre til test-teamet uden selv at have foretaget de første simple tests?
Hvorfor skulle udviklere nøjes med bare de simpleste tests?
Som konsulent oplever jeg oftest at jeg nærmest selv definerer kravene, hvorfor det egentligt er mig der sidder med al viden om hvordan funktionaliteten er.
Derfor har jeg accepteret at teste med ekstrem høj test-coverage i det jeg afleverer. Én fantastisk god måde at gøre det på er at udvikle test-driven.
Det virker og som en ekstra side-bonus har jeg oplevet at jeg udvikler hurtigere og ender med mindre kode.
Jeg kan varmt anbefale bogen "Test Driven: Practical TDD and Acceptance TDD for Java Developers", den dækker ALLE dele af TDD, hvor andre bøger er meget teorietiske og andre kun dækker isolerede unittests.
Kenneth Holm Nielsen skrev: Hvorfor skulle udviklere nøjes med bare de simpleste tests?
Som konsulent oplever jeg oftest at jeg nærmest selv definerer kravene, hvorfor det egentligt er mig der sidder med al viden om hvordan funktionaliteten er.
Derfor har jeg accepteret at teste med ekstrem høj test-coverage i det jeg afleverer. Én fantastisk god måde at gøre det på er at udvikle test-driven.
Det virker og som en ekstra side-bonus har jeg oplevet at jeg udvikler hurtigere og ender med mindre kode.
Fint nok, at der findes udvikler, der samtidig har overblikket ifm. seriøs test - men det er ikke generel standard med min viden. Jeg har set for meget i alt for mange år.
Skal projektet slutte i den bedre ende, så foretrækker jeg knald god udvikler og et tilsvarende testteam + QM.
Det med mange kasketter kendes i historien som lidet anbefalelsesværdigt.. gid at it-udvikling også snart vil tage det til sig.
Finn Christensen skrev: Det med mange kasketter kendes i historien som lidet anbefalelsesværdigt.. gid at it-udvikling også snart vil tage det til sig.
Helt enig, men desværre er it branchen ikke helt der endnu.
Jeg har flere gange set folk der er designere, team leaders, deployment managers og QA på samme tid, ofte uden at vide det.
Det er meget sjældent at man afsætter den tid der skal til for at teste et projekt, - heldigvis er det en naturlig af udviklingsarbejdet at man tester undervejs, - dvs. at man ikke koder videre uden at have testet den kode man allerede har lavet, - naturligvis ville det være fedt med f.eks. 2 ugers test efter man kalder projektet for færdigt, - det sker bare aldrig, - det er der ikke penge til, - tåbeligt, - men det er altså ikke "og så skal vi også lige teste" der sælger et projekt :(
Kasper Bach skrev: Det er meget sjældent at man afsætter den tid der skal til for at teste et projekt, - heldigvis er det en naturlig af udviklingsarbejdet at man tester undervejs, - dvs. at man ikke koder videre uden at have testet den kode man allerede har lavet, - naturligvis ville det være fedt med f.eks. 2 ugers test efter man kalder projektet for færdigt, - det sker bare aldrig, - det er der ikke penge til, - tåbeligt, - men det er altså ikke "og så skal vi også lige teste" der sælger et projekt :(
Nej 'test' er desværre ikke salbart - men jeg har to gange som projektleder, tvunget det igennem i en floppy organisation. Den ene gang byggede jeg testforløbet ret tidligt i projektet.. og overlod det til organisationen at finde ud af hvem der skulle lave arbejdet... den anden gang havnede jeg selv i det ifm. en konvertering af application til en anden platform, der afleverede jeg skærmprint af alle de fejl, som jeg fandt, incl. hvilke fejl jeg allerede havde rettet (ikke min opgave) - jeg blev ikke populær, men havde det selv godt med det, da kunden nu var 'oplyst'
Quality Assurance er nok noget af det mest besværglige og tunge man kan give sig i kast med. Jo, tingene skal testes, og det er hamrende irriterende når man får sig et stykke software med fejl i, men som verdenen hænger sammen nu, tror jeg ikke der er meget at gøre.
Som i siger de fleste af svarene, så er det dyrt at teste, men jeg vil gerne tilføje at det også er uhensigtsmæssigt hvis man udvikler kommercielt software. I god kode forventer man 15-50 fejl per 1000 linie kode, og i aller bedste tilfælde kan man håbe på ned til 2! Ser vi på windows XP for eksempel, så er det ca 40.000.000 liniers kode, hvilket i bedste tilfælde giver os 80.000 linier med fejl i. Tilføj så at de fleste folk absolut vil kunne sammensætte deres systemer lige som det passer dem, så er der et utal af drivere og hardware der skal snakke sammen oven i hatten.
Desværre er testing ikke bare at køre hver linie igennem. Én fejl kunne fx være at hvis du har 'calculator' åbent tre gange samtidigt, på en maskine med tysk keyboard, og så prøver på at kører en installer, så kommer der en fejl... Hvis den slags ting skal testes, så er vi vitterligt i en situation hvor der er uendelige test cases der skal testes. Godt nok er unit testing en fantastisk måde at tage det værste, og at gøre det rimeligt automatisk, men det er ikke nok til at sikre at produktet virker.
Herudover skal det siges at de fleste software virksomheder lever af at sælge deres produkt, og af at komme ud med det før konkurrenten etc. Derfor er der ikke tid til at bruge 3-4 år på at teste, i hvilket tilfælde softwaren formegentligt er forældet alligevel.
Der er også alle de sikkerhedsproblemer vi hele tiden hører om. Der skulle man tage de tests nævnt oven for, og så skal man til at gøre ting oven i, som softwaren ikke er beregnet til. Så er vi ude i uendeligt^2 test cases!
Så mens jeg er enig i at det er hamrende irriterende, så tror jeg ikke umiddelbart der er en løsning i sigte, ihvertfald ikke i større applikationer. En web applikation på et par tusinde linier bør man dog kunne teste ret godt igennem, men der vil du stadig have probemer med fx hvor vidt Java VM har problemer (og det har det), som du som udvikler ikke kan gøre ret meget ved....
Quality Assurance er nok noget af det mest besværglige og tunge man kan give sig i kast med. Jo, tingene skal testes, og det er hamrende irriterende når man får sig et stykke software med fejl i, men som verdenen hænger sammen nu, tror jeg ikke der er meget at gøre.
Som i siger de fleste af svarene, så er det dyrt at teste, men jeg vil gerne tilføje at det også er uhensigtsmæssigt hvis man udvikler kommercielt software. I god kode forventer man 15-50 fejl per 1000 linie kode, og i aller bedste tilfælde kan man håbe på ned til 2! Ser vi på windows XP for eksempel, så er det ca 40.000.000 liniers kode, hvilket i bedste tilfælde giver os 80.000 linier med fejl i. Tilføj så at de fleste folk absolut vil kunne sammensætte deres systemer lige som det passer dem, så er der et utal af drivere og hardware der skal snakke sammen oven i hatten.
Desværre er testing ikke bare at køre hver linie igennem. Én fejl kunne fx være at hvis du har 'calculator' åbent tre gange samtidigt, på en maskine med tysk keyboard, og så prøver på at kører en installer, så kommer der en fejl... Hvis den slags ting skal testes, så er vi vitterligt i en situation hvor der er uendelige test cases der skal testes. Godt nok er unit testing en fantastisk måde at tage det værste, og at gøre det rimeligt automatisk, men det er ikke nok til at sikre at produktet virker.
Herudover skal det siges at de fleste software virksomheder lever af at sælge deres produkt, og af at komme ud med det før konkurrenten etc. Derfor er der ikke tid til at bruge 3-4 år på at teste, i hvilket tilfælde softwaren formegentligt er forældet alligevel.
Der er også alle de sikkerhedsproblemer vi hele tiden hører om. Der skulle man tage de tests nævnt oven for, og så skal man til at gøre ting oven i, som softwaren ikke er beregnet til. Så er vi ude i uendeligt^2 test cases!
Så mens jeg er enig i at det er hamrende irriterende, så tror jeg ikke umiddelbart der er en løsning i sigte, ihvertfald ikke i større applikationer. En web applikation på et par tusinde linier bør man dog kunne teste ret godt igennem, men der vil du stadig have probemer med fx hvor vidt Java VM har problemer (og det har det), som du som udvikler ikke kan gøre ret meget ved....
Første punkt i artiklen han refererer til er 'Faster time-to-market'. Selvom artiklen er meget kommercielt præget og jeg ikke helt på deres undersøgelse, så har den nogle point'er.
De konkluderer at unit-testing, som er tema'et, har andre sunde effekter på projekter udover forbedret kvalitet.
Specielt i større projekter med mange tusinde linjer kode er det en fordel at have unit testing, da det formidler hensigten med koden bedre.
Det giver et sikkerhedsnet til at refactor udfra og kompleksiteten begrænses ved at kunne se en afgrænset anvendelse af koden.
Jeg er HELT enig. Unit testing er meget sundt. Det er bare ikke en cure-all løsning desværre. Men det er da et skridt på vejen =)
Kenneth Holm Nielsen skrev: Første punkt i artiklen han refererer til er 'Faster time-to-market'. Selvom artiklen er meget kommercielt præget og jeg ikke helt på deres undersøgelse, så har den nogle point'er.
De konkluderer at unit-testing, som er tema'et, har andre sunde effekter på projekter udover forbedret kvalitet.
Specielt i større projekter med mange tusinde linjer kode er det en fordel at have unit testing, da det formidler hensigten med koden bedre.
Det giver et sikkerhedsnet til at refactor udfra og kompleksiteten begrænses ved at kunne se en afgrænset anvendelse af koden.
Domæneviden står højt på ønskelisten, når virksomheder efterspørger testressourcer. Læs her hvilke andre kvalifikationer, der er efterspurgt ifølge 2010 World Quality Report
Hvem vil købe en indboforsikring, hvor dækningen er ukendt? Det er der næppe mange, der vil. Men når det handler om dækningen af softwaretest bliver test-dækning til tider katastrofalt negligeret.
Erhvervs- og Boligstyrelsen har ikke gjort softwaretest-arbejdet godt nok på hjemmesiden Boligforbedringer. Læs her hvilken simpel test-teknik, der kunne have sikret, at Søren, Jørgen og Alfons Åberg kunne sikre sig hver deres bid af puljen.
Her er syv vaner, der kan gøre dig til en bedre tester. Det er syv gode råd til, hvordan du som tester kan være med til at skabe et bedre slutprodukt i softwareudviklingsprocessen.
Christian Carlsen er testkonsulent i Sogeti. På Testbloggen skriver han om softwareudviklingens lyksagligheder og faldgrupper set fra en testers kontorstol.
Kan gratis sikkerhedssoftware virkelig beskytte din pc? Svaret er ja, hvis du vælger det rette produkt. Læs her en test af de mest pålidelige gratis sikkerhedsprogrammer.
Næsten 200 IBM-ansatte får med få timers varsel sidste arbejdsdag i dag. Ingen var orienteret forud for dagens massefyring, som effektueres øjeblikkeligt.
Flyselskabet SAS har brugt op mod trekvart milliarder kroner og seks år på at udskifte sit bookingsystem. Undervejs har der været flere projekt-udfordringer, som kulminerede en vinternat med en big bang-migrering.
Log ind
Publiceret d. 19. juni 2008 kl. 09.41
| 
