(note: indlægget her ser bort fra TDD og unit-testing, som selvfølgelig er en del af udviklernes arbejde)Vi har pt. ikke dedikerede testere tilknyttet vores projekter. Det bliver løbende et større og større problem, da det både kræver, at udviklere og product owners (vores forretningsudviklere) bruger en stor portion af deres tid på at teste.
Jeg anser det for et problem fordi
1. Udviklere er naturligt "blinde" overfor fail-scenarier. Man selv har skrevet den kode, logik og funktionalitet, som skal testes, og i mange tilfælde vil man derfor let komme til overse en række boundary cases, fordi man tænker i "positiv" scenarier i forhold til den kode, man lige har skrevet.
"... the term ‘FUT’ (frequent unit testing) for the activity of creating unit tests along with the software code, regardless of whether the tests or the code are created first. And then he goes on to say that the risk with FUT is that ‘blindness’ may prevent the developer from writing tests for
the edge cases he did not consider when coding the application.", http://www.developertesting.com/archives/month200501/20050131-BlindSpotsFrequentTestingSoftwareAgitation.html
2. Kunden/Product owner er heller ikke nødvendigvis den bedste til at optænke alle nødvendige tests. For det første er ens fokus på udvikling af en given forretning, og man har ikke nødvendigvis det kompetencesæt, som er påkrævet. Derudover har man heller ikke tid, da man jo er travlt beskæftiget med at udvikle og drifte en forretning.
I min forestilling er der behov for mindst én på et projekt, som har sit fulde fokus på softwarens kvalitet. Dette sikrer, at kvalitetsprocedurer overholdes og gør det muligt at opfange fejl/mangler tidligere i forløbet og dermed spare refaktoring-tid i en sprint.
"Being in a more detached role, sometimes the tester can see a neckbreaking hairpin curve in the road before everyone else.",
http://www.testing.com/agile/crispin-xp-article.pdfDerudover skal der være i hvert fald en i QA linieorganisationen, som har det overordnede ansvar for kompetenceudvikling og retningslinier for testere på de forskellige projekter. Det skal også være denne afdelings ansvar at sige
go eller
no-go til projekter ud fra kvalitetskravene.
På testing.com fandt jeg et ret interessant eksempel på, hvordan agile testing skal organiseres og hvorfor:
"Rather than communicating at people, we need to join and encourage the ongoing
project conversation. Testers and developers should sit in the same bullpen,
share offices, or occupy alternate cubicles. Many testers should be assigned to
help particular developers, rather than to test pieces of the product. The test
plan should evolve through a series of what James Bach calls "drop-in meetings"
- short, low-preparation, informal discussions of particular topics. These will
result in what James Tierney calls "test doclets" - short memos addressing a
specific issue. Test status should be reported via big, public, simple-to-read
charts that answer specific development questions like "what parts of the
product can we stop worrying about?", http://www.testing.com/agile/agile-testing-essay.html
Jeg kan godt lide det fokus på kommunikation, der vægtes i ovenstående citat. At testere skal assignes til at hjælpe en eller flere udviklere, istedet for at teste et eller flere områder af en applikation, virker soleklart på mig. Det drejer sig jo om at undgå distancering og ansvarsfraskrivelse i sidste ende, hvis man altså ønsker at være virkelig effektiv.
Jeg kunne godt tænke mig at høre jeres ideer til emnet, og hvis muligt høre fra nogen af jer, som har implementeret lign. i jeres organisationer.
PS: et udmærket link til udforskning af holdninger og tilgange til emnet kan findes her:
http://www.testing.com/agile/
Etiketter: organisation, teams, test
