For so long, it’s been assumed that we all have to follow the same communication processes that the company requires us to use to do our jobs. This may be true, but within that, there are intricacies which can help ensure the best communications possible in a given scenario, equally there are some things which cause frustration and unless otherwise shared, noone would know they caused a problem to you.
I’ve been trying to work on understanding how I could make my team dynamics more accessible for all and allow everyone to have their own specific needs met. In a world where we are becoming more accepting of all kinds of diverse individuals, surely it’s ok for someone to express their frustration at people asking questions without any context over IM and expecting an answer?
So I’ve pulled together some key sections below and created my own which I will also attach below:
Why Do I have a Readme?
Everyone is different, everyone has different things which make them tick, different things that annoy them and different preferences for communication. I’d like to give anyone who needs to know, an insight into how I work best and how to get the best out of me when you need me to do something.
How Best to Communicate With Me
<what are some of your preferred comms methods>
If it’s urgent, <insert best way>
How Do You Book A Meeting with Me?
<insert ways you prefer meetings to be booked>
<topics people could ask you about>
What Makes Me Tick
<things that put you in a good mood and help with communication>
What Quirks do I have which you should be aware of?
<some things you may do which may seem unusual, but it is important for you to be yourself>
Things that frustrate me
<things people should avoid when communicating with you>
Hopefully these will help you find a way to communicate your preferences with other and improve communications across teams in your setup.
By this part of the series, we have covered how to open the job market up to a wider talent pool and have looked into how to make Job Specs inclusive, the next step is to look at how we can make the interview process more accessible for all candidates, not just those classed as neurodivergent.
For someone with a neurodiverse condition, the idea of having to communicate and sell themselves to strangers could be akin to torture, this is partly why a lot of neurodiverse candidates will avoid disclosing their condition. They will feel like it will be held against them, rather than being supported and allow for the interview to be adapted for them.
Interviews don’t give a true reflection of whether someone could do a job anyway, but for a neurodiverse candidate, they may be more than capable of doing the job well, but will not get a chance to prove that because they hadn’t found a way to talk about it in the way the interviewees want them to talk about it. Something doesn’t add up here, but the interview process is probably here to stay for a long time yet.
What Can We Do to Make It Less Torturous?
Everything should be done to make all candidates feel as relaxed and informed of the process as possible. without this, any Neurodiverse candidate will instantly feel completely overwhelmed with the lack of knowing what to expect. This alone could cause someone with Autism to become very anxious and either end up not attending the interview or being visibly not at their best during the session.
The first step to help with this, would be to make contact with the candidate beforehand and ask them some simple questions around what environment they would be most comfortable being interviewed in. Given that the point of the interview is to find out about as much about each other as possible, working out whether you are a good fit, why not find an environment which everyone can be at ease? This may be outside in an open space or it may just be in a room which has been set up a lot more informally (no desk and panel interview format maybe?). It’s also a chance to discuss any sensory needs which may be distracting for the candidate (bright lights, loud noise or strong smells). Merely having this kind of conversation with the candidate, shows empathy and care for them and will immediately make them feel valued.
Along with having this discussion, ensure that the format of the interview is documented, and the schedule is sent to the candidate. Again, like the job spec, remove any ambiguous content and make it as clear as possible. Putting times in it may or may not be a good thing, as if there is any deviation to schedule because of delays on the day, this could also lead to anxiety from the candidate.
What are the Tests Proving?
Really assess whether any practical tests need to be timed/pressured. In the working environment, you won’t be in many situations where you have an hour to write a piece of code or perform a task, so why put additional pressure on a candidate who will already be putting additional pressure on themselves? It really becomes a test of processing speed rather than quality of output.
With any tests that are devised, think about how they can be made accesible. Look into whether they are compatible with assistive technology tools. Again, this will be something which will make the candidate feel like they are valued and that you are keen for them to do their best.
Think About Your Questions
One thing that will benefit all candidates, not just the ones who are neurodiverse, is for interview questions to be more carefully planned and prepared. Think about how your questions could be answered.
Do you have any prepared questions which could be percieved as closed questions? For someone with a neurodiverse condition, something along the lines of “Can you tell me about your current job?” could simply be answered with a “Yes I can”. Or something like “What can you bring to this role?” could get an answer along the lines of “my laptop, my rucksack and my lunch”. It’s crucial to find a way to articulate your questions in a way that both sides understand the type of answer expected.
Try to avoid hypothetical questions, someone with Autism or ADHD may struggle to understand the logic of why the answer would be important. Or questions where you get them to compare themselves to the other candidates (when they know nothing about them), this could throw the candidate off and the answers may come across as blunt.
Because of the nature of how some neurodivergents brains work, questions that come across vague will cause confusion, try and ensure these are as clear as possible and don’t be afraid to discuss expectations of what you’re asking about, in order to keep them focused.
Check Your First Impressions at the Door
In the heightened stress of an interview situation, you may find that a neurodiverse candidates eye contact is not what you would usually expect. They may spend a lot of time looking away or looking down, this doesn’t mean they aren’t focused, it may just be a coping mechanism to get them through the session.
Think again about what you are really assessing the candidate on, the problem with interviews are that they often became and exercise in social interaction. And while a lot of interviews are also about how well the person fits in the current team, it’s also important to understand how you can adapt the team setup to enable a neurodiverse team member to excel. So if you think they have the capability to do the job, think about what else you could do to help them fit in.
In part 4, we will look into the induction/onboarding process and how it can be made as inclusive as possible when considering Neurodiversity.
Following on from Part 1, the next step of the process is to look at how we can all make the hiring process more inclusive for Neurodiverse talent. We will look at the job advert in this part, looking at how to make them as inclusive as possible.
The Job Spec is a Window into the Role, how clean is your window?
How many job specs have you seen which are clearly just a regurgitated template which has been used over and over again without being updated for a while? Have you seen jobs with huge long lists of “must have skills”? Are all of these really “must have”? This can exclude neurodiverse talent, because they may feel there is one they don’t match and maybe they see the world in such a black and white way that this will prevent them from applying, even if they are excellent at all the other must have skills.
It’s also common for lots of jargon and acronyms to be used. This can be off putting for any of us who don’t know the terms, but consider someone with Autism who has bucked up the courage to look for jobs, only to be faced with one full of words and phrases they don’t understand, it can not only put them off this job, but can knock their confidence completely that all jobs would be like that and there is nothing they can do. One way around this is for the first time a phrase is used, use the full term and then put the acronym in brackets such as “Test Driven Development (TDD)”, once this mapping has been made, it would be ok to use the acronym. But consider if there are too many specific phrases that could cause confusion. You should want to make the role accessible to all, so the language needs to be as clear and concise as possible.
Try to ensure the daily activities are called out as clearly as possible, avoiding vague statements such as “assisting your manager”, instead specify exactly what that means. The clearer you can be, the easier it will be for someone with a neurodiverse condition to work out whether it is something they can and want to do.
What will the place of work be like to work in?
One thing which is often missing, and it can be crucial for any neurodivergent candidate, would be a description of the working conditions. With the hybrid working world going forward post pandemic, being clear on the environment will be like both in the office and what support can be provided at home too. Be open, if there is a “busy, collaborative working space” in the office, mention it, also state whether there are quiet areas away from the bustle. It would also be good to mention anything which could lead to sensory issues for some neurodiverse candidates, things like lighting, access to windows, smells from the canteen drifting through the office etc. You of course want to sell the workplace, but make it an accurate description that the candidate can assess for themselves. Provide links to a virtual office tour if you can, this will help them get comfortable with their surroundings.
With the home environment, mention what support you will give around equipment setup, but don’t tie it down to just the tech. If there are special bits of equipment needed for a neurodiverse candidate (maybe an anti-glare screen as an example), be open to reasonable adjustment from the standard working setup and help them feel supported.
Feedback and Accreditation
It will also be important if you put a statement around any diversity programmes your company has, including feedback from others who have used it.
If your company has any accreditation from disability organisations or has been certified as something like an “Autism friendly workplace”, then this is hugely beneficial to be included in the spec.
If you’re unsure whether the spec for a role is inclusive of neurodiverse individuals, reach out to organisations such as the National Autistic Society who would be able to provide pointers
In the next part, I will discuss more on the interview process itself.
Please feedback on whether you are finding this series useful… 🙂
As part of my journey in learning more about Neurodiversity and doing my bit in helping make the workplace accessible for all both now and in the future, I felt it was time to start putting my learnings to paper and hope that my tiny circle of influence can get something from my ramblings.
Not sure how many parts this will end up being as I haven’t done this kind of thing before, but let’s see how it goes…
As If It Wasn’t Hard Enough for Anyone to find Work Right Now!
Many Neurodivergents tend to leave school with less qualifications than their potential suggests they should’ve got. This would be due to the support not always being in place in schools to enable them to achieve their best, along with the difficulties of peers who seem them as “different” or “odd”. Schools are trying to change this and SEND is now starting to get more focus, but there is a long way to go.
It’s not just schools either, Higher Education and Vocational Qualification settings also have not been equipped with the ability to support such a wide range of neurodiverse conditions, so it’s no wonder that students with Autism/ADHD/Dyslexia etc may not get the grades or qualifications they wanted or needed.
Find an Ally, Find A Job!
Finding the right job is difficult for us all, but finding a job when you’re Neurodiverse can be 10 times harder. So how can organisations start to make jobs accessible to all and not mean that individuals feel they need to hide their condition as best they can to try and get in the door?
In the current job world, (especially in Tech and other M&A functions), a large proportion of roles are now not publicly advertised and instead come about due to networking and building personal reputations. For people who enjoy socialising and enjoy being an active part of an industry community, this works in their favour, but for someone with Autism who may not feel able to socialise, this can cause additional anxiety and debilitate an individual. This could increase a lack of confidence, self-doubt and cause someone to go back into their shell, meaning they wouldn’t find out about these hidden roles. In some markets, these roles equate to 80% of the market, so straight away the window of opportunity is reduced significantly.
So what can be done? This is a tricky one, because we can’t force people to socialise more in the industry they wish to grow in, but one suggestion might be to find allies. This could come from various sources, but could involve organisations and individuals advocating for Neurodiversity, building bridges with neurodiverse charities and organisations (eg. National Autistic Society) to open a channel with them, to enable jobs to be advertised through their connections.
It may also be an opportunity for some people within major companies to buddy up with neurodiverse talent too, maybe being someone to talk to, to mentor and coach, while also making them feel at ease with what the working world may be like
This would certainly help to open a slightly larger amount of jobs to a market that haven’t usually been given a chance to apply. The next challenge will be to make sure the jobs being advertised are accessible to Neurodiverse candidates and the interview process does not exclude them either.
Guess you’ll be coming back for part 2 for more on that!
In the season of festive films, in our house, one film in particular is on almost constant repeat. That is the film Arthur Christmas. It got me thinking as I watched it with my boys again today, that really it’s a family animated film that looks at the full operational process of delivering 2 billion presents from receiving letters to dispatching the presents under the trees with the plan of a 100% success rate. Of course it’s actually described in a much more fun way than I had just said and is actually a really enjoyable film, even if we have watched it about 20 times already this year… kids hey?
The main crux of the film (apologies for the spoilers) is all about the fact that the new fangled delivery operation falls below 100% success as one child’s present doesn’t get delivered, even though initially the system says there are zero presents left to deliver…
When the present is discovered, a discussion starts over the importance of that one child because the system still shows a success of over 99.9%. So does that child matter if the system shows such a high level of success? In the same way, does it matter if our software systems only succeed 99% of the time? Of course it matters, and in the context of this one customer, it could be a huge issue that the system failed. In the film, that child would be devastated if they didn’t get their present from Santa! This is the point of view which Arthur (clearly more customer focused than his techie brother and Head of Operations, Steve) puts across and then he decides to fight for the child and insist that if the tech system can’t correct the issue, he would do it himself.
Then comes the old trusty manual workaround which resolves the issue which the automated system couldn’t do in time to still deliver the present. Again, this shows similarities to our software systems which require manual resolutions when a failure occurs or a bug is found. I’m chuckling at this point as GrandSanta (who helps Arthur use an original sleigh to fly around the world to drop off the present), talks about how he doesn’t understand the need for the new tech solution when the old method works perfectly well! Certainly a conversation I have heard too many times over the years in the work place…
It really reminded me that sometimes we get so hung up on making the technical solution as flashy as possible that we think it is infallible and it serves our needs exactly as we need it to, but sometimes the bigger picture is missed and customers may not be getting what they need out of it.
2020… what a rollercoaster
Thought this would be a nice random way to sign off for 2020. It’s been a hell of a tough year but also a very rewarding one. While there have been some real personal lows and some professionally too, I’m proud of all that I have managed to achieve this year to keep going despite really not enjoying the working from home.
I set myself a resolution this year to improve my personal brand, especially with starting a new job on January 2nd, I was desperate to help move things forward and almost wanted to be able to show what I had achieved previously, I also wanted to help out the wider community as much as I could.
Reflecting back on some of the things I did this year on a professional level is quite a list:
Took on a wider ranging leadership role at work, during the pandemic while others were on furlough and later leaving the company, which has now become a full role.
Became a D&I Trailblazer at work, particularly advocating for Neurodiversity
Launched an internal Test Community
Panellist at a Quality Leaders Network Event in February
Guest on 3 podcasts (The QA Lead, Test Automation Guild and EuroStar Huddle)
International Conference Talk at Test Leadership Congress
Re-launched the MOTBucks Meetup with my awesome co-host Stu.
Met tonnes of new faces through the MoT VirtualCoffee slack channel and through all the virtual events and discussions.
Mentored numerous mentees in the testing world who were either looking for work or looking for the next step up.
And then the big one, is launching the Testing Peers podcast with 3 hugely important and awesome friends who have at times kept me going this year, it’s been so natural to jump in to the regular recordings and enjoying chatting to friends while recording talking about two things we are all passionate about – Testing and Leadership. 17 episodes down and just shy of 4,000 downloads, I couldn’t have dreamed it would go this well and am really excited about where it’s going.
We launched our 17th episode and our Christmas Special today, check it out via the link above.
On a personal level and from the Peers, I really thank you all for your support, friendship and feedback this year, it has meant more than I could possibly express.
Happy Christmas everyone! Look forward to speaking to more of you in 2021!
Following up from my previous post, I thought it would be a good idea to dive deeper into the idea of the Quality Narrative. As mentioned in that blog, I first came across the term from the ‘Leading Quality’ book by Ronald Cummings-John (@ronaldcj) and Owais Peer (@owaispeer). The book is a great reference for helping to drive quality in an organisation and it has truly become my go-to reference book to understand how to move forward when you hit those roadblocks to improving processes around testing and quality. Here is Ron and Owais’ definition of a Quality Narrative:
A quality narrative is the way people think and talk about quality in a company.
Sounds simple enough, but when you think about it, there are so many parts to decompose. Let me try and do that now and show you how I use this…
What does quality mean for you and the immediate test/delivery teams? Is this the same view of quality that the wider business has. Quality is very context specific, in some, it could be measured by the number of defects outstanding against a release, each one having an impact on overall Quality, others it could be more about the user’s satisfaction of the system. Here is the definition I drive to and share with my teams:
The measure of whether the software meets the explicit and implicit needs of the customer and their ability to use it successfully
Simon Prior 2020
Having a definition for quality which everyone can agree on and work with, can really help trigger the understanding of where and how Quality fits within an organisation.
People would effectively be anyone who you may be trying to pursuade on the importance of quality.
This might seem obvious, but you can split people into different areas of influence and each will have a slightly more removed view of what quality is and how important it is.
You and the test team – You are trying to help drive the culture towards a better focus on quality. To you, it is your main focus.
Your Delivery Team/Department – Quality will be one of the main focus points, not the only one.
Your Organisation – The further removed from quality being the main focus, the less attention given to issues. This is when it starts to become important to be able to map quality to what is important for the company. How does bad quality relate to revenue?
Relating back to the people, the company could mean any level, but ultimately, it should relate to the overall view of quality across the whole organisation.
To the outside world, your company may not talk about quality, until something goes wrong. When it does, quality quickly comes to the forefront because it is then something tangible, whereas good quality doesn’t always have something so visible.
So How Do I Define our Narrative?
So you have an idea of what you are trying to define, the next step would be to start with understanding what the current Quality Narrative is. Start by asking questions to key personnel within every level mentioned above. Ask them about their understanding of Quality, the importance of it, where they believe it fits and how we can improve the quality of our products. You will likely get very different answers for each person you talk to, unless Quality is embedded within the culture already.
This may take time to build up, so don’t expect to be able to get this defined instantly. Once you have pulled this information together, think about the format of defining it. This could be a single slide in a deck or even better, a mindmap. Don’t make it too complicated, keep it succinct and straight to the point on. I would suggest breaking it down to the main 3 areas:
Perceived Quality Ownership
Any discussions around quality start at end of development phase
Value of Quality
Regulatory Requirement and purely confirmation testing (Checking requirements fulfilled)
A very brief example of an “As-Is” Quality Narrative
This should give you an understanding of where you are now, the next step would be to look at where you might want to get to. Understand there will be a journey to get there, but it’s a good time to collaborate with key people again to understand where they would like to focus on quality to be. Quality ultimately doesn’t just mean executing tests, there is far more to ensure the quality is good, everything from ensuring requirements meet what the customer is asking for, all the way through to the right monitoring/observability tools used in production to give feedback effectively and enable the product to be improved based on real usage. Tools such as MetroRetro or Miro can be a great tool (especially during these remote working times) to get people collaborating on this from wherever they are. Bring the key people together, brainstorm the ideas and collaboratively build out a future vision of where you may want to get to. This is then the first step on that journey. Then the hard work starts in moving the culture forward.
Following on from my earlier blog post (Changing the Perception – Working towards a Culture of Quality), I have been lucky enough to have a submission selected for the Test Leadership Congress 2020 which is a virtual conference happening over July-October this year. This got me thinking more about this topic, and it really has become my thing to talk about. At every possible opportunity, I am trying to find ways to change the work culture to have more focus on Quality in any way I can. Whether this be trying to insert myself into Change Review meetings so that someone is representing testing to ask the difficult questions, or even whether it’s starting to define new processes which will help the teams move forward with providing more information about the quality of the system earlier.
With that, I started planning my talk and came up with a model which helps me frame my thoughts and works (for me atleast) when trying to make it a process which teams could follow to improve their working culture.
I’ll add a huge caveat here, that the teams and organisations which this has worked for me with, have not been agile in any particular way, maybe lipservice was paid to ceremonies, but there wasn’t a collaborative culture to any great extent. Testing was generally seen as an expense only considered towards the end of a project and getting involved any earlier was seen as a cost not worth considering.
So let me give you the model, I will then talk through the component parts and how it all plugs together:
So what is this Quality Narrative thing?
I first came across the term “Quality Narrative” , when reading the awesome Leading Quality book. Effectively, the Quality Narrative is how quality is perceived within your organisation. Some of the following questions may help you understand
How important is quality seen when releasing a product? Is it given the right focus? Or Is it an after-thought?
Who ‘own’ quality? Is it a collaborative accountability or do the wider business deem it the responsibility of the test team?
What is the perceived role of the test team? Do you even have a separate test team or do you work more collaboratively?
Are the test team engaged early in the process ?
How is testing done?
What Value does the testing provide?
What is the business’ view of risk?
Does Quality mean more than just testing?
Understanding the answers to these questions for the current state, will give you a fair assessment of the importance of Quality and testing within the organisation. The next step would be to then define what you would like the Quality Narrative to be going forward. Once you have the As-Is and To-be states, it will give you a vision to share and build out the journey to get closer to the ultimate state of Quality being an important consideration in every release.
So you have the vision… what next?
As a leader, you may have driven the definition of this vision, but it should have been a collaborative exercise (with others within the test team and wider delivery teams atleast) in defining the direction and getting buy in at a high level that it is acceptable. Once it’s defined, the next phase is to start engaging the immediate test team, so they can all be advocates for it. Use every opportunity to get them on board with it, give them time to digest it, ask questions and build enthusiasm for working towards the end goal.
One way to do this will be to get the fire lit on their passion for quality. Get an internal community of practice going if there isn’t already one, get passionate speakers to come in and share their ideas and give the team the chance to innovate and change the way they are doing testing too. If they see that their voice is important and you as a leader will listen to them, it will encourage them to stand up when needed, to voice their thoughts.
As small improvements are made to the way testing is done/measured/perceived, celebrate these successes, no matter the size. Seeing that any improvement makes a difference, will help the team feel like what they are doing is worthwhile.
So you have the team on board, now to share wider…
Now you have a passionate, engaged team who are all willing to make a difference and move the business forward, the next stage is to find the opportunities to raise the awareness of Quality around the business. Use different forums internally to share new processes such as metrics which are now being used or a new test strategy which focuses on the vision. Maybe there is an internal blog platform? Are there internal all-hands or departmental meetings which would be good opportunities to discuss such topics and how it could impact those teams? Discussing the test strategy with the customer support teams by framing it around reduced call volumes, would help them buy into the vision in a way that it can help them. By finding ways to discuss quality, it will help get you and your team involved in earlier discussions when projects are initiated. Therefore meaning that what “Good Quality” looks like for a particular project can be defined.
It may also be the opportunity to coach the business to test better themselves too, whether it be asking questions from a quality perspective or for teams which may be working on hot-fixing production or developing internal tools, but don’t have their own test resources, providing support and helping them learn to test effectively, will improve those relationships too.
Sharing is one thing, but can you find Advocates?
When sharing with the business, you may find there are a small group of people who really get it and want to find out more or find out how they can help. This happened to me and this was the time I started getting the TestSphere cards out and invited them to discussions with the test team on all things testing. I’d start getting comments like “I didn’t realise you Testers knew so much!”
Having these voices in wider teams, adds clout to the message. Especially when they are the ones to discuss it with their teams. I had advocates who would be discussing the updated test strategy, or the risk based testing metrics which we had devised and shared with the wider teams to show what we would be reporting on going forward. I actually walked in on a debate in the canteen, with no-one from the QA team involved, but they were discussing how much more confident they felt about the actual quality of the release with the metric I had devised and rolled out. It certainly gave the “warm fuzzys” that we were making a difference.
Improve the Quality Processes and Shout About it!
While also building the relationships with the business, it’s important that they are seeing the value and improvements that you are doing. Of course, alongside the daily expectation of proving the quality of the software through testing, there will be improvements and discussions going on to try and raise the bar and give better indicators of the quality of the software.
As mentioned earlier, this may be working closer with the Customer Support teams to assess call volumes and working on correlating specific customer issues with some additional testing which could be done to find these issues earlier. It may be looking at an approach to Testability which means the system is assessed as testable based on requirements/architecture before any code is develeoped which should mean the systems are of a better quality and less defects found later on. There could be a new approach to automation, maybe it’s been seen as a cost before that wasn’t worthwhile, but by showing the ROI and the feedback cycle reduction, it could be something which can enable earlier releases.
Whatever the initiatives end up being, it’s important to be transparent now that you have built the relationships with the wider business. They should be able to see what you’re doing and collectively reap the rewards of better quality systems.
Reflect, Rinse and Repeat…
This will be a constantly evolving process, a culture is never complete. Enabling it to grow will be important but it will require regular reflection on what could be done to improve and also assess where it isn’t working as well. Maybe there are pockets of the business which don’t see the value, so how could we speak their language and help them buy into it.
Reflecting and re-aligning the vision if necessary will be imperative to ensure it continues to be embedded as a culture. If you stick to your original focus and don’t flex when you need to, you won’t end up with a collaborative culture.
In bigger organisations where there are engineering groups everywhere, it will be important to use shared communities of practice to build the knowledge and share good practices. It will be important to set achievable goals like improving the view of Quality across your engineering group first including all stakeholders outside of engineering. But don’t try to boil the ocean, use regular reflection and feedback to know when to push yourself further or when to focus on honing what you have already achieved.
Let me know your thoughts on this, am I talking rubbish or does it relate? Come and join me at the Test Leadership Congress 2020 to hear me talk more about this. Register here
Ten years in a field of work I love, it felt as good a time as any to reflect on what brought me to this point. I still remember that feeling the day I finished my last exam at University in May 2006 and realised I needed to try and do something with the knowledge I had spent the last 3 years accumulating. I was adamant then that I didn’t feel I would make a good developer, University is a dangerous place for comparing your abilities to your peers and there are always those genuises who seem to know how to do all the tasks that take you hours or days to complete. I genuinely didn’t know what I wanted to do, but felt that the development route may be the best one.
To start with, the University has it’s own in-house development company called Seed Software where graduates could work for 6 months on commercial projects, so I joined there and started work on a .Net project for the Fire Brigade. Less than a few weeks into that, a position came up as a researcher in the University, researching Computer Crime. The project was called Cyberprofiling and was all about identifying ways to create a profile of criminals based on their activities online. I spent time learning Linux, setting up Honeypots and wrote a research paper which can be found here. This lead to my first public speaking slot at the E-Crime and Computer Evidence conference in Nottingham.
The funding ran out in the January and I was out of work. Going on Job-seekers was demoralising, but i found work as a Bingo Caller in a local club and ended up designing a member database for them which I believe was used long after I left. They certainly got value for their £5 per hour salary!
Eventually, after months of interviewing for Computer Forensic roles and graduate roles, I eventually was successful at the McAfee graduate scheme interview. For the next 6 months, I spent my time split between 3 teams in McAfee, one team was a C++ development role for the core Anti-Malware technology, one team was testing the Gateway Appliance hardware and one was doing Anti-Spam research. Out of the 3 roles, I enjoyed working in the development team, but even then, I enjoyed the testing work more. I even asked if there was an option of doing testing for the development team, and there, my interest in testing was born…
I joined the Anti-Malware development team as a junior C++ developer. C++ was the one language taught at University which I said I would avoid like the plague, it was a struggle to feel like I was getting anywhere with it. I could get the simple coding tasks done, but the whole pointers thing really screwed with my head and I beat myself up comparing myself to the team of developers who all had 10+ years experience. I learned a lot from them all and had some great mentors, but something wasn’t clicking for me
The team were using Scrum, so I very quickly became familiar with the process and started championing the agile practices, eventually becoming a Scrum Master for the team. It was at that point, I was told I was different to the others in the team and definitely had more of a people focus than the rest of the team. I took this and ran with it, did the Scrum Master course and worked 50-50 between scrum mastering and picking up dev tasks in the sprints. I then started learning more about the QA process and started helping out with test tasks to keep the sprints on track. I also ended up in our build room (yep an actual server room with a dozen different OS servers), I got to learn Perl/Python as I worked to improve the scripts used to build the software and burn it to discs for distribution). Again, here, I spent time testing the scripts and learning how to improve the scripts in any way i could.
Deciding to Make the Move to Testing
Eventually, in early 2010, in one of my performance reviews, I was asked what I wanted to do, and by this time, I’d built up great friendships with several in the QA team, that they had shared stuff with me. I told my boss that I wanted to move to QA and from there, I started transitioning over to the QA team.
My first testing project was our URL reputation scanning technology and I spent my time writing python test scripts plugged into our automation framework while learning and developing my skills both from a testing and also python perspective.
Over the next 2-3 years, I moved between teams in QA and worked on multiple different projects, eventually moving into a lead position where I coordinated the testing efforts across our globally distributed team. It was here, that I started to really have confidence in my ability to challenge and question features from a testing perspective and helped build a team to do this too. We became a well-oiled machine and helped deliver high quality software with a huge regression automation framework running thousands of tests across dozens of operating systems.
By 2014, I moved teams again and went back to being a QA Engineer working with a team that didn’t have a QA team apart from an architect and myself. Together we defined an automation framework in Robot Framework, hired some great team members and pushed the development cycle to new dimensions with CI and even getting QA involved in code reviews (I wrote about this here). It was around this time that I attended my first Testbash in 2015 and it really pushed me to start loving my career. I set up the Aylesbury Tester meetup on the back of this and started sharing my passion with others.
I found my voice, people started looking to me as the voice of quality, I had a place at the table of discussions for new features, new projects and process improvements too. The team had the respect to make decisions around quality and I started coaching and mentoring the team to push the boundaries and improve the deliverables and influence the end to end operations process.
In 2017, I became the Manager for the local team and a second team in Ireland and found a new passion for leading and coaching my teams. Building a whole team from scratch, using my principles written about in my #makeatester blogs and conference talks, while also nurturing the existing team who were set in their ways and trying to push them forward.
By the mid of 2018, McAfee was changing it’s focus and I felt i needed to look at something different, I jumped to try a more senior position as a Program Test Manager at the National Lottery. While the company was very set in it’s traditional ways around software, I enjoyed changing the culture and helping give QA a place at the table for discussions and not just be a team which executed 100s of tests at the end of a cycle. I was hellbent on raising the awareness of quality and ensuring a focus of testability and automation across all workstreams. It was an enjoyable year in a lot of ways, but i didn’t feel like i fully fit and needed to find somewhere where I felt I could be myself 100%.
This lead me to where I am today, leading the Core QA team at EasyJet, where my focus is on building a centre of excellence for testing which then works to assist the delivery teams across all areas of easyjet with automation and good testing practices.
Who knows where the next 10 years will take me, but I’m confident that I have found my niche and will be pushing ways to improve the focus on quality through coaching and culture changes for years to come.
I couldn’t have done a lot of this without a huge list of mentors and supporters over the years. Far too many to mention here, but I hope they all know how much it meant to me. I will continue to do my bit by paying forward advice and coaching to peers, team members and the wider community.
Feel free to reach out if you want to discuss how I could support you in you testing or leadership adventures!
Long ago was a time where testing was purely seen as an activity by a siloed team who executed 1000’s of tests towards the end of a project. In the modern world, this is still a very real situation in some areas, but on the whole, testing as a collaborative, continuous activity is much more the norm.
But getting to that stage is not easy, for some reason, there has historically been a stigma attached to testing as a lesser activity that slows the release of a project down and changing this mindset is a huge obstacle to get over.
In places where testing is perceived in a negative light, it is possible to move forward, but it will take hard work and use of the power of persuasion, while coaching and building collaborative best practices which a whole range of tech teams can buy into.
Improving the Perception of Testing Across the Business
When thinking about the need to move the view of testing forward, it’s really important that a number of steps are considered to help make it a success.
1. Define your End Goal
The most important decision to make when changing the perception is deciding what the goal is that you are aiming for. Is it just a more positive perception of what the Test teams do? Or is it a collaborative approach to testing where everyone is able to get involved when needed? Whatever the decision is, cementing this and having this to work towards is crucial.
2. Communicate what Testers Do
There may be common mis-conceptions with what Testers or QA do, what they are responsible for and what motivates them. These may come out in conversations, but in worse situations, assumptions will be made that Testers don’t need to be involved and therefore decisions are made without any testing input.
My personal way to deal with this, is to face this head on, any opportunity I get to talk about testing, I will. Within two months of joining my current role, I was presenting at an internal meeting to the whole technology department about “Growing a Culture of Quality” which involved talking about:
The common mis-conceptions of testing
What testers actually do
Showing where Testers could work collaboratively with other teams to improve quality
Highlighting the concepts of Testability and Continuous testing throughout a project
Inviting the wider business to join some lunch sessions with TestSphere
This set the groundwork for moving the team forward and eradicating any possible mis-conceptions of what testers do.
3. Spend Time Sharing Best Practices
TestSphere cards are a great activity to get conversations about testing going. I used these both internally within the Test team and also with the wider business to get folks talking about testing activities, and start to suggest ways in which activities can be incorporated.
By making yourself approachable and available for discussions, you will find that those chats over coffee become working meetings where suddenly “can you show me how we could test this more?” or “how can i create a set of tests which i can re-use?” become questions you will hear from non-testers who want to improve the quality of their work.
If you’re in a place where you have collaborative teams who work with you on the testing activities, embrace this but also look for the ways in which the communications could improve and with that, the testing activities could become even more effective.
Finding opportunities to share knowledge is a huge passion of mine, I firmly believe if I can help improve just one persons testing ability, I have done well.
I’ve run interactive workshops on identifying tests, where I’ve looked at heuristics, using TestSphere and other ways, rather than just the ISTQB defined techniques. Broadening the thought process has inevitably improved the testing quality. Running the same workshops with the wider business will help embed the knowledge wider and testers may find opportunities to help testing activities in teams where they weren’t aware they were even needed.
4. Share, Share, Share
Find ways to share blogs, webinars, conference talks and more with the test teams and the wider business. Build a passion from quality within the team and this will expand organically across the organisation. Not every tester is active or even aware of the online community of testers, none of my current team had heard of the Ministry of Testing or the Test Automation University until I signposted them to them, now people are attending events, webinars and taking courses when they have the opportunities.
I’m sure it gets annoying for some, but I’ve blogged several times internally on the company wide blog about testing and can also be seen occasionally wearing MoT or other testing t-shirts around which always guarantee questions from curious folk and yes, you guessed it, another chance to share even the smallest amount of knowledge.
5. Define New Processes and Prove the worth of Testing
Spend time learning the way things are done currently and understand why. Once you have that grounding, you can then explore options to embed new processes which may bring testing activities earlier or make quality part of discussions from the beginning.
One success I’ve had here is incorporating a Testability Assessment of the product requirements before it is “finalised”. This is again a chance for an open discussion with the test team and the wider business stakeholders to understand what is testable from the requirements and what needs more work to be refined and articulated better. This has enabled the team to understand more of the system earlier, ask probing questions which help to design a better system and be able to write more effective tests.
Another area of suggested improvement would be to look at measurable results which show the dial is moving in the right direction, this may be different for the context and organisation you are in, but the important step is again to communicate the metrics purpose and how they are generated widely before first use, so that everyone is on the same page with what it shows. This means the reporting can be more succinct as there won’t be the need to explain what it means each time.
It All Comes Down to Communication
Ultimately, as with most things in our world, communication is the foundation of all things great! A huge part of our role as Testing professionals is communicating effectively. This comes in many forms, but making our world accessible to all is imperative in creating a shared and collaborative culture of Quality throughout an organisation. Yes there will be difficult conversations along the way and some will take longer to come round than others, but stay close to the goal you defined at the start, understand whether you are moving closer to it and enable yourselves to course-correct if needed.
The Tech industry is evolving faster than anyone is prepared for and with that, roles within the software world are in desperate need to change too, no more so than in the Testing world. With the demand for faster delivery, more complex tech stacks and more fluid ways of working, Testing roles and activities need to move too.
Test Managers as they are currently
One role which has been particularly highlighted in the trend of “traditional roles are dying” is that of the Test Manager. Taken from a Techwell article from 2018, this quote sums up the traditional test manager quite well –
In traditional software processes, test managers are responsible for all management aspects of their team. They dole out tasks and assignments, hold frequent meetings to stay on top of progress, review and approve estimates, and often provide technical guidance as well.
This traditional TM role is no longer effective and maybe not even relevant in a lot of companies (not all!), so there is a need to evolve the role. This is coming from a passionate Test Manager who wants to remain relevant and move both myself and my teams forward.
A siloed Test team who are only involved actively towards the end of a project is no longer the norm, so a TM being the only contact to the test team until the test phase is no longer enough. In some environments, it was the TM who provides that early estimate of the test effort on behalf of the team and will then hold their own team accountable to this value, they decide all resourcing, devise plans and communicate progress to the wider business. Their team left in the shadows until something goes wrong during testing or a defect leaks into production at which point the team are thrust into the spotlight.
The knowledge and accountability for testing and quality should no longer sit on the shoulders of one TM. The role of signing off on the quality of a product should not be the sole responsibility of the TM or even the test team and don’t get me started on the term “gatekeepers of quality”.
The Change to Test Leadership
While in some (if not most scenarios), the title of Test Manager won’t change (at least straight away), the underlying role needs to evolve and be fundamentally different. The role ultimately comes down to the following priorities:
1. Building an Effective Team
Identifying what your team needs to be, starts with understanding whether you are the type of leader your team would want to work for. Are your team able to do their best work? Are they set up for success? Are you all working towards the same goal? Do they believe in your testing values?
2. Nurturing, coaching and empowering the team –
Regular facetime with your team should be an important part of your time in the office. It’s not necessary to have big team meetings every day, but being around for 1-1s (ensuring they aren’t pushed out or cancelled regularly) where the focus is on them and their personal development and not project status. Give your team the confidence to feel they are making decisions on your behalf. This only becomes natural to them if you have worked closely with them to ensure you are on the same page and you’ve earned your trust from your team for them to know you will support them. Coaching and mentoring your team on testing and how to effectively communicate to the wider delivery team should be a key part of your discussions.
3. Being an advocate of your team and also of Testing best practices
You should be your teams protection and biggest cheerleader. When their leader is taking a collaborative decision which they have been involved in making to higher levels or other teams, the teams confidence will boom. Equally, when something does go wrong, protecting the team from the immediate backlash and then working with the team constructively to resolve an issue with an attitude of “we’re in this together” will go a long way to preserve the teams confidence and trust in you.
Also, the other part of your advocacy should be to promote testing best practices to the wider business, find opportunities to get the TestSphere cards out with other areas and discuss all the great work your team and the wider delivery teams are doing to ensure high quality will help raise the profile of your teams work and make everyone aware of what testing involves.
It really is important that the team feel you are on the same journey with them and not focussed on your own agenda. Yes you are their manager, but manager doesn’t mean you are above them. Your team are your biggest asset and working with them will make them more valuable
4. Being a servant leader
Management can be a thankless task, but being there for your team has to be your primary objective. Unblocking them so that they can excel should be one of your primary objectives. “How can I help you?” should be a common phrase your team hears from you, and you should always be working with them to improve their testing ability, empowering them to unblock themselves.
The primary goal of an effective leader is something one of the best managers I ever had passed on to me:
PEOPLE over PROJECTS
Ultimately, this means that your primary focus should be building, enabling and supporting your team instead of being “at the helm” and being the sole decision maker for all project work. If your team feel you have their back, they will feel empowered to make decisions that you would agree with.
That’s All Very Nice But What About Getting the Work Done?
In the modern agile or devops ways of working, it is very unlikely that if you have more than a few people, that they will all be working on the same project or the same features, so there may be a need for someone to be overseeing all progress across potentially many streams. This may not be a Test Manager, it may be an engineering manager or some form of delivery manager where dev/test etc is all combined. But there will still need to be someone who is the Test/Quality champion who can help improve the processes from a test perspective across the teams.
Ultimately, this will require you and your team to devise a process where it is easy for you to keep on top of all the moving parts. This may include devising dashboards which highlight progress and testing pain points for you to assist with. It may also mean ensuring you have the right metrics in place for real time testing progress to be quick to access.
Ensuring testing involvement during the whole project, advocating for Testability and other ways to build quality in earlier should be a focus of the whole team, but having someone driving this from a leadership perspective will help move the team forward.
Can I Still Be A Test Manager?
You can, but the role is evolving. The focus should now on your team and raising the awareness of Quality Engineering/Testing, rather than leaving it as a siloed activity and you being 100% accountable for the quality of the product.