Principle 7 - Exercise 1: What do you or will you do to teach other team members to test?

🙋 Questions
1

Time: 5-10 Minutes

Purpose: Principle 7 is the “everyone can test” principle, but we have an important role in helping, consulting, and coaching testing. This is an opportunity to think about how we do that.

Introduction: There are many ways to transfer skills. Pairing, for example, is one of my favorites. In order to help our teams accelerate the achievement of shippable quality, we have to help them learn to be better testers (and we have to trust their testing skills)

Activity:
List 3-5 different ways you can help your team learn more about testing.

Share your thoughts (and give feedback to others) on this thread.

2 Likes
2

I think a big step to improve testing or at least quality of testing is how steps are inputs, outputs and errors are logged.

1 Like
3

This is the course:

A person kinda has to watch this all first, so I need to engage the other topics as well still Alan.

  1. We will talk a lot about problems we face when executing a test case whenever we hit “testability” issues and start a conversation about designing apps to make testing them easier (both manually testing and automatically testing).
  2. I’ll often talk about how writing test cases to map onto requirements is often an oversimplification. Categorising tests to cover regressions requires not just for tests to map to requirements we currently have, but also that test cases need to map to component interactions and feature impacts over time, without creating duplication and management overlap. Testing is often a lot about being organized, over being complete
  3. Adding code to add a feature always injects bugs, as a tester our workload grows exponentially as features get added simply due to their interaction. Can we make architectural changes to the way we build not just our app, but also out testing work, that reduces the scale problem multipliers.
  4. Plan, plan ahead, and keep lines of communication open, not just to other teams, but also keep yourself open to new ways of testing using new tools that don’t yet exist. Plan for changes in the way that you work, changes that you dont know about yet.
  5. Less is more - just putting it out there
1 Like
4

Love that so much of the above is about communication. I continue to see pairing and collaborating kick off a lot of acceleration for teams.

1 Like
5

The “people” component of software development exists because most of the software we test is used by humans. Even though that is increasingly shrinking as api tools shrink the problem and create space for service-only or API-only products.
But even web services or apis’ are still fundamentally consumed by humans, and still going to be a risk that a human buying your weather-related web-service for example just one day changes their mind and switches vendor because of a minor pain-point that was otherwise invisible, in the mechanical mindset of api testing alone.

6

Over the years I’ve ran a number of brown bags on different aspects of testing, including those that our developers might be less familiar with (such as accessibility). More recently I’ve been involved in things like retros, RCA and also refinement and planning with each of the teams on my site, trying to share my knowledge and encourage them to actively think about testing.

Going forward I am really keen to add pairing to my toolkit as it seems really powerful. Maybe a little scary but if both me and the dev can brave it and the social anxiety, I’m confident it’ll prove very valuable!