Due to COVID 19, all workshops and courses are remotely given for the foreseeable future.

Janet Gregory: Agile Consultant, Trainer, Advisor, Writer, Speaker

In my last blog post (June 2016), I talked about people’s perspective and that there is not usually only one point of view.

Let’s use that concept to our advantage in our team’s collaboration efforts. If we each can let go of our ego and be prepared to listen to other’s point of view, we may actually learn something new.

In one of my agile testing classes during a learnings discussion, one participant said “it’s about being humble – we all get to learn together on our agile journey”.  I thought that was quite profound. Being humble, letting go of what we think is the right way to do something.

In the course, one of the exercises I do is take a simple feature and have each group discuss what tests they might need to perform for that functionality. They then discuss what might be automated and map it to levels in the automation pyramid. For more information on this model, you can see Chapter 14 in Agile Testing, or Chapter 15 in More Agile Testing or you can find the basics in Mike Cohn’s post here https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid.

It is not the outcome that is the goal of this exercise, but the journey and the conversation. Getting programmers, testers, designers and even domain experts talking about testing activities and what might be automated at what level, spawns some very interesting conversations. Trade-offs are discussed – why might we automate at the unit test level vs. the API level or through the user interface. What might be best left for exploratory testing (ET)?

Transparency into what people are thinking, produces amazing ‘ah ha’ or sudden realization moments. When teams explore this type of open collaboration together, it starts to encourage trust between the team members and the different competencies so I encourage teams to use a model like the pyramid to talk about test automation and testing as a team.

The opposite is true when only some members of a team are privy to what is automated; it may lead to duplication of effort and general misunderstandings — and trust between team members will erode.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

Leave a Reply

Your email address will not be published. Required fields are marked *