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.

"... 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.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/

Teams #3 - Selvledelse

Selvledelse er i følge Det nationale kompetenceregnskab (s.12) en kompetence baseret på

"...evne og vilje til via eget initiativ at beslutte og gennemføre opgaver i
arbejdet i overensstemmelse med virksomhedens strategier."

Selvom definitionen er lidt stiv, så kan jeg godt lide dens fokus på, at det både er et spørgsmål om evne og vilje. Selvledelse kommer ikke af sig selv. Det er en kompetence, som individerne på et givent team skal opøve og ikke mindst ville.

Det enkelte individ skal være indstillet på at bryde med vaner og hele tiden udfordre sig selv og sit eget standpunkt, men samtidig også turde stille samme krav til andre. Det kræver både evne og vilje. Først når alle på et team gør det, vil teamet blive reelt selvledende og selvorganiserende.

Som leder er dit job, som jeg ser det, at opstille de rigtige rammer for ovennævnte kan ske. Ledelsesarbejde skal baseres på

• tillid fremfor kontrol
• motivation fremfor ordrer
• uddelegering af ansvar fremfor uddelegering af opgaver

Der er sikkert også mange andre ting, men det er i hvert fald et godt sted at starte, og husk på, når man uddelegerer ansvaret, så kan man faktisk også tillade sig at stille spørgsmål ved planlægning og løsning af opgaver, hvis planerne skrider, for nogen har jo taget ansvar for planlægningen og løsningen. At modtage og acceptere ansvar er lig med at bevæge sig væk fra ansvarsfraskrivelse, som efter min opfattelse er det største problem ved projektledelse baseret på command-and-control tankegangen.

Jeg slutter med et godt team-citat hentet fra en fantastisk god historie om transitionen mod Agile:

"The first thing we learned was that we needed to make open and honest
commitments as a team to produce high quality software every iteration. It’s not
as easy as it sounds. You need to check your ego at the door. There are no
heroes on our team….our team is the hero. There are no goats on team…our team is the goat. We sink or swim together."

Et godt link til danske artikler om selvledelse og teams kan findes her

Teams #2 - Tillid

Hvad skaber grobunden for et velkonsolideret og high-performance team? Jeg tror, at det er det samme, som venskaber er bygget ovenpå: tillid og respekt. Tillid: at man har tillid til den andens adfærd og handlinger udføres med det bedste ønske i forhold til en selv. Respekt: at man respekterer hinanden og de forskelligheder man måtte have, og faktisk bruger respekten til at lære hinanden noget nyt hele tiden.

Vi har under Scrum-møder den sidste måneds tid stillet det samme spørgsmål (efter de tre andre..): Respekterer vi hinanden og hinandens forskelligheder? Det virker måske lidt too-much-agtigt og akavet, men formålet med spørgsmålet har været at bringe et konstant fokus på, at man skal se hinanden som ligeværdige i forhold til teamets mål og opgaver, og kunne stole på hinanden i forhold til, at hvis en udfører en opgave på en bestemt måde, så har andre på teamet respekt nok til at lade denne person udføre opgaven på denne måde, og ikke mindre, hvis nu opgaven er forkert udført, så har andre personer respekt nok til at turde indgå i dialog herom.

Tilliden har jeg hele tænkt som et biprodukt af fokuseringen på respekt, men efter at have læst en slide-præsentation af Diana Larsen om tillid og teams, så ser jeg nok lidt anderledes på det. Her er f.eks 21 gode tips (på engelsk) til at forbedre/skabe tilliden på ens teams:


1. Trust first—To get trust, give trust and act trustworthy
2. Set a tone for interaction and collaboration from the beginning
3. Identify clear, consistent purpose and performance goals
4. Communicate openly, freely, and honestly
5. Listen carefully and seek fairness
6. Develop comfort with discussing mistakes, concerns, and limitations
7. Respect each other’s opinions
8. Learn about each other’s perspectives
9. Establish strong business ethics
10. Visibly do what you say you’ll do
11. Interact with the team consistently and predictably
12. Decide how the team will decide
13. Take responsibility for team action
14. Give credit to team members
15. Empower team members to take risks and act
16. Make yourself available, accessible, and responsive
17. Show awareness, sensitivity, and support for the needs of other team members
18. Maintain confidences
19. Watch your language
20. Create social time for the team
21. Expect and allow emotional release, find a safe space to vent