Liverpool Tester Gathering – best tester meetup ever?

Dan Ashby

My answer to my own question above: Yes! Quite possibly! There certainly is something special going on up there… 🙂

lpltestergathering

I recently spoke at the @LplTesterGathering and what a tester gathering it was! The place was BUZZING! Packed to the brim with around 110 people showing up and not a quiet person in the room – it was incredible. But the best thing about it…. It felt like I was joining in on a monthly family reunion. But bear in mind that for perhaps 30% of the attendees this was their were first time attending the meetup too!

What made this amazing, was the organisation and on-the-night management of the event – Duncan, Leigh, Chris and Amy are doing a fantastic job with this meetup. And Leigh is a fantastic front-man. His engagement with the audience (he knew everyone’s names which added a real personal touch), and his inclusiveness – passing the mic around to each individual new member to introduce themselves and giving them a warm welcome – it was really special and made the place so relaxed with a real feel-good atmosphere. That certainly helped create and stimulate the buzz.

There were a few rounds of lightening talks before my talk which were great, and it felt awesome getting up in front of such a pumped up crowd. I feel so honoured to have had the opportunity of riding that wave of energy from the audience and being part of that special night.

On top of that, the night was captured on video and streamed live through periscope – you can see it from start to finish here: https://www.periscope.tv/w/1YpKkANQnXYJj

My talk has had some good feedback and I got a lot of questions through sli.do that I need to answer. Unfortunately, Slido doesn’t have the ability for me to respond within slido, so I’ll paste the questions here and answer them within this post. 🙂

Here’s the questions (my answers are in blue):

  • Curious _Tester 15/11/2016: Is agile a journey or is it a destination? Do we know when we are agile enough?
For me, agile can be a mindset, or it can be a process. It depends on the other sentences that are used around the word “agile” when people talk about it. If people mean “process”, then we need to realise that there are so many flavours of agile. I prefer to promote that people learn about agile and implement the processes based on their context. But even if we talk about agile being a process, getting there is a journey and it does require a bit mindset change. I’d prefer to say its not a destination, because being agile is about being able to adapt to change. it’s not about speed. it’s about a realisation that we cant think of everything, so we need to be ready to adapt to information that we learn throughout our processes.

 

  • Rob D: Dan, what’s the structure of your technical testing people? Is it mainly project based, service based, or some other setup?
This completely depends on what you mean by “technical testing people”. If you just mean “automation” (or the people who write code to automatically assert), then that will probably be project focused… But IMO, technical testing is much more than just writing code. You can have technical skills without writing code – e.g. using proxy tools to look at web traffic and intercepting it to manipulate the data. Using browser dev tools to investigate deeper. Using environment builder tools for spinning up test environments. Manipulating databases for testing or for populating data. Viewing logs or utilising monitoring tools. Using other tools to investigate other types of risks (e.g. performance tools, accessibility tools, security tools, etc). This is all technical. The testers embedded in your agile team should be looking to invest time to learn these technical skills. And this can be based on anything: project, product, team, service, platform, etc.

 

  • Anonymous 24/11/2016: What’s your favourite meme at the moment ?
I really like this question! I’m finding myself using the “Godzilla facepalm” image a lot as a meme. I use this when I hear silly things about testing, agile, BDD, CD, Automation, etc (which seems to be all the time recently – there is so much guff information online that people seem to be listening to)… So this meme is very handy. Here it is:
godzilla-facepalm

 

  • gordon crawford 19/11/2016: Any advice for getting testers to engage with learning these kinds of skills where they come to the role with deep domain knowledge that allows them to get by.
Yes! Sensible communication within a safe environment is key. We all start in a state where we don’t know about something, so we, as teachers, need to be aware of that and be conscious and sensible, and perhaps sensitive to this situation.
So, a common problem in our industry is that we have people with 15 years of experience in “testing” where they think testing is “making sure the software ‘works’ as per the requirement”. And when they hear about Exploratory Testing and why investigation is extremely important, some of them go into denial and dispute it. I believe this is because no one likes to look as if they don’t fully know their craft, especially when they have been a tester for so many years. So safety when it comes to learning is vital. If we communicate in a thoughtful way, using examples and exercises to help that knowledge set in and to start building up that knowledge into skills which allow us to grow our experience, then that is the majority of the battle. Influence skills help with initially getting people into the room too – utilise the rule of reciprocation!! Buy cake and doughnuts to lure people in, or take them out for coffee or lunch to get the conversations going as an initial step. 

 

  • Hazel Lythgoe 24/11/2016: Fundamentally, 4 SDLC to deliver the ‘right’ product, the art of communication is key. How wud u use Lateral/Critical Thinking to enhance communication flows?
Lateral and critical thinking skills definitely help uncover and refine information. They allow us to refactor our “ideas” for new software or features to get us closer to what “right” means (which may be just 1 individual’s perspective by the way – there are many stakeholders that we should think about). If you use lateral thinking to think of as many properties as you can relating to the new software idea, and think of as many variables as you can relating to each of these properties, then that stems more discussions. It’s hard for anyone to switch from being in the mindset of “how to solve the problem” towards the “lets uncover information” mindset though. This needs good communication skills to guide the conversations. Another thing to realise – the more diverse people you have in the room, the better the conversations. Everyone has different experiences, beliefs, perspectives, biases, etc. so each person will bring different thinking into the conversations – So “testing the idea” is a team activity.

 

  • Anonymous 24/11/2016: What is your view on how testing aligns to DevOps?
Testing in DevOps is something that is hugely misunderstood. Read any DevOps book, and they dont talk about testing. They might mention a small bit about automation, but they dont mention anything about investigative testing at all. And that is why so many people get it wrong. Communities aren’t diverse enough to learn from each other more. My thoughts on testing in DevOps are here:
“Continuous Testing in DevOps…“. I’m also starting to write a book that addresses this gap too.

 

  • Lisa 24/11/2016: If data gathering is critical thinking & you use data to generate predictive analysis, how do you apply lateral thinking to this model to gain more information?
So when we think critically of information, then we are using existing information to work from there. And the same applies to predictive analysis. We’re trying to predict something that we are looking for when it comes to having prior information to stem that expectation. Its similar to machine learning and monitoring to. We’re using information. With predictions, we’re using existing information to make a prediction. With machine learning, we’re informing the machine to look at information that we tell it to look for (hence its existing info as we are telling the machine what to look for), and it will tell us any discrepancies of deviations, and it will track data over time to “learn” new patterns, all relative to what we initially told it to look for. Lateral thinking (IMO based on Ed de Bono’s books) would be when we take a step back and break down things to actually uncover more information about the initial thing being looked at – Thinking about each different property of that thing, then thinking about parallel variables within each of those properties. Although that will form much more complexity, it’ll certainly stem much more information. If at any point you hear anyone say “oh… I didnt think about that”, then that’s a win. That’s value.

 

  • Duncs 24/11/2016: 4 types of software development slide included development as an activity. Isn’t testing a development activity? Shouldn’t it just be coding activity?
When I say 4 activities within the development lifecycle, I broke them down to “Design”, “Development”, “Testing” and “Checking”. All 4 of these are part of “development” as a whole. But when I talk about the “development” activity (one of the 4 things), I’m talking about coding activities and what people might consider as ops activities, etc. people in any role in the team have tasks that fit across all 4 activities too. But perhaps you’re onto something! Maybe we should split “development” activities into “coding activities” and “ops activities” to call them out explicitly! I like that idea! It makes perfect sense to me. 🙂

 

  • Leigh Rathbone 15/11/2016: Question, this is a test. To see if it works

Did it “work” Leigh? ;P

 

Thanks again to @LplTesterGathering for such an awesome meetup event. It was a pleasure and an honour to be speaking at it and I hope I’ll get invited back up there again soon.

One thought on “Liverpool Tester Gathering – best tester meetup ever?”

  1. Many thanks for the detailed answer Dan. I was thinking about the performance and security testing mainly. They often demand specialist skills and especially with performance testing, often if done incorrectly would lead to false issues, which lead to a lot of time wasted investigating by lots of different people. The approach I’m thinking of suggesting is that there’s elements of performance that can be done by skilled people on the agile teams but then there’s a team which specialises in performance offering a service to smaller projects that don’t have enough requirements for a fte performance person. I agree that in an ideal world the team should be able to do it all and be multi skilled but those skills are quite rare and take time to develop, so maybe a long term goal? or maybe we are behind the curve?

    Like

    Reply

Please leave a comment!