Fixar testaren biffen ?
När man är ute och pratar om testning på olika företag har jag märkt att testning är något som görs i slutet, strax innan produktet skall tagas i drift. Ett synonym med testning är att den också höjer kvalitén på produkten. Jag har då argumenterat att testning som en sista aktivitet innan release inte höjer kvalitén på produkten utan bara påvisar vilken kvalité eller brist på kvalité en produkt har.
Det har fått mig att tänkta på hur testning skullle höja kvalité på en produkt med så lite insats som möjligt. En produkt med hög kvalite är en produkt med få buggar, det är definitionen på kvalité i detta inlägg.
Hur kan man med enkla medel få test att bli en del av utvecklingen och inte något man gör strax innan release ?
Om man har någon form av möte där man diskuterar olika former av lösningsförslag. Det kan vara organiserat eller runt kaffemaskinen. Att bjuda in testaren till dessa möten för att diskutera lösningar på hur GUI skall fungera och hur funktionen i sig skall fungera kan vara lönande. Jag har varit med om att att utvecklare har enbart tänkt på funktion och inte tagit med användaren i beräkningarna.
Hur kommer egentligen användaren att använda systemet ?
På ett av mina tidigare konsultuppdrag så gjorde jag gjorde jag lite dumma tester som jag alltid brukar göra. Jag använde systemet som man inte skall använda system men som man kan använda systemet. Detta ledda till att hela systemet kraschade och det tog ett par timmar att återställa. Jag rapporterade detta som en defekt, men den blev en defekt som avslogs med motiveringen att "så använder man inte system". Jag lät då supporten blanda sig in i diskussionen och vi kom fram till användare gör just detta som jag gjorde och de gör det flera gånger i veckan.
Som testare kan jag vara med och diskutera hur användarna kan använda system utan att en enda rad har skrivit och kvalité har höjts. För vi vet ju att kvalité byggs, inte testas in i systemet.
Tankenöt #1
Hur många värden måste man testa med för att vara 100 % säker på att gränsen är korrekt implementerad ?
you tell me !
Skratta bäst som skrattar sist ?, eller skall jag gråta ?
Denna sammanslagning skulle ske under påskhelgen, detta ledde till Finlands största bankdebacle; Visa Electron-kort, Visakort och Eurocard/Mastercard korten slutade att fungera. Vissa kunder kunde inte betala sina räkningar, se sitt saldo osv. Tammerfors stads 1000 timanställda fick inga pengar och tvingades byta bank. Sedan dessa har problemen kommit och gått under hela våren.
Än så länge har ca 25 000 till 30 000 kunder privatkunder och hundratals företagskunder lämnat Sampo Bank. En orsaken till att det strular för Danske Bank har krupit fram, "de tog en rövare och skar ner testningen". Detta kostade dem ytterligare tiotalsu miljoner, utöver dem 200 miljoner Euro som systemet skulle kostar ifrån början.
Så förutom att det kostar 10 tusentals euro mer, så har de förlorat 25-30 tusen kunder, soo far ! Det är så skönt att veta att jobbet som testare är viktigt. Det "spara" företag massor med pengar och PR. Så skall vi testare skratta eller gråta...jag vet inte. Men glad blev jag när jag läste denna artikel så jag tror jag skrattar bäst :)
Yo Mama vs "The blame game"
Vikingen och Testaren, samma skrot och korn ???
Första erfarenheten av Exploratory Testing and Session Based Test Management
Förutom web shopen ingick också en administrationsapplikation med diverse funktioner. Applikationen skulle testat på mindre än 2.5 vecka och som vanligt finns inga direkta "kravspecifikationer" eller någon övrig dokumentation. Som testledare införde jag Session Based Test Management (SBTM) (http://www.satisfice.com/).
Efter 2 dagar hade det testats effektivt i 8 timmar och funnit 27 defekter. Den övriga tiden hade gått åt till övriga uppgifter. Efter varje session hade hölls ett kort möte, där diskussion om session gick igen. Det som jag såg som fördel med att ha dessa möten var att man fick nya idéer om hur man kunde testa.
Jag hade gjort några enkla chart för att hålla koll lite på vad som fanns att testa enligt den "mini-manulen". Efter ett par dagar testade av övrig delar av det totala systemet upptäckte jag att det var svårt att hålla reda på vilka kombination av olika användare som hade testas och vilka feature de skulle ha tillgång till. Det som jag kommer att ta med mig är att använda några test-tekniker för att hålla koll på kombinationer samt skriva ltie mer detaljerade test chart.
Testcharten kommer inte innehålla några steg utan mer "riktlinjer" som man har utvunnit ifrån de olika testteknikerna. Innan man kör igenom dessa chart så kommer jag att rekommendera lite freestyle exploratory testing för att "lära sig" systemet. Jag rekommenderar starkt att prova på lite E.T, det är stimulerade för testare som utför den, men den kan också vare jobbigt för en testare som har i flera år kört detaljerad skriptat testning utan att behöva tänka på vad han/hon gör.
