30 Days of Testability Day 26: Relationships With Other Teams Exercise

30 Days of Testability Day 26 task is an exercise about relationships with other teams.

How well you get on with other teams that affect your team and application has a massive impact on testability. Understanding how other teams use your system, how they test the systems that integrate with yours and many more influential factors.

Goal
Determine which teams affect your testability and how you could improve relationships with those teams.

Objectives

  • Find out how many teams are connected to your team
  • Find out how those teams test the applications they are responsible for
  • Determine what actions you could take to improve those relationships

Exercise
Work with your development team to create a mind map (or list) of:

  • Teams which support your application
  • Teams which consume your application
  • What types of interactions with those teams occur (regular demo’s or shared tools for example)
  • What types of testing they perform on components linked to your application

Where the level of interaction or knowledge of how they test is low, what can you do to improve that?

Examples

I’ve adapted this Objectives to the place I work at

  • There are 3 teamsconnected to my team
  • In my work’s sctructure, my team is in charge of testing other team’s applications
  • Since I’m the nexus between all 4 teams I have to be very communicational and conciliating when there is a communicational problem.

Exercise
Work with your development team to create a mind map (or list) of:

  • Teams which support your application: Support team, supports the applications my team tests.
  • Teams which consume your application: My team is the one that consumes applications besides our clients.
  • What types of interactions with those teams occur: As for interactions, we have daily meetings, demos, sprint celebrations, reporting/fising bugs/stories in JIRA.
  • What types of testing they perform on components linked to your application: We perform regression testing, smoke testing, stress testing, among others.

When interaction or knowledge of a tester is low, I ask an experienced tester to accompany that person. We also have updated documentation on our products, which helps have a better understanding of our apps.

Was this an accurate approach of today’s item in the challenge? @heather_reid

1 Like

What a great summary :grin:

Have you ever had an experienced team member refuse to accompany someone who was less experienced? (not part of the exercise, just curious)

Yes, I have!
That’s where I as a Scrum Master, had to do my part. Explaining to that experienced person (Person A) why helping others (Person B) was a benefit for himself as well.
To which Person A stated that what he had to explain was “extremely difficult” (and it was).
So I used Einstein’s quote to try and get his attention: “if you can’t explain it simply, you don’t understand it well enough” and told him I was going to ask someone else to help person B.
Person A said there was no need of that, and was going to help Person B. Later that week, he (Person A) wrote in his weekly report that this task ended up being a challenge for him so he could proove his knowledge to me and he actually enjoyed it very much. Sometimes, touching a person’s ego gives us positive results. Right? Still…a bit risky. But it turned out to work perfectly. :sweat_smile:

1 Like

I must remember this!

1 Like

From others online: