On the 19th October, 2018 I attended TestBash Sydney, the first time this event has come to Australia. I spoke on “Advocating for Quality by turning developers into Quality Champions”. I’ll share some more on that topic in a different post, and instead focus this post series on what I got out of the other talks presented that day.
These are the things that stood out to me, my own reflections and some paraphrasing of content, to help share the lessons with others.
Next Level Teamwork: Pairing and Mobbing
- Things are better together!
- When we pair or mob test on one computer, we all bring our different views and knowledge to the table.
- With mob programming, only the best of the whole group goes into the code, rather than one person giving their best and worst.
- Plus, we get those “how did you do that!” moments for sharing knowledge.
- Experts aren’t the ones who know the most, but who learn the fastest.
- Traditional pairing is one watching what the other is doing, double checking everything. This is boring for the observer. “I’ve got an idea, give me the keyboard!” mentality.
- You should keep rotating the keyboard every 2-4 minutes to keep everyone engaged.
- Strong-style pairing shifts the focus, to a “I’ve got an idea, you take the keyboard” mentality, where you explain the idea to the other person and get them to try it out.
- You are reviewing what is happening with what you want to happen, rather than guessing someone else’s mindset.
- It can be hard to pair when skillsets are unequal, eg a developer and a tester, feeling that you are slowing them down or forcing them into things they don’t want to do. Strong-style pairing helps with this.
- Some pairing pitfalls
- Hijacking the sessions. Only doing what one person wants to try, or not getting the point
- Giving up to impatience. Don’t see the value, but persist anyway.
- Working with ‘them’. Pairing with an uncomfortable person, maybe use mob over pairing for this.
- In Agile Conf 2011, an 11 year old girl was able to participate in a mob session by stating her intent, and having others follow that through, and by listening to others and doing what they said to do.
- Mobbing basics:
- Driver (no thinking). Instruct them by giving “Intent -> Location -> Details”
- Designated navigator, to make decisions on behalf of group.
- Conduct a retrospective.
- Typically use 6-8 people, but if everyone is contributing or learning, it’s the right size.
- Need people similar enough to get along, but diverse enough to bring different ideas.
- I might have a good idea, but don’t know how to code/test it.
We use pairing at work a lot already, and I didn’t really learn anything new to introduce here. Mobbing doesn’t really appeal to me, for it to be beneficial, you have to justify the time spent of a whole group working on 1 task, which to me, only works when the work produced by individuals is far inferior. Mobbing should produce a better outcome, but it will be quite slow, and we get most of the way there by reviewing people’s code to get a solid overall solution.
Well presented, but I can’t see mobbing working outside of some particular scenarios.
How Automated E2E Testing Enables a Consistently Great User Experience on an Ever Changing WordPress.com
Note: A full transcript of Alister’s talk, including slides, is available on his website.
I didn’t really understand the start of Alister’s talk about hobbies or why it was included. It finished with the phrase: “Problems don’t stop, they get exchanged or upgraded into new problems. Happiness comes from solving problems”. This seems to be what the introduction was getting at. The rest of the talk then followed a pattern of presenting a problem around automation, a solution to the problem, and the problem that came out of the solution, and then the next solution, and so on.
- Problem: Customer flows were breaking in production (They were dogfooding, but this didn’t include Signup)
- Solution: Automated e2e test of signup in production
- P: Non-deterministic tests due to A/B tests on signup
- S: Override A/B test during testing
- Including a bot to detect new A/B tests in the PR, with a prompt to update e2e tests
- P: Too slow, too late, too hidden (since running in prod)
- S: Parallel tests, canaries on merge before prod, direct pings
- P: Still have to revert merges, slow local runs (parallel only in docker)
- S: Live branch tests with canaries on every PR
- P: Canaries don’t find all the problems (want to find before prod)
- S: (Optional) Live branch full suite tests (use for large changes via a github label)
- P: IE11 & Safari 10 issues
- S: IE11 & Safari 10 canaries
- (All these builds report back directly into the github PR) – NICE!
- P: People still break e2e tests
- S: You have to let them make their own mistakes
- Get the PR author that broke the test logic to update the test, don’t just fix it
- Backwards law: acceptance of non-ideal circumstances is a positive experience
- Solving problems creates new problems
- Happiness comes from solving problems
- Think of what you ‘can’ do over what you ‘should’ do
- Tools can’t solve problems you don’t have
- Continuous delivery only possible with no manual regression testing
- Think in AND not OR
I thought this was a clever way to present a talk, and the challenges are familiar, so it was interesting to see how Alister’s team had been addressing them. Being a talk about ‘what’ and not ‘how’ meant there was less direct actions to take out of it. I already know the importance of automated tests, running them as often and early as possible, running parallel and similar tips that came up in the talk. So for me, I’m interested in exploring setting up an optional build into a test environment or docker build where e2e tests can be run by setting an optional label on a github PR.
A Tester’s guide to changing hearts and minds
by Michelle Playfair – @micheleplayfair
- Testing is changing, and testers are generally on board, but not everyone else is.
- Some confusion around what testers actually do
- Most devs probably don’t read testing blogs, attend testing conferences or follow thought leaders etc. (and vice versa)
- 4 P’s of marketing for testers to consider about marketing themselves:
- Product, place, price and promotion
- Product: How can you add value
- What do you do here? (you need to have a good answer)
- Now you know what value you bring, how do you sell it?
- Promotion: Build relationships, grow network, reveal value
- You need competence and confidence to be good at your job
- Trust is formed either cognitively or affectively based on culture/background
- You need to speak up and be willing to fail. People can’t follow you if they don’t know where you want to take them
- Learned helpfulness
- Think about how you talk to yourself
- Internal vs external. “I can’t do that” -> Yes it’s hard, but it’s not that you are bad at it, you just need to learn.
- Permanent vs temporary. “I could never do that” -> Maybe later you can
- Global vs situational. Some of this vs all of this
- Step 1: Please ask questions, put your hand up! Tell people what you know
- Develop your own way of sharing, in a way that is suitable for you.
- If you can’t change your environment, change your environment (ie find somewhere else).
Michelle presented very well, and the topic of ‘selling testing’ is particularly relevant given changes to the way testing is viewed within modern organisations. This was a helpful overview to start thinking through how to tackle this problem. The hard work is still on the tester to figure things out, but using the 4 P’s marketing approach is going to help structuring this communication.
My talk “Advancing Quality by Turning Developers into Quality Champions” was next, but I’ll talk more about that in a separate blog post later.
A Spectrum of Difference – Creating EPIC software testers
Paul and Lee talked about the program they have set up to teach adults on the autism spectrum about software testing through the EPIC testability academy. An interesting note early on regarding language is that their clients indicated they preferred an Identity-first language of “autistic person” over phrases like “person with autism”.
They had identified that it’s crucial to focus their content on testing skills directly applicable in a workplace, keep iterating that content and cater for the group differences by arranging content, changing approaches etc. They found it really helpful to reflect and adapt content over time, but ensure you give your content enough of a chance to work first. Homework for the students also proved quite useful, despite initial hesitations to include that in the course.
It’s encouraging to hear about Paul and Lee’s work, a really important way to improve the diversity of our workforce, and give some valuable skills and opportunities to people who can often be overlooked in society. It was also helpful to think a little bit about structuring a training course in general and what they got out of that.
I did find the paired nature of the presentation interfered with the flow a little but not a big problem.
Exploratory Testing: LIVE
This was an interesting idea for a talk, a developer at Adam’s work had hidden some bugs in a feature of his company website, and put it behind a feature flag for Adam to test against, while not making it public to anyone else. Adam would then do some exploratory testing, trying to find some of the issues that the dev had hidden for him, demonstrating some exploratory testing techniques for us at the same time. Adam also had access to the database to do some further investigation if needed.
The purpose of doing this exercise was to show that exploratory testing is a learned skill, and to help with learning to explain yourself. By marketing yourself and your skills like this, others can and will want to learn too.
- Draw a mindmap as we go to document learnings
- Consider using the “unboxing” heuristic, systematically working through the feature to build understanding.
- E.g. Testing a happy path, learn something, test that out, make a hypothesis and try again. Thinking about how to validate or invalidate our observation.
- Sometimes you might dive into the rabbit hole a little when something stands out.
- Make a note of any questions to follow up or if something doesn’t feel right.
- It can be helpful to look at help docs to see what claims we are making about the feature and what it should do. (Depends on what comes first, the help doc or the feature).
An interesting way to present a talk on how to do exploratory testing, by seeing it in action. There were a few times I could see the crowd wanted to participate, but didn’t get much chance, and it felt like it was kind of an interactive session, but kind of not, so I wasn’t quite clear on the intention there. Seeing something in action is a great way to learn, though I would’ve liked to see him try this on a website he didn’t already know, or at least one that more people would be familiar with, so we could all be on a more level playing field, but made for interesting viewing regardless.
Part 2 of my summary will follow soon!