Testbash Brighton 2019 Conference Day Part I of II
It’s been an intense month in a my personal life and even more intense (exciting!) months to come. So before I get too busy, let’s turn my notes (that can only be read by me), into a blog post!
In early April this year, I had the honour of speaking at Testbash Essentials on the Wednesday. I also had the opportunity to attend the main Testbash Conference on the Friday and learn a lot from the speakers.
Here are my notes on what I learned in the first few talks I was able to attend (I had to leave a bit early to make my flight back home).
Lisi Hocke - Cross team Pair testing: Lessons of a testing traveller.
“Have you ever asked yourself, are you good enough?"
Lisi didn’t come from a technical background —> she fell into testing.
She was mostly the lone tester at a company and didn’t have a mentor. But now at her current company there are more testers.
“I’m basically just managing my list, but not learning something."
She shared her struggled in learning new things and constantly having to edit a to-do list.
When she met Toyer, they helped each other get out of their comfort zones.
She then created a goal: 10x pairing sessions with at least 6 different testers. Each 90min long.
Benefits of pair testing:
- Having a learning partner, who keeps her accountable really works well for Lisi.
- Vulnerability: Both revealed to each other they are newer
- Never get stuck: Then can trigger new ideas with each other.
- Making implicit knowledge explicit
- She now has a better understanding of what she knows and what she doesn’t know yet.
- Expand her network –> so she can learn more in the future.
2019 goal: Code confident.
Claire Reckless and Jahmel Harris - United by Security: The Test that Divides us.
How did it work?
- They started with STRIDE
- Whole team activiity
- Outcomes fed into requirements
- Long sessions
“If there are heaps of vulnerabilities, it makes it harder for the pen testers to know which vulnerability they should focus on”.
Jim Holmes - Changing testing culture in a ginormous company
- Think about helping the business to succeed (don\’t just think about the user)
- Communicate throughout - not just at the end.
- Spread the testing competency throughout the team (work ourselves out of this specific job_)_
- Push for continual improvement
- Learn the business so you can advocate yourself
- Manage expectations on how slow it can be for things to change in a large organisation –> there’s only so much you can do to speed it up
- You don’t need permission to be awesome
- It’s easier to ask for forgiveness than permission
Ultimately it often came down to a people problem
- Lots of people were stagnant
- Power hungry
- Driven by fear
Choose your battles
- You can’t fix everything
- Focus on what’s important
- What’s the most valuable thing I can do?
People + FUD
- Fear (of change)
Look for existing initiatives
- It can be very difficult to start something new in a large organisation
- But you can try tie your idea to an exisiting initiative (i.e. because budget already exists)
Mike Smith - Owning your craft
New project with lots of new technology and new concepts he was unfamiliar with.
-->This led to imposter syndrome
-->Then he admitted how little he knew
-->Turns out that the rest of the team only had a few weeks headstart and were also learning
It’s not cool to like what we do (at work). A lot of us are surrounded by miserable people.
Mike wanted to get better: “It wasn’t just my day job, it was my craft."
If there were things he had to do multiple times, he taught himself how to automate it; write a script for it.
Mike learned to be easier on himself e.g. When he missed a bug, he wouldn’t feel guilty - instead he would get curious and try to make it happen again and again.