Skrivet av Shimonu:
Fetmarkerade en intressant bit. Jag tycker man bör vara försiktig hur man formulerar sig här. Jag har stött på någon som uttalade sig som att det är testerna som bestämmer vad kraven faktiskt betyder, det var i kontext av att det fanns otydliga krav som gjorde det svårt/omöjligt att testa. Just det tankesättet håller jag verkligen inte med om. Testaren ska aldrig behöva göra någon tolkning av kraven i min mening. De ska helst vara så tydliga att det inte finns någon tvetydighet.
Idealt hade kraven varit tydliga och testbara, tyvärr är det sällan så i verkligheten, enligt min erfarenhet i alla fall. Om man då jobbar enligt TDD så blir det ju den som skriver testerna (normalt utvecklaren) som tolkar de bristfälliga kraven. Har alla koll på syftet med vad man håller på med så behöver inte det vara något större problem, men om man inte riktigt har koll så kan det förstås slå fel, men det gäller ju lika mycket för utvecklaren om man inte kör någon form av TDD.
Citat:
Vad är ert tankesätt när det kommer till testning? Personligen ställer jag in mig på att granska allting kritiskt och faktiskt försöka hitta sätt att få koden att göra något dumt eller försöka misstolka krav om det finns utrymme för det. Mitt jobb blir att försöka hitta vad andra inte tänkt på eller struntat i.
Det beror helt på vad för tester man pratar om. På mitt jobb har vi fem nivåer av tester exempelvis.
Enhetstester skrivs av utvecklaren och granskas i den vanliga kodgranskningen och så. Dessa testar ju väldigt små enheter och då behöver man ofta inte fundera så jättemycket i mina ögon. Kan man inte det, om man behöver tänka mycket och skapa upp många objekt exempelvis, så är det ett tecken på att koden borde delas upp mer. Men funktionen av enhetstester är ju mer att hålla koll på regression och att få utvecklaren att tänka till ett varv till liksom, antingen före eller efter kodningen.
På högre nivåer blir det mer black-box, man testar ur ett användarperspektiv exempelvis. Vi har haft mycket diskussioner internt om hur detta ska ske, hur testfunktionen ska se ut, ska man bara testa acceptanskriterier eller ska man göra antaganden om sånt som inte står med, och så vidare. Tidigare hade varje team en testare som framför allt skrev testfall, genomförde eventuella manuella tester och satte upp exempelvis långkörningar av systemet, men de var också delaktiga i planeringen, granskade aceptanskriterier tillsammans med resten av teamet innan vi ens tog in en feature exempelvis. Sen valde företaget att inte göra på det sättet, istället har vi ett testteam till typ 6 utvecklarteam. Diskussionerna om ansvar har fortgått dock, testteamet hinner inte med riktigt så allt mer av "deras arbete" har hamnat på utvecklingsteamen.
Mitt team exempelvis har byggt en service som kopplar upp sig mot hårdvara via en tredjepartslösning och kommunicerar med den. Teamet är nu ansvarigt att först skriva testfall för manuell testning, sen faktiskt genomföra dessa tester i labbmiljö och i slutändan automatisera dessa inklusive att skriva eventuella simulatorer och liknande som behövs för att kunna köra dessa tester helt automatiserat som en del av pipelinen.
Citat:
Vad jag har sett ibland är att man gör absolut minsta för att ha ett test som gör någorlunda vad kravet säger. Ska en funktion sätta en bit baserat på ett argument som anger position så gör man ett anrop till funktionen med en position och ser att minnet har ett värde skiljt från noll till exempel. Man verifierar aldrig att biten inte var satt från början, man gör inte test med att sätta flera bitar eller samma bit flera gånger t.ex.
Det låter som enhetstester och om man inte kontrollerar grundläget där så har man ju gjort fel i mina ögon. Ett problem är när man har olika personer som skriver acceptanskriterier som är på helt olika nivåer. Just nu har vi exempelvis tre produktägare som jobbar med/mot mitt team, en är en tidigare utvecklare som skriver väldigt tekniska och detaljerade kriterier ofta med flödesdiagram och så, mycket bra. En person kommer från liksom längre ner i stacken och har väldigt bra koll på hårdvaran som vi använder men detta spelar inte någon större roll för utvecklingen av mjukvaran i många fall. Dennas acceptanskriterier utgår mer från hur hårdvaran fungerar i detalj, vilket vi försöker abstrahera bort, så användbart ibland men inte riktigt rätt nivå ofta. Den sista personen är journalist i grunden och har jobbat med dokumentation så den skriver helt otekniska krav. I teorin ger det teamet mer frihet att lösa saker på bästa sätt själva, men samtidigt har vi ju ett team arkitekter som har en massa krav på just arkitekturen men också övriga NFR-grejer så man är ändå väldigt låst.
