Housekeeping…

I’ve been meaning to write something for a while, but struggling to think what to say so have been putting it off, until I set myself a deadline of posting something before year end.

It was a surprise to see its nearly 4 months (!) since I last posted about job adverts and how they need to change. Maybe you had a chance to read it, maybe not, but it was something I really felt I wanted to highlight – and then once I had done so, I ran out of ideas, until today.

My focus this week has turned to housekeeping, as the approaching Christmas holidays and start of a new year tends to focus the mind. We look at our objectives, assess whether we met them, and start to plan for 2020. What do we want to achieve, add in some stretch objectives, think about how we can improve what we do personally (can I make better use of my time, go to less meetings, and have a sense of achievement), and within our teams (how do we do our testing, what can we stop doing, what can we do differently, where are the gaps in our testing).

I’ve been tidying up some old wiki pages (these have not been updated since 2016, some 2-3 years before I joined the company), and thinking about what we need to achieve as a team. There are some bigger challenges that will take time and resource to do, but there are also smaller things that can make a difference too.

It’s also a good time to reflect on the progress that has been made over the year – sometimes its really easy to forget some of the positive things that have happened. I started my role at the end of January and have a list of achievements – introducing test team meetings, thought leadership, lunch and learn sessions, automation guidelines and roadmaps, training sessions etc. These have all had a positive impact on the team, in the way that we work, learning new skills, sharing with each other, and becoming even better testers.

There are many things I would have liked to have implemented, but there is a tendency to start a new job with a list of things as long as your arm. And then reality hits and you find that the pace of change is dictated by other factors that you have no control over. Am I disappointed? No, I am a realist.

Now is the time to celebrate the wins and achievements that I have been able to make, and to try to make a more realistic plan for 2020.

I hope that you can also take some time to stop and reflect on your journey this year:

• Where were you back in January?
• What hopes and dreams did you have for 2019?
• Did things pan out as expected, and if so, are you pleased?
• If not, what changed, and did they turn out even better perhaps?
• What can you learn from this year?
• Have you grown as a person in your soft skills as well as your technical skills?
• Are you happy?

I hope that you have had a fruitful year, whatever life has thrown at you, and wish you all the best with your life, career and plans for 2020.

Thanks for reading, do feel free to leave a comment on your 2019 journey.

Tester job ad’s need to change

It has been a while since my last post, due to holiday and other general busyness, plus a struggle with what to blog about, after completing the 4 part series on preparing for a conference talk.

Ironically, it was the preparation for my next talk on 17th October at Test Expo in London (https://conference.unicom.co.uk/testexpo/2019/london/) that has led me to this post. Funny how things work out.

My talk is about how testers can cultivate their careers, by investing time in 3 skill areas, rather than just on technical skills which seems to be what happens. We woefully under-invest in other areas and it really concerns me that we churn our people with tech skills but no analytical or soft skills, and that isn’t right.

I did some research into the types of skills in job ads, those HR departments are looking for and skills that testers believe are important. I’ll share more details on here after the conference talk, but the essence is that there is a disconnect between all 3.

What I want to cover here though is just one of those areas – job adverts.

I dont know whether it would come as a surprise if I said that ITJobswatch.com stats for Tester, Test Analyst and Test Engineer job ads over a 6 month period, showed that NO soft skills or analytical skills were listed.

Everything in the top 30 is either technical, educational (ISTQB) or a type of test experience needed.

A few days ago I met up with Tom McNama from www.teksystems.com for a chat, and it was fair to say that he was gobsmacked when I shared this with him.
We make assumptions that candidates come with certain things as standard – a bit like when buying a car, we dont ask for seats and a steering wheel – but with humans, we cannot take anything for granted.
Assuming that a candidate with great technical skills also possesses analytical and soft skills is a mistake.

• How good are their communication skills?
• Will they be able to speak to colleagues in a respectful way, and be able to articulate themselves well?
• Could they speak to customers and represent your company?
• How good are their analytical skills?
• Will they be able to pick up a user story and review the acceptance criteria, and ask sensible questions that help to uncover potential risk areas?
• Can they think about other scenarios?
• Will they be able to learn the business well enough to know if something that is proposed might not work for the end user/customer?

To exclude these things from job ad’s is short-sighted, and can give hiring managers a headache. As a hiring manager myself, I do not want to wait until a candidate is put in front of me before I find out if they are lacking in these areas – it wastes time all round. I’d like a recruiter or internal HR partner to be able to do a good phone screen to assess these skills themselves and then put good candidates forward, but if we dont specify what we need, how can they do this effectively?
There is a difference between someone who is a little shy and needs some help and encouragement to speak to others more openly, and someone who is brusque or rude who may not so easily change, and could cause friction within the team.

On the flip side, if job ad’s only ever display the tech skills needed, this tells the candidate that they are the only skills that matter – whether that is true or not. It doesn’t encourage them to invest any time in other areas as they are not outwardly shown to be important. Would you want to work for an organisation that only values you for your tech skills and doesn’t care how you treat other people? Because that also means they don’t care how others would treat you.

Tom was very open about the fact that it is so easy to take one job ad and use that as a template for the next job. So if a template is flawed, it’ll always be flawed, unless we change and improve it, and that is where you come in as a recruiter, hiring manager or someone with any influence over what skills your next team member needs to have.

Of course you need to list the tech skills, but also think about the company culture. What type of person would fit it? How do people communicate – is it more by Slack/Email or face to face? Do you work with offshore colleagues? If so, how good does the communication need to be? What is the expectation that you have.

Think about the job of a tester – hint, it’s NOT about just writing some Selenium code! A tester should be able to analyse requirements, ask questions, highlight gaps and risks etc, so you need someone with good analytical skills, unless you really just want a code monkey who bangs out C# code all day without thinking about what they need to test!.
I believe testers should be critical thinkers, so how important are analytical skills to you?

Make sure that the job ad is well balanced. Giving an idea of the types of tasks that the candidate would be involved in will really help as it underlines the need to have a good mix of skills, and shows that the company values all of them, and this will encourage continuous learning.

Once one recruiter starts to make their job ad’s stand out in this way, others will follow. I’m going to check in on the Teksystems job ads in a few weeks, as I know Tom is keen to start addressing this if he can, and it’ll be a great start.

I will ensure that for any openings in my team, I will better emphasise the mix of tech and non-tech skills needed. What change can you make to help?

How to prepare your first conference talk – 4. Taking on board the feedback.

This is the final part of the series aimed at helping you prepare for your first conference talk.

After the talk – self reflection.

Once the talk is over, and you’ve breathed a sigh of relief, you may have another talk to go to at the same conference, but I’d advise taking some time for yourself, especially if you have just delivered your first talk.

Whether the talk was 20 minutes or 60 minutes, you will have used up a lot of emotional energy. You may feel on a high (if you thought it went well), or you may feel low and drained (if you had technical issues or felt it wasnt that well received).

It’s important to grab a drink and find a place to gather your thoughts, even before you ask for feedback. People may come up to you and tell you it was good (which is a boost), but focus on sitting quietly and jotting down some notes. Think about things such as:

• Did the time go quickly or slowly
• Did you lose track of time, and did you have to rush
• Were you able to cover all the points
• Did the talk flow or did you lose your place and struggle
• Did you feel as though you spoke at the right volume, and engaged the audience
• Did people seem to understand what your message – was the audience with you
• Were you rooted to the spot or able to move around
• Were there some good questions at the end
• If you were going to deliver the talk tomorrow, what would you do or say differently
• Did the slides work for you or would you change them.

There will be other things that come to mind but I think these will be the main considerations.

Your own sense of satisfaction will come from how you thought you performed plus the feedback from others, so it’s important to get your thoughts in order first, before your view is clouded.

After the talk – feedback on the day.

If you have friends or colleagues who are attending, they would be a good first port of call to ask for their honest feedback. It will be difficult for anyone to tell you if they think something didn’t work that well, so you need to prepare yourself to take onboard constructive feedback, and also give them permission to tell you as it is.

You need feedback to help you prepare for your next talk, so don’t short-circuit this loop, as you will be the one who loses out.

There will be feedback from attendees – people are usually quick to come up and say if they enjoyed a talk, and why. I have never had anyone tell me that a talk sucked (thankfully) – that feedback tends to go to the organisers, but even so, it’s good to know which parts of the talk resonated with others – ‘what went well’ – so you can replicate that next time.

After the talk – feedback from the organisers.

Hopefully you have been to enough conferences to know that there are usually feedback forms, asking what you think of the facilities, calibre of the speakers, the topics, and then the delivery of each talk itself, with some sort of scoring system.

These will be collected, collated and then distributed to the speakers a few weeks after the event, and it’s certainly something I eagerly await, as I want to know if the talk was pitched correctly, or whether I got it wrong and need to rethink some aspect of my topic or delivery.

With any luck the score will be a good one, indicating that the talk was well received – but even if not, there should be some comments to help understand why specific individuals did not feel that the talk met their expectations. Feedback is not always right – it is subjective. One person will dislike a talk whilst their neighbour will love it, as we each attend a talk and receive the information based on our own perspectives and circumstances. It’s important to note that you cannot please everyone, so take the feedback with a little pinch of salt.

As an example – if someone did not like the topic, then that’s not your fault. You could recheck the bio that you sent to make sure that what you covered matched what you said you were going to do. If it did, then there isn’t much you can do.

However, if someone felt that the talk was too slow/too quick/missed key points etc, this is far more useful, as you can think about how you delivered the talk and how you would improve it to ensure the message was given and received as intended.

Constructive feedback has much more value, so your job is to sift through and select which comments are most appropriate to helping you to plan your next talk.

Conclusion.

So, we reach the end of this mini-series on how to prepare for your first talk.

We’ve covered the initial ideas stage & submitting to conferences, preparing the talk slides, content & delivery structure, delivering the talk on the day, and now wrapping up with self-reflection & feedback.

I hope that you have found it helpful, and I would certainly value YOUR feedback on this, especially if you are preparing for a first talk, or have just finished one. Is there anything that I could add which would help others?

Lastly, if you have any specific questions about speaking and preparing to do a talk and you would like my advice, or to use me as a sounding board for any ideas, please do get in touch.

Thanks for your time.

How to prepare your first conference talk – 3. Delivering the talk.

This is part 3 in a 4 part series aimed at helping you prepare for your first conference talk.

**Updated with some additional thoughts**

A few days beforehand.

Yes, I am going to start the Delivery stage before the actual day, and there’s a good reason for this.

By this time you’ll have created the slides, rehearsed what you want to say and sent off the slides (possibly) to the organisers, and now its time to do that final checking in order to remain calm and relaxed on the day.

1. Check you know exactly where you need to be. If its somewhere you need to travel to, I hope that travel tickets and any accommodation will have been sorted out well in advance, but this is thinking about the actual venue – have you had any instructions from the organisers?
2. Do you know the timings? Some organisers like you to be there early to try out microphones, or to check if your laptop works, or that the slides work from their own laptop.
3. What kit do you need to take? Laptop, charger, HDMI cable, adaptor, memory stick etc. Will you need one of the clickers for the presentation? Is it all working?
4. Have you seen a schedule to know what time your slot is?
5. Have you had a look online at the venue? Its useful to see if there are any photos of the rooms to get an idea what its like if you haven’t been there before.
6. Do you know what you will wear? Some people choose business casual, others jeans and t-shirt. Its up to you – perhaps look for photos from last years event to see what the format was, but plan carefully. You don’t want to add pressure by feeling over or under dressed.

The day before

Make sure that you set your Out of Office on Outlook, set Slack to Do not disturb, and remind people that you will not be contactable.

The last thing you need before delivering your first talk is getting dragged into work emails, calls etc. Your aim for tomorrow is to remain totally focused!

Above all, keep calm. Run over the slides one last time, and do a talk through to yourself, just to remind yourself of the running order.

You may be travelling the day before, or early the next morning, but either way, try to get a good rest. Delivering a talk whilst yawning might not give off the right impression!

THE BIG DAY

Well, this is it.

The day has finally arrived, you’ve made it.

My first piece of advice is to arrive in plenty of time. Remove any possible stresses that you can from the day. Chat to the organisers, you may see other friends there that you know, have a coffee and try relaxing the nerves.

If you need to take some quiet time before your talk, then do it. Although a benefit to speaking is that you get to stay at the conference and attend all the other talks, put yourself first. If you need some space, then take it, but don’t isolate yourself for too long.

When you walk into the room to deliver the talk, you will have some time (5-10 minutes usually) to set-up. With any luck there will be no problems, but be prepared for issues if swapping over laptops – they happen 50% of the time in my experience, and people are used to waiting.

You will be introduced (I hope) by someone, and then its over to you!

Delivery

Click to the first slide, take a deep breath, and start with your own welcome. Smile.

Remember to look around at all areas of the room, try not to stand behind a lectern with arms folded or by your sides – step out, pace a little if you can so that you engage everyone. Seeing someone move around a little, and show some expression will help maintain interest, whereas a monologue delivered from one place will send people to sleep. Don’t forget to smile.

Change your voice pitch, and ask questions of the audience. “Raise your hand if you have ever experienced xyz” is a great question – you raise your hand and others follow. Leave your hand down, and so will they – even if it’s true. People follow others and mimic behaviours. It also engages them, and then they are now part of the talk.

Smile when appropriate – you will look friendly.

When you have the slides up, it’s ok to glance at the laptop screen to see where you are but avoid putting your head down and talking at the screen too much.

In the same way, avoid turning your head and talking to a screen. Although you may have a microphone, it still looks a little odd – try always to look at your audience to keep them engaged.

Look around at the audience as you speak (unless like my last talk there are spotlights in your face as it does make it awkward), as you need to know if they are coming along the journey with you. If you see people nodding with you, then they are onboard, but if they are looking elsewhere, you may be using them. It can seem as though people on phones are doing other things – but it could also be that they are tweeting about your talk, so don’t be too phased by that.

If you do see people fidgeting or looking sleepy, think about skipping ahead a little. If the depth of the subject isnt winning the audience, don’t be afraid to say  something like ‘I won’t go into too much depth, but happy to chat with anyone afterwards if you are interested’. It shows that you recognise that people have different needs from your talk, and will gain you brownie points.

If you lose your thought process, take a few seconds, glance at the slides, and continue from a point you are happy with. It may be a little disjointed, but it’ll soon be forgotten.

Likewise if the slides go wrong or there is a technical issue, don’t panic. It happens more often than you would think. Calmly try to recover the situation. Rest assured that if it’s a technical problem, help will be on its way. Once fixed, make a joke about working in technology – you’ll get a sympathetic laugh and it will relax you and the audience.

Finally, when you wrap up, recap your points, thank the audience and then ask for questions. Look happy.

You will get a round of applause, and hopefully people will ask some sensible ones. Answer as honestly as you can. If it s not something you can respond to, don’t be afraid to answer truthfully that it isn’t something you have experienced, but you could offer to chat later if it would help.

After the questions, thank them again, and exit stage left.

Congratulations! You have just delivered your first talk 🙂

Take a deep breath, grab a coffee and relax.

Part 4 is all about feedback, where you’ll gather your thoughts and take on board participants feedback.

 

How to prepare your first conference talk – 2. Planning.

This is part 2 of a 4 part series aimed at helping you prepare for your first conference talk.

Planning the detail.

After the initial euphoria of being accepted has worn off, you can reach the ‘oh bugger’ moment quite quickly (I know I did!) where the realisation hits you that you have just committed to giving a 25/45/75 minute talk on a subject, and now you have to deliver!

Hopefully you have some time to get into the detail before the conference. No organisers are going to give you really tight deadlines, so you can afford to take some time to step back and take a deep breath.

Task list.

Firstly, think about the tasks that you need to do. You might think its just writing slides, but it’s not just that – there are other things too, such as the running order, any research that you need to do to support any information or points you want to make, and making brief notes to refer to on the day itself.

When I was starting out, I was given some great advice by Mark Wilmshurst, my CTO at the time. I explained my talk, how I wanted to run through it, and mentioned that I had pages of notes to refer to. He introduced me to mind mapping, not only as a way to plan out the talk, but to use as prompts during the talk. His point was that when speaking, you will not want to be reading from notes (more about the delivery itself in part 3), but it does fall squarely into the planning part. There is no point writing pages of notes that you wont ever refer to, so this can save a lot of effort.

The tasks I follow are as follows:

Lets tackle them in order.

1. Writing the first draft slides.
   These will form a basic structure – and you may have a format that the conference organisers ask for, and they may send you an Intro slide to put at the beginning.
   Start with a Welcome slide, perhaps a little info about yourself. Not all conferences do the people introductions to the same standard, so best not to rely on someone doing it for you. Remember, people have picked your talk for a reason, so they want to know who you are!
   Introduce the topic – what are you going to cover today? Just the key themes.
   Then lead into what you want to say. Only you can decide how to make the story flow, and the number of slides.
   Be careful not to overdo the amount of words, otherwise you may just end up reading the slides out loud. Write the key points only, which you will elaborate on, use reasonably big fonts, add images for interest and animations as well if you like – but again, dont overdo it. Too many animations can be distracting – people may then end up watching the slides and stop listening to you!
   For the final slides, have one that wraps up with a summary of the key themes (the 3 take away points) that you have told them, have a Thank You slide and then one asking for any Questions.
   Job done!
   
   
2. Organising into a sensible running order.
   Well. job not quite done then. You may find that you rejig the slides around – I do this a lot when I start walking through them, as sometimes it feels disjointed. Play around until you are happy with the initial flow.

3. Thinking about the time, and matching content to available time.
   You’ll know how long the slot is that you have – if its 25 minutes, you’ll have a 20 minute talk and 5 minutes for Q&A’s. If 45 minutes, then 35-40 minutes talk and 5-10 minutes Q&A.
   Its difficult to get the balance right first time, so have a go at creating the right amount of content that you believe fits timewise – step 5 will show if its right or not.

4. Memorising the points and writing a few prompts on cards (as reminders).
   Rather than reading from notes, start to memorise the detail for each slide that you want to explain. The more you do this, the less reliance you will have on needing any notes at all – it comes with practice, and after a few talks you’ll find it easier to do. For the first talk, have cards with mind map notes on to help as reminders, just in case you get lost in thought, or something happens that stops you (e.g. technical glitches).

5. Delivering to yourself in a room, slowing down the delivery speed and timing it.
   This is the weird part. It feels very strange to speak out loud to yourself, but I recommend that you do so.
   Book a meeting room that is private and out of the way, set a timer on your phone, stand up and actually deliver the talk to an empty room.
   Follow the slides in the right order and feel free to stop/start as necessary. As you do this first run through, you’ll pick up all sorts of things – spelling mistakes, the order may not be right, you missed something etc. Thats fine as its the point of the exercise.
   Make the changes and start again, and aim to do a full run through without stopping.
   When you are done, analyse the timings – did you rush, did you speak clearly, did it flow, did you get lost (if so, what can you do to stay on track?) etc, did you start off slowly and speed up?.
   You will get to a point where you are happy with the content, delivery and timings, so time to be brave!

6. Delivering to close trusted friends/colleagues and asking for feedback.
   Pick a few trusted colleagues who will be your guinea pigs. Explain that you are planning your first talk, and ask if they would run through it with you.
   Ideally, deliver it in one go, as you will do at a conference. Ask them to take notes that will help you, and also to ask you questions at the end, as you will want to be prepared for that.
   Once you deliver the talk, ask for their feedback: What was the delivery like in terms of speed and clarity? What about slide content? Did the talk flow logically? What could be done better?
   This is all helpful and will allow you to grow in confidence.
   Also do some self analysis – did you notice anyone looking confused at any point? What questions did they ask you? Did you get caught off guard?

7. Refactoring slides and repeating the run through.
   This is effectively a ‘rinse and repeat’ exercise – making changes and delivering to yourself and others until you are happy. 
   At that point, resist the urge to keep tinkering – stop, save everything and have a break.

Good preparation will make life so much easier, and it will be time consuming, but well worth the time you invest.

At the point where the slides are done, you are confident about the subject and feel you can answer any questions thrown at you, then you are ready to go.

In part 3, I’ll tackle the actual delivery, and offer some advice on keeping calm, and how to enjoy it – yes, it is possible!

 

How to prepare your first conference talk – 1. Getting started.

Following on from my last post about my Unicom talk (and ahead of my National Software Testing Conference talk tomorrow), a couple of people have asked me for advice about becoming a conference speaker, and the qualities and skills that are needed.

I thought it might be helpful to share some of my thoughts, in case anyone else finds it useful, and I’ll tackle it in a number of sections.

Initial hurdles.

As a starting point, it’s interesting to note that there are a number of things that prospective new speakers are concerned about, and these are along the lines of:

• Do I have something relevant to say,
• Do I have the confidence to speak in front of people,
• Will I be good enough.

I felt the same way when preparing for my first talk back in 2011, and its perfectly natural.

My response to any concerns is that everyone has a story to tell based on their own unique life experiences, so that means that everyone has something relevant to say. That includes you. If this is a concern of yours, then please don’t worry. We are crying out for new speakers to come and share stories and experiences that we haven’t heard before.

In terms of building confidence, it takes time, but it can be done (and I’ll go into that in another part of this series).

Lastly, as to whether you are good enough or not, how will you know if you don’t try? We all fear failure, but actually, I find testers to be hugely supportive of each other. You may be nervous, you may trip up, but you are human, and therefore fallible. Don’t expect to give a 100% perfect delivery on your first attempt. just aim to do the best that you can.

Getting started.

At this point, I am going to assuming you have decided to go ahead and prepare to submit a talk, so the first question is, how do you get started?

Firstly, you probably have an idea of what you want to talk about. Something that I have got into the habit of doing is to have a few ideas on the go and writing down what I want to cover for each one. Having a number of possible talks can help determine where to submit to, depending on the conference themes.

For each topic, I jot down some of the things I want to say, and work backwards. I think about the 3 things that I want the audience to take away from the talk, and then work out my route there. This may not work for you, so try out your own planning strategies until you find something that works you are comfortable with.

A useful tip I was given when I started out was to think of a talk as 3 separate parts:

1. The introduction – who you are, and what you are going to talk about.
2. The talk itself – delivering the message you want in detail.
3. The summary – recap what you just told them, and reiterate the 3 key take-aways.

I don’t think you can go far wrong if you have this as a template to work from. Getting stuck in without any intro, or finishing without a recap will leave the audience somewhat bemused or confused, so at the very least, work on these first and make sure you dont skip them.

I use a mind mapping tool to expand on the particular theme, drawing out the important parts. As an example, doing a talk on the 3 skill areas that testers should work on, I broke my talk down like this:

The main parts are in blue with the grey areas going into a bit more depth. I haven’t added in the intro and summary, but you get the idea.

It’s at this point where the idea is well formed, but there are no slides, which is the time to submit the talk. Conferences will have different time slots – as little as 25 minutes or as long as 75 minutes in some cases, so there is little point in writing a lot of slides in detail until you know how much time you’ll have. 

Submitting your ideas.

Having decided on the topic, and the key message, it’s a good time to submit the talk to one or a number of conferences.

Consider the conference themes, and ensure that your talk fits in with them. It gives you a better chance of success, and is better than a ‘scatter-gun’ approach.

Submissions usually need a bio – a summary of you and your career, and a brief description of the talk. This is your marketing opportunity, and where you will outline what the talk will cover, so that prospective attendees can decide if it’s a talk they want to hear. Don’t forget a photo – something professional looking is best, as it’s going to be on marketing material and the conference website too!.

Don’t be too concerned if you are not successful the first few times you submit, as there is a lot of competition for spaces. (Eurostar is one of the biggest conferences and has many more submissions that there are spaces – I couldnt even guess as to the ratio of speakers to spaces). Keep plugging away until you receive your first acceptance email 🙂

Congratulations – you have been accepted!

Wow! This is a real mix of emotions – the joy of being selected versus the sudden realisation that you have to complete and deliver a talk!

But don’t panic – there will be plenty of time to get the slides written, work out the flow and to practice timings and delivery. More to come on this in the next blog post.

The Unicom Testing Summit

I was fortunate enough to be invited to speak at the Unicom Testing Summit in London on 11th April, which meant being able to attend the day long event.

For anyone who hasnt been before, there is a joint morning session with 4 talks and a panel session, and then in the afternoon there are 3 parallel sessions – Agile, Devops and Testing.

From the talks and discussions, I am going to call out two things in particular which I found really thought provoking – not that the others were not interesting, far from it, but there will always be certain talks that are more relevant to our particular circumstances.

The first talk was a Keynote from Zuzana Sochova on what it takes to be a Great Scrum Master. This isnt a role I have done, but two of my current team have taken on Scrum Master roles alongside their Testing role, so I was interested to find out what Zuzana was going to tell us.

She shared her thoughts on the role being one of a coach, teacher and mentor, creating an environment to help people to remove impediments. This was different to what I had heard before, where the view is that a scrum master removes impediments from the team, but Zuzana’a rationale was that creating a self-service culture and allowing people to remove their own impediments is an important part of helping people to learn for themselves rather than create a dependency culture. The phrase ‘servant leader’ was also used to describe the role, and this makes sense. Everything that you do as a scrum master helps the team in some way.

The other interesting thing that Zuzana said was that she recommends that the role NOT be shared with anything else. This is a difficult one, as I understand the reasons for saying so – that the time devoted either to being a scrum master or to the other role may be compromised in some way and time not apportioned appropriately. It all depends upon the structure of the organisation so I dont believe that this can really be a hard and fast rule, but it was an interesting point to bear in mind.

The second thing I want to mention was a round-table talk that took place before the split into the different tracks, and I joined one entitled ‘No place for manual testing in DevOps – is a myth’. Understandably this was very well attended with an interesting debate from most of the people sitting round the table.

There are a lot of people in the industry who believe that automated testing can replace manual test effort, and this came up from a number of people who feel pressured to learn automation in their organisations. One person said she really didnt want to learn to code – she enjoys testing (she used the phrase ‘Star Shaped Tester’), and I sympathise. If I wanted to write code, I would have been a developer, but things have changed, and we have to recognise that testing in 2019 with a move to a DevOps culture means that there is a clear need to embrace automate testing to cover regression type checks. But it is also clear that there remains a place for manual (human) Exploratory testing, and I had a light-bulb moment during this discussion.

We, as an industry, do not make enough effort to showcase where Exploratory testing brings benefits, therefore those in management who hold the purse strings also cannot see where manual testing adds value, so they only push for automated testing. Fundamentally it is OUR fault for not doing enough to demonstrate the value of manual and automated testing and the drawbacks of each as well.

We need to educate, and I am going to do something to show internally to my management team, and also plan for a conference talk to try addressing this, so keep an eye out. We have a lot to do!!!

Just to finish, I presented my talk on how to Talk Testing to Non-Testers, and at some point soon I will type up some of my thoughts on this, but I was really pleased that about a quarter of the 24 or so attendees came up to me afterwards to say that they enjoyed the talk and found it useful/helpful/. It’s always great to get positive feedback, so am glad that the work I put in was well received.

Thanks so much to Narayanan Palani for taking the photo of me in action and kindly sharing it.

My next talk is at the #NationalTestConf at the British Museum, 21st-22nd May, where I’ll be speaking about how to become a better tester. I look forward to hopefully seeing you there! https://bit.ly/2USoxIf