Om bloggen
Den här bloggen är till för alla er som vill veta hur ni skall komma igång och få bättre kvalitet i era produktioner.
Den vänder sig till alla som på något sätt jobbar med IT och det spelar inte så stor roll om det är som utvecklare, projektledare, IT chef eller inköpare. Oavsett vilken roll du har så kommer du att ha nytta av den här bloggen.
Under de tio år jag jobbat med test så har jag fått mycket motstånd och det tog ganska lång tid innan jag insåg varför test har varit så svårt att implementera.
Sättet jag lärde mig testa på är anpassat till riktigt stora system där inget får gå fel, såsom banker och medicinska system. Om det fungerar med dessa system vet jag inte för jag har aldrig jobbat i den typen av projekt. Jag vet dock att ISTQB, den certifiering jag tog för många år sedan, inte längre är ett krav för testare hos t.e.x. Handelsbanken. Det är helt enkelt ett föråldrat sätt att utföra test. Även om man kan använda mycket av det jag lärde mig även i agil utveckling så är angreppssättet helt annorlunda.
Så när mina vänner med mångårig utvecklingserfarenhet talar om hur dålig erfarenhet de har av testare och testledare som satts in i deras projekt så förstår jag dem. Den här bloggen kommer att hantera en del rättmätig kritik testar- och testledarrollen fått under åren. Men jag kommer främst att ta upp hur viktigt test är för att IT-projekt skall bli framgångsrika.
Men innan jag börjar så vill jag ställa några frågor till dig som läser det här.
- Tror du att det är för dyrt att ta in personal som testar för det kan väl utvecklarna göra själva?
- Har du svårt att avgöra när systemet kommer att gå att lansera?
- Dyker fel upp först när ni lanserat systemet trots att ni tycker att ni testat allt innan det gick i drift?
- Är test något ni utför efter att ni utvecklat, strax innan ni skall lansera, programmet/systemet?
- Tror du att implementera automatiserade tester är det naturliga steget för utvecklare och på så sätt lösa alla problem? Kanske har du redan gjort det.
- Anser du att om utvecklarna är tillräckligt erfarna så behövs inga tester för då kan de förlita sig på best practice?
Svarar du ja på något av ovanstående så är den här bloggen för dig.
När man ställer krav så måste vara noggrann med att tala om vad man vill ha. Är det så enkelt? Hur kontrollerar du sen att du fått det du begärt?
Och vad är test? Är det att klicka runt lite i den senaste leveransen för att se att den fungerar?
Sanningen är nog dessvärre den att allt för många, i synnerhet de i ledningspositioner, inte har en aning om när, hur och framförallt varför, man testar. Många tror att agila tekniker, såsom Scrum, löser allt och att man därför inte behöver kunna test. Dyker det upp fel så rättar man ju till dem efter hand. Det är tyvärr en lite förenklad syn på test. Agilt arbete ger andra förutsättningar för såväl krav som test och det finns inget motsatsförhållande. Man behöver testa även när man arbetar agilt.
Krav och test är först och främst ett mindset och förhoppningsvis kommer denna blogg att få er att tänka lite annorlunda när ni utvecklar nya eller modifierar gamla system.
Jag kommer kanske att gå in lite djupare i vissa stycken men bloggens syfte är inte att göra testare/testledare av er allihop utan att ge er en förståelse för hur test och krav skall bli en naturlig del av er utveckling.