I was incredibly lucky to be able to attend TestBash Brighton as a speaker at TestBash Essentials. I’ve listened to some really intelligent people talk there, so I decided to write up a small takeaway. No long prose here, just bits and pieces of things I think were interesting.

(Don’t see your talk here? Don’t worry. It probably only means I’ve been unable to easily write about it here without just paraphrasing your talk!)

What is testing?

I try not to worry too much about definitions and names of things, but there was an excellent talk, and lots of discussion, on what testing is and what testing isn’t.

Some key quotes that I noted down:

”A user would never do that”, “Yeah, but what if they did?’

We demonstrate we need to look at the blind spots

We bring uncertainty into a safe space where it’s ok to talk about them

Security

We had a joint talk by a tester and a pen tester, and on giving the talk together spoke about (and gave) the message that it’s not just the responsibility of pen testers to do security testing. It’s something the whole team can get involved in as early as we can. Knowing things like the OWASP top 10 and knowing the tools makes it easier for us.

And something that was said almost as an aside is the idea that we can include security checks into our build process and/or automation. I think this is a really good idea, and is something I’ll be thinking about in the future.

Claire coined a really good term: security smells. Like code smells, but with security. I would really like to hear more about this.

The testing periodic table

This is an interesting one. Ady Stokes has created the Periodic Table of Testing. There’s a lot to this, and it’s something I need to read a lot more about.

Pair testing

Making a partner makes you accountable.

I really like the idea of working with the community, doing something together, to improve your craft. Not only does it make you accountable (which, if you look at the dates of my blog posts, is something I need!), but it also improves ideas.

I’ll be keeping this one in the back of my mind. I’m not sure I want to just do a journey of pair testing with people, but I don’t know what I want to do yet.

Culture in a ginormous company

Some takeaways here are:

• We should be working ourselves out of a job: the endgame should be that everyone becomes more test minded.

• If we use the right levers, we can start to do great things

• If there are restrictions, try to identify the fears behind them. To get high level support, try to speak their language, and know their targets. Find something to tie onto.

• Recognise it can take even a year to get things done. It’s important to recognise the scope.

• Some useful books: Emotional Intelligence 2.0, Driving Technical Change, Peopleware, The Trusted Advisor

• Don’t ask, just demonstrate

Organising community in a company

As someone who set up a community of practice of sorts where I work and is always looking for ideas to improve it, I found this one interesting. While it wasn’t a “how to set up a community of practice” it did still have some useful hints about creating a community.

Things I’ll be trying are putting together a proper purpose (not just a few sentences that goes into the email invite), making sure it’s a community owned by everybody: not just me. And something that isn’t just a regular meeting at the same time every week. By moving things around a little and doing different things, different people can get something out of our little community.

Heck, the speakers did mention things like socials and game nights. That’s certainly something that could work in our company!