Agile testing - hvordan skal denne disciplin organiseres??
(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.
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.pdf
Derudover 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:
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/
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 for2. 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.
the edge cases he did not consider when coding the application.", http://www.developertesting.com/archives/month200501/20050131-BlindSpotsFrequentTestingSoftwareAgitation.html
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.pdf
Derudover 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
indsendt af Rune Mai kl.
08.59
2 kommentarer:
Udviklere er ikke fødte kommunikatorere (min fejlstavning? af dette ord er måske netop en indikator for at det er sandt!)
Der er en fandens fokus på kommunikation i disse dage. Og Agile gør det bestemt ikke nemmere for nørder. Vi kan kommunikere, men vi kan bedst kommunikere (selvsagt) med de mennesker der taler vores sprog.
Det der driver en udvikler (generelt!) er ønsket om at tilfredsstille andres behov rent teknisk. Og det gælder faktisk også når vi snakker om at forklare tekniske problemstillinger -- men det er ikke altid nemt. En udvikler skal faktisk kaste sig hoved-først ud fra sin verden og ind i en "what-what-what"-verden hvor pointers, SPROCs og andet gejl ikke giver mening... det tager tid.. det kræver mental-ability... og det er i sidste ende noget der bremser produktiviteten for en udvikler -- også selvom det faktisk kan betragtes som adspredelse ;)
Godt en gammel blog-entry - havnede her ad omveje.
Hvis man ønsker litteratur om emnet kan jeg varmt anbefale: Lisa Crispin, Janet Gregory: "Agile Testing: A Practical Guide for Testers and Agile Teams" (Amazon: http://www.amazon.co.uk/Agile-Testing-Practical-Addison-Wesley-Signature/dp/0321534468).
For mig var læsningen af den nærmest som at finde "the missing link". Jeg har haft utroligt svært ved at se hvor en tester passer ind i den agile proces. Det forklarer bogen indgående.
Send en kommentar
<< Startside