Tuesday, August 14, 2007

Regression testing

Eftersom jag arbetat de senaste 6 veckorna under uppfattningen att fas 1 av mitt nuvarande projekt inte skulle gå vidare till Quality Assurance förrens efter kodfrysningen i september kom det som något av en överaskning när jag fick nya marschorder idag. Fas 1 ska inte gå till QA innan kodfrysningen. Den ska gå till produktion. För att detta ska kunna hända måste jag ha en release klar imorgon, redo att gå in i QA i övermorgon. Eftersom jag fortfarande inte fått min beställare att godkänna skiten till att börja med så måste han godkänna det samma dag så QA testning och verifiering kan ske innan veckans slut. Det ger mig 1 dag i nästa vecka att fixa eventuella buggar och komma med en patch, för på tisdag nästa vecka måste den gå i produktion, annars är fönstret stängt till slutet på september. Det leder till:

  1. Min beställare blir sur och skäller på min projektledare
  2. Min projektledare kommer köra sin passiv-aggresiva rutin på mig
  3. Jag blir tvungen att skriva sisådär 2 kilometer SQL script för att fixa de ändringar som min uppdatering skulle gjort automatiskt.
  4. Skriva SQL i 3 dar kommer göra mig till en mycket vresig pojke.
Med dessa kittlande framtidsutsikterna i färskt minne satte jag mig med min checklista för produktion
  1. Isolera kod för release (inte gjort).
  2. Lokal "ren" check-build (inte gjort).
  3. Få ett "ok" ifrån beställaren att det jag utvecklat är det han ville ha (minsta problemet. Han vet inte vad han vill ha.).
  4. Code-review (hah, review this!).
  5. Release-build i QA miljön (hålla tummarna och hoppas att allt kompilerar).
  6. Test-plan (haha, skrev en på en post-it för en månad sen. Låt QA clownerna leka med den nöten).
  7. Regressionstester (I HATE EVERYONE)
  8. Till produktion (oh when the saints, goes marching in)
Regressionstestning är bara ytterligare en etikett på det allmänna förfarandet som icke hjärnskadade människor kallar "testa att skiten funkar". Konceptet togs fram för typ 100 år sedan av en hatfull mjukvaruutvecklare efter att hans fru lämnat honom för hans syster och tog med sig ungarna, hunden och hela samlingen av orginal Star Wars figurer, fortfarande inplastade i sina kartonger INKLUSIVE VINTAGE 1980 MINT KENNER BOBA FETT PÅ STAR WARS ESB 41 BACK 41B AFA 85 CARD. Eftersom IT-chefer kan lukta sig till självförakt och desperation på två kontinenters avstånd plockade de upp tekniken omedelbart.

Tekniken kan i princip beskrivas som "om jag målar om mitt garage, kommer ratten fortfarande funka likadant på min bil".

LOL, regression testing FAILED!!!

Men för att återgå till mig. Jag tittade över min lista, gjorde en grov tidsuppskattning i huvudet och filosoferade över varför min beställare är dum i huvet. Sen gjorde jag en lista över det också.

  1. Han skrev en gång en SQL fråga emot en tabell i en databas. Således tror han att han kan både databaser, programmering och mjukvaruutveckling.
  2. Han lever under uppfattningen att konstant ändra sig är ett tecken på att man är dynamisk, inte hysterisk.
  3. Han anser att minimal framförhållning och beslut i sista minuten betyder att man är "på bollen" och beslutsstark, inte en lallande idiot.
  4. Svara på email är ett svaghetstecken.

Mannen kommer vara vice-VD innan deceniets slut.

10 comments:

dagge said...

vi älskar sannerligen att hata mjukvaruutveckling...

Idag på KTH:
Professor: Dag, använd den här koden som vi skrev när jag var doktorand.
Dag: Ok...
Professor: Den är skriven före Fortran 77 blev standard, men den är nog ganska hygglig ändå!

Ja, du kan gissa hur kul det är med 10 000 rader legacy-kod i en pre-standarddialekt av Fortran. Hittade efter ett par försök en uppsättning växlar som gjorde att koden kompilerade. Är fortfarande osäker på om kode faktiskt räknar rätt på min burk... Problem 2: Jag skall använda subrutiner i deras kod, men arrayer i C lagras inte likadant som i F77.

Ser fram emot nästa inlägg!

Tills dess, F77:
%%%%%%
i = 1
sum = 0
10 do 20 i = 1, 50
if (i .gt. 10) goto 30
sum = sum + i
20 continue
30 if (i. le. 20) then
sum = sum - 1
goto 20
else
sum = 2*sum
endif
write(*,*) 'Sum =', sum

(inga kommentarer i koden)
%%%%%%

Odd said...

Fuling den där kodsnutten är ju snodd från nätet...

http://gershwin.ens.fr/vdaniel/Doc-Locale/Langages-Program-Scientific/Fortran/Tutorial/loops.htm

(längst ner)

Är det bara jag som får svaret: 1,71799E+11 efter lite huvudräkning?

Odd said...

Sorry, -1,71799E+11...

PAP said...

35*(2^30)

Erik said...

Vid sådana här tillfällen blir jag filosofisk över mitt val att inrikta mig på MDI: det innebär iofs att jag inte behöver utveckla mjukvara och framförallt inte samarbeta med andra som skriver kod, men å andra sidan måste jag ju förklara för vanliga människor varför saker inte fungerar...

Either way, I lose.

dagge said...
This comment has been removed by the author.
dagge said...

jo, en fuling helt klart (notera att jag inte påstod att det var ur denna kod exemplet kom). Jag satt hemma, hade inte koden framför mig och ville heller inte ge någon ögoncancer. Delar av koden jag snackade om kan man hitta på netlib

Den innehåller godbitar som:

IF(1.GT.NV) GO TO 10370
DO 550 J=1,NV
Q=(0.,0.)
IF(K1.GT.N) GO TO 10380
DO 530 I=K1,N
530 Q=Q+A(K,I)*V(I,J)
10380 CONTINUE
Q=Q/(CABS(A(K,K1))*C(K1))
IF(K1.GT.N) GO TO 10390
DO 540 I=K1,N
540 V(I,J)=V(I,J)-Q*CONJG(A(K,I))
10390 CONTINUE
550 CONTINUE
10370 CONTINUE
560 CONTINUE
10350 CONTINUE

Anonymous said...

10 REM
20 PRINT "HEJ, VAD HETER DU"
30 INPUT A$
40 PRINT "HEJ "A$"!"
50 PRINT "E DU DUM (J/N)"
60 INPUT B$
70 IF B$="N" THEN GOTO 100
80 IF B$="Y" THEN GOTO 110
90 ELSE GOTO 120
100 PRINT "DET E DU VISST "A$"!"
110 PRINT "JAG VISSTE DET! HAHAHA"
120 PRINT "DU KAN INTE SVARA KORREKT, DU E DU I HUVUDET!"
130 END

Denna kod kanske du kan ge till klåparna att köra lite QA på?!? ;)

Anonymous said...

glömde några end på slutet eller nåt

PAP said...

while (true)
{
System.out.println("Press a key to continue:");
System.in.read();
System.out.println("Wrong key. Try again.");
}

/* WORKING AS INTENDED! */