My First Experience of The Conference - TestBash Manchester - Part 2/3

Continuing my summary of the talks and short takeaways from TestBash Manchester.

AUT - Anxiety Under Test by Gem Hill

Gem's talk was an astonishing story of her fight with anxiety under the mental strains of being a tester and how she manages to cope. The talk touched most of the room, raising awareness, offering advice and encouraging others with mental health issues to open up and fight back. Due to the personal nature of this story it's very hard to summarize, but here are some strong quotes:

"Your brain can be unhelpful, or even outright lie!"

"Getting thoughts out in full context slows down thinking and therefore allows responding"

"Mindfulness - paying close attention to the mind and body - and focusing on thoughts can help."

"Don't give advice unless asked to - just listen"

"Be a safe person to talk to"

"It is not okay not to be okay, but also it is okay not to be okay."

TL,DR: My takeaway - It's not long, read. Otherwise "Don't give advice unless asked to - just listen".

The Lost Art of the Journeyman by Martin Hynie

In one of two talks taking very different approaches to change the perception of testing to being craftsmanship and not a commodity, Martin took us through his personal journey as a tester and how he learnt, and how he came to realize that what matters is what your skills are, what are you good at and not what others call you. To lead up to an interesting proposal, three ways of teaching were distinguished: Coaching - transferring knowledge via skills to teach; Benefaction - Helping or educationg based on a perceived potential; Mentoring - Building an organic, bi-directional relationship through teaching and going along on the journey of the mentee, with loyalty lying in the individual.

These led up to the modelled progression of Apprentice - Journeyman - Master, where education is about the craft, not the individual, a sustained effort to retain, evolve and expand knowledge. Masters, who have tremendous experience and capable of creating (or performing) a "masterpiece", would create the environment for Apprentices to learn and practice the craft, ideally under multiple Masters. After gaining enough skills, Testers would be allowed to take short contracts, trying to apply the craft to various problems, falling back to the help of masters if needed, hence becoming Journeyman. This is (clearly) not possible in the current industry, but is a very good basis for experimenting in smaller contexts (e.g. within a larger company). Martin concluded that once testers are described by the skills they possess and abilities they have (the craft), the title "Testing" would not be needed as it has a "known meaning", which is very hard to change. Instead, people should be allowed to name what testers do based on the description of their skills and abilities. TL,DR: My takeaway - Language/branding is strong, be careful with it. Focus on your skills, not your title. Experiment with the Apprenticeship model.

Turning Good Testers into Great Ones by Vera Gehlen-Baum

Vera's talk was about Metacognition - thinking about your own thinking, which is responsible for 17% of learning (e.g. intelligence is only 10%!) . Breaking it down into three concepts, each of them a 'Superhero' to be trained: Knowledge, Regulation, Monitoring. By training them, one can become a better tester.

Vera described these as the following relating each to testing: Knowledge is about the person - knowing about ourselves, the task - knowing about the task at hand and strategy - knowing how we want to perform the task. In testing this is thinking about ourselves as a tester, knowing the testing environment, charter and how to do the best testing possible.

Regulation is required during the task, during planning, and for evaluation. In testing Session - Based-testing is a good example - it requires structured, scientific thinking, a hypothesis, collecting data, using heuristics and oracles, followed by a debrief and report.

Monitoring is about reflection. Asking what did one learn, whet went well or what could be improved? In testing this can be reflecting on reports, debriefing, holding retrospective, listing areas/mistakes to avoid.

TL,DR: My takeaway - Thinking about how we think is very important. And it can be trained, but requires deliberate effort.

Who will guard the guards themselves? How to trust your automation and avoid deceit by Bas Dijkstra

Bas addressed a nagging concern/issue faced by many: The will to speed up delivery cycles via automating checks, but not having the requisite confidence in these tests. He concludes the way to our confidence that our product can perform a function is through building trust. Automation is used to help building this trust, which means that we need to trust these automated checks. However, it's very easy to lose that trust if there are: False positives - Checks that indicate failure, when there isn't one. If they happen persistently, they should be fixed or retired. If they are flaky, there are suggested ways to deal with them (e.g. Richard Bradshaw talk on Selenium Conference). Trust will build up if people see consistency.

False negatives - Checks that pass when they shouldn't. To avoid these checks should be reviewed periodically, test code should be code reviewed, and even the checks should be tested themselves For example by injecting deliberate bugs/perturbations and see if they are caught - Mutation testing, or Property-based testing where we're expressing properties of input/output data, which are then randomly generated. TL,DR: My takeaway - Don't be afraid to throw away checks. Building up trust is more important than having "more" checks. To be continued...