Kategorie: Book

For personel interest I decided to read chapter 4 „Team Logistics“ of Agile Testing, before we decided to do so in the book study group, here is my outcome:

• Team Structure communication is critical!
  • Independent QA teams
    • lead to division between programmers & testers
    • are inefficient
    • structures & reasons should be changed
    • testers as learning CoP, QA managers as „leader“/ „teachers“
  • Integration of testers into an agile project
    • testers (also) need training -> critical/ crucial
    • programmers need training on testing (skills)
    • pairing of programmers & testers
      • improves communication
      • is efficient
    • only 1 budget/ schedule
    • -> how does this fit into a big organization with multiple scrum teams and multiple independeent QA-teams?
    • testing as part of the DoD
    • testers are full fledged team members (use retrospective to improve)
    • testing tasks are as important as all other tasks (use retrospective to improve)
    • new definition of QA & development managers to be found
  • Agile project teams
    • cross-functional, but „whole team effort“
    • build team depending on project´s needs <- refactor as needed
    • tester´s CoP, driven by QA manager
• Physical logistics
  • -> Co-location of all team members!
  • support communication of distributed teams (phone, webcam, instant messaging, …)
• Resources
  • tester-developer ratio
    it depends… on
    • complexity of the AUT
    • skillset of the tester
    • used tools
    • -> number of test taks taken by programmers (?)
  • focus on skills instead of ratio
  • use retrospectives to find out if hiring a tester would solve the problem (!)
• Hiring an agile tester
  • Very similiar article online: http://lisacrispin.com/downloads/HiringAgileTester.pdf
  • most important: does person fit into team
  • „hire for attitude“ (not skills)
• Building a team
  • self-organizing team: team can identify & solve problems on their own -> best progress
  • involving other teams: bring teams together, so they can learn from each other
  • performance and rewards
    • measuring & rating individual performance risks undermining team collaboration
    • good performance shouldn´t be victimized if team doesn´t perform well
    • don´t blame the tester if a bug gets discovered in production
  • set goals which
    • serve business
    • increase profibility
    • make customers happy
    • -> generalized(?): which add value?
  • celebrate success
  • What can you do?
    • get team principles from chapter 2 to work
    • communication
    • feedback