Kategorien
Book

Book Study Group: “Agile Testing”, Chapter 4

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
  • 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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.