So I went to TestBash in Brighton last week and as is traditional I will now share the things I learned, plus some sketch notes I made during the day.

TALK 1: Communities of Practice

• Community of practice helps us as testers to avoid mimicry of people within our team and allows us to act more independently; whilst feeling like we have some support.
• Teams have a gestalt brain meaning they’re vulnerable to information loss if information is siloed. A community of practice helps to avoid large chunks of that brain going missing when someone joins another team / quits / gets hit by a bus /  runs away to join the circus.

TALK 2: Learning to Learn

• When learning a new subject you’re keen but unfocused which can lead you to become burned out. Focus your learning into a specialism at a time to improve your ability to learn over time.

TALK 3: Discovering Logic in Testing

• Deductive reasoning is used by many people when judging whether something is correct; something when observed either confirms or denies a logical assumption. This can be risky because any observation that runs counter to the observation can cause the pyramid of logic to collapse.
• Advanced testing techniques require leaps of faith based on abductive reasoning (like Sherlock Holmes). These leaps of faith are a jumping off point which drive learning and observations lead you to change your mind as required.

TALK 4: Experiences in Modern Testing

• Modern testers look to accelerate the team wherever they can and so are responsible for driving a whole team culture of quality. The aim of this is to prevent bottlenecks to quality due to being limited as an activity only undertaken by the testing specialist.
• Modern testers use data to help a team to drive business impact in a cycle of (Build –> Measure –> Learn –> Build). This data should show what business success looks like and can be collected from anywhere, including running production experiments to capture user feedback.
• Because Agile Teams feature generalists the modern tester is frequently called an engineer with a testing specialism in order to fit in with the other team members on a team (with a development specialism). This doesn’t mean that a tester has to become a developer or start to write code.

TALK 5: Less is More

• Different communication styles in a team can be plotted on to a quadrant matrix of Too Much vs. Too Little and For Others vs. For Yourself, the ideal communication style being in the very middle of the matrix. We should be mindful of how others perceive our communication style and balance it to meet their preference (i.e. move to the centre of the matrix).

OTHER MUSINGS FROM OTHER TALKS

• Learn the development tools! The team use these so often, why shouldn’t they be analyzed for risk or even tested?
  
• Be Kind! As testers it doesn’t take much effort to show a little empathy to our fellow team members when working with them but it has a big impact.

MY 99 SECOND TALK

As a testing community we frequently talk about having specialisms in Automation, Exploratory and other engineering concepts and nobody bats an eye; But what about having a specialism in building connections with a team or bringing people on a journey?

When’s the last time in an interview anybody asked you whether you could get on with people or how, when dropped into a new team, you’d go about getting to know team members and get them to want to work with you?

When’s the last time you said that your testing superpower was being able to make friends?