Defining your Story – Owning Your Quality Narrative

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…

Quality

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

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.

  1. 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.
  2. Your Delivery Team/Department – Quality will be one of the main focus points, not the only one.
  3. 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?

Company

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 OwnershipQA Department
Quality FocusAny discussions around quality start at end of development phase
Value of QualityRegulatory 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.

Growing A Culture of Quality – A Model

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

A Decade in Testing – How did I get 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!

Changing the Perception – Working towards a Culture of Quality

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.

We’re Not Dead! – The Art of Effective Test Leadership

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.

 

 

 

 

Thinking Differently – Embracing Neurodiversity in Tech

Diversity has rightly become a big topic of discussion across many media and in the last few years there have been huge movements globally to try and correct imbalances in the workforce. These have included Race, Gender, LGBTQ, Age and Physical Disabilities. A lot of companies have worked really hard to close the gaps within some of these diverse areas, but for me, one which has been relatively quiet, especially within Testing or even the wider Tech industry is Neurodiversity.

Before I dive further into this, what do we mean by Neurodiversity? (Quote taken from ACAS website  – acas.org.uk)

Neurodiversity refers to the different ways the brain can work and interpret information. It highlights that people naturally think about things differently. We have different interests and motivations, and are naturally better at some things and poorer at others.

Most people are neurotypical, meaning that the brain functions and processes information in the way society expects.

However it is estimated that around 1 in 7 people (more than 15% of people in the UK) are neurodivergent, meaning that the brain functions, learns and processes information differently.

To be classed as Neurodivergent, it usually means conditions such as Autism, Dyslexia, Dyspraxia or ADHD. There may be people within your teams that have one of these conditions and you may not even have ever been aware.

I have certainly worked with high-functioning neurodivergent engineers on both a peer-to-peer level and also manager-employee level. And I’m not just saying this for the sake of this article, but I have been awe-struck at time with how they have solved a problem or asked those questions that no-one else dare ask.

Certainly within Testing, it is not a role which requires uniformity or everyone fitting within the same box, we need out of the box thinkers and actually I found that one of my team was an incredible Exploratory tester, as his attention to detail was incredible but he had lots of ideas of pathways through the software which others would never have thought about. Indeed, a lot of the skills we look for in testing such as “Critical Thinking”, “Attention to detail”, “Seeing the bigger picture” are all things potentially in abundance within Neurodivergents. Although, maybe communication skills and stakeholder management may not be, but it comes to a point where we assess what we really need and can we work around the gaps in other ways?

I grew up with an Autistic sister, so for all of my life which I can remember, Autism has been something I have been very familiar with. This was added to, when I decided to fall in love with my wife, who for years has worked as a teacher in a Special Educational Needs (SEN) school, so I have learned a lot around Neurodiversity without really knowing what i was.

I do also think it is something that, the more I think about it, I have “quirks” which could be seen as “Neurodivergency”. I can relate a lot to my friend and fellow Testing Peer Chris’ blog post about his own self-discovery into ADHD, it could easily have been me who wrote that about myself. Maybe that is why it is an area which has peaked my interest so much?

In the workplace, I don’t feel enough is being done on multiple levels to ever really close the gap for potential Neurodivergent employees to be given a fair chance. 1 in 7 in the UK may be classed as Neurodivergent, but according to research done by Helen Needham for her recent TED Talk, they are 3 times more likely to be rejected for roles…

While I fundamentally believe that we should always hire the best candidate for any given role, are we even aware of untapped talent which we may have not even considered could fit the roles?

On an episode of the Super Testing Bros podcast last year, Lee Hawkins and Paul Seaman discussed their Neurodiversity project where they were teaching testing to autistic students. This was a fantastic listen and a great idea to reach out to a group not usually considered for roles within our industry. But it raises a lot of questions like the following:

  1. How can we raise the awareness of roles within our industry to more Neurodivergent candidates?
  2. How can we make our roles and our industry appealing?
  3. How could we change our hiring process to make these candidates feel able to participate?
  4. What could we do to make our work environment a place in which these potential employees would feel able to do there best work? Or what provisions could we put in place to ensure we supported them and helped them to be successful?

Raising the Awareness of Roles/Skills

As mentioned in the podcast above, Lee and Paul reached out to local organisations and had an Autistic charity take them up on teaching testing to students. So, I guess, in the same way some of us in the industry have started talking in schools and universities, another option would be to reach out to charities who are trying to help get people with Autism careers and working with local organisations to offer trainings of the necessary skills to get into testing or tech generally.

Making our Industry Appealing

As an industry, job adverts can be very varied in quality and detail. These can obviously be interpreted differently by different people, but think to yourself, would you role or company be appealing to a Neurodivergent candidate? Maybe they meet all the required skills to do the role, but don’t like doing presentations or talking to customers, would you be able to accomodate them and find other ways to complete the puzzle? We should see these candidates as a chance to see things differently, would they add something different to the team and make the team better? How can we therefore make these candidates want to work with us?

Making the Hiring Process Accessible

How do we feel our current hiring process would work with a Neurodivergent candidate? Is there any chance it could feel confrontational? How could you make it more accessible? Could interviews be carried out somewhere the candidate feels at ease? Could it be set as more of a chat, rather than an interview? If you know you have an Autistic candidate coming in, read up on Autism and learn about some of the triggers and things an autistic person may find difficult. A site worth browsing to learn more here would be medecoded.com – a site with experience reports and articles from neurodiverse employees and how they work…

Find a way to ensure you get all you need from the interview process but also ensure you’re not putting so much effort into the neurodivergent candidates, that you are neglecting any neurotypical candidates.

Enable Them to Be Successful

Ok, so you have hired them, but now, how do you ensure they fit within the team and the ways of working? Work with them to find a way for them to be successful. You may find the open plan office is a pain point for them, maybe they need a set of noise cancelling headphones to enable them to work in silence? Are there quiet areas where they can take themselves off to work? You may find they have some habits which seem odd to others, but will probably be partly a way of them self-regulating and keeping themselves calm. Make allowances for this and support them to ensure the team as a whole allow for this too. Ultimately, as with any employee, you want to help make them the best version of themselves they can be at work, doing all you can to nurture the talent will go a long way with that.

It really isn’t however about putting a label on these people, a lot are working perfectly fine within the tech industry already, but it is about considering them equally with other talent going for a role and learning a bit about how to get the most out of them, if you do decide to hire.

My Personal Testing Values

As I am currently going through a transition in my career of moving companies for the first time since i got a graduate position 12 years ago, it has really become clear to me how important it is to have personal values not just for your life as a whole but equally for your work life. Having values which act as indicators that something needs to change is a way of knowing when and how to adapt, if you need to.

It was these exact values which kicked me into gear with the career change. I wasn’t living by my working values any more and something therefore needed to be changed.

I in fact have two sets of values which I try and follow for work:

  1. My Testing Values
  2. My Leadership Values

This post will focus on my testing values. I will provide a later post which looks at the leadership values. So what are these values which I hold so close? Let me try and give some detail around my thoughts:

Testing is A Mindset –

    I’ve learned this more as I started having to hire testers, but not everyone is cut out for testing. It may be true that anyone can test, but it takes someone with the right mindset to test deep and test well.

Testing Isn’t just identifying and executing scenarios –

    Testing starts with the questions, with the probing and the digging for information. Ultimately, the results of testing is providing information to the decision makers, we should not be responsible only for a list of pass/fail results, we have so much more to offer.

Testing starts as a project starts

    – We should be involved in conversations at a start of a project, we shouldn’t be left to piece together requirements at a later stage. We should be involved (where possible) in assisting to form the requirements and putting them through their paces before any code is written.

100% of Testing being automated should never be a consideration –

    If I see one more LinkedIn thread on this topic, I will explode. I maybe need to be more open minded somehow, but I can only see automation as a tool to aid a tester, not to replace them. It should be a single tool in a testers toolkit, not someone’s entire toolbox. Good automation also does not just run a series of test cases which would otherwise have been run manually, it can (and should) do so much more.

Test Team and/or Testing is valued as highly as other disciplines within a team/organisation

    – For a long time, I had worked in teams where Testing was seen as the second class citizen in the room. Time for testing was shrunk because the true value testing provided was never given chance to be shown. It’s a case of making awareness of testing a part of our role. All project team members should know what they are getting from testers and there should be the same respect and time given to testing as there is to writing the product code or operationalising it.

So those are what I try to ensure my testing work aligns to and as I took on a leadership role in testing, i have always tried to ensure my team are aware of these values and how they can improve their focus and work based on these

Would love to hear feedback on these. As mentioned before, I will do another post on my leadership values…

Are Some of Us Doing it Wrong?

I love the Testing Community, there are so many opportunities to share knowledge, talk to others, attend events and learn. Of course, there are always different perspectives, different opinions and different ideas and this is part of what makes the community so great!

I had heard the term “Imposter Syndrome” banded about for the last few years and never really felt it myself, but recently, I have not only experienced it myself, it actually brought a sense of “Am I doing it wrong?” and having had some conversations on social media and recently at UKStar, I started to realise I wasn’t alone. To the point that people were deciding to not attend events because they didn’t feel good enough.

This was also inspired by a thread on twitter by @AllCapsTester:

Let me give a bit more context, recently there have been some phrases thrown around:

  • “Test cases are dead!”
  • “There is no need for dedicated Testers anymore”
  • “Everyone is doing Agile/DevOps”
  • “Testers need to code”

Now I’m not saying any of these phrases are wrong, but they are communicated like they are the norm. Of course, there are a huge amount of innovative people in the community that have inspiring ideas and have brought them to fruition, but for as many that are following innovative methods, there are probably just as many who still following waterfall with a team of dedicated QA who write hundreds of manual test cases. Does that make them bad Testers? No. Are they doing something wrong? Of course not. Does that mean we should avoid working for those companies? Probably not.

Don’t get me wrong, there is always room for improvement and I’m sure the above mentioned are improving what they do to ensure there Testing is as effective as it can be. All should be able to appreciate what they do and not feel like they aren’t good enough.

I have also found Social Media is not always the place to have discussions about the above points as it can be quite intimidating. Semantics can be argued over and increasingly can make people feel like they aren’t good enough.

So it’s really a simple plea, when talking about an innovative solution to move the industry forward, please don’t talk about it like everyone is already doing it. Let’s embrace the abilities of everyone in our industry. We are only moving forward as fast as our slowest member, let’s help get everyone to to be the best they can be and feel like they are doing a good job, even if they aren’t up with the latest ideas.

UKStar 2018 – Fuelling the Passion

My first conference since TestBash in 2015 and I had genuinely forgotten the buzz that these events provide. There was a real sense of community, I made some new contacts, caught up with people I had met before and generally networked with everyone who would talk to me.

On top of that, I would also be giving my first talk on the 2nd day, something which typically, I had spent the week or so before stressing about it, but I really shouldn’t have worried.

There were some great talks which I really felt I learnt a lot from and others which have inspired me to do more of this!

Here are some of the talks which really stood out for me:

Christina Ohanian – Growing a Testing community of practice and navigating ‘traditional’ mindsets”

Christina’s keynote really set the tone for the two days. She talked about her journey to where she is now which included some of the hurdles which resonate with me. Hurdles such as the perception that testers are responsible for quality, testers are just there to find bugs and that everything needs to be automated. She gave hope that these hurdles can be overcome and also that working on the concept of a Community of Practice can really help convince some of the ‘old-fashioned’ mindsets which may be blocking progress. I’m hoping to start an internal Community of Practice for Testing and will be using ideas from Christina’s talk to help me get there.

Ali Hill – Learning to Become a More Technical Tester

Ali presented his first conference talk and went through the path that has brought him to his current role at Craneware. It was impressive to see the effort he has gone through to ensure he had the right skills to do his role, especially given he came from a background of a non-technical degree. Ali shared the steps he had taken to become more technical, including getting involved in the Automation Strategies, learning to code enough to help with the API testing, working on Performance testing and having monitoring in the production environment. The key points he made was really about finding allies and pacing yourself, these are key messages which anyone should consider when learning a new skill.

Isabel Evans – Leadership, Fellowship and Followship

Isabel’s keynote at the start of the second day set the positive tone for the day, it touched on some topics around how we could be made to feel in our teams as a tester and used examples of different animals to explain team dynamics. She also talked about the different types of followers and leaders, which I intend to use with my team to find out how we all fit together.

Isabel had a great way of explaining some of the tough issues and touched on mental health issues within work and it was very inspirational to hear her stories of how she has coped in difficult situations.

I also enjoyed talks from Richard Paterson where he talked about convincing people to share stories if they have something to share about Testing as too many people find every excuse not to. James Lyndsay’s hands on session was engaging while understanding the “Basic Pathologies of a simple system”. Marianne Duijst’s enthusiasm during her talk was just phenomenal and the concept of the 24hr Innovation event is something I would certainly love to try. I also loved the concept of the Conversation Track, I attended Yann and Viktor’s session on the Monday and thought the concept and the presentations were great. I especially related to Viktor’s talk aboth the Testing Survival as alot of the issues he mentioned (lack of documentation, having to automate everything etc), were things that are regularly being lived by many teams all over the world.

Both workshops I attended were engaging and I felt like I learned something new – Christina Ohanian and Nicola Sedgwick’s on Day 1 and Isabel Evans’ on day two. Both these provided the opportunity to work in groups with others and get a chance to talk to new people.

Then there was my talk… Part of a conversation track with Joel Montvelisky, I had spent some time with Joel before the conference and also attending the London Tester Gathering on the Monday night to see him talk. Joel is a great presenter and really enthusiastic about Testing and particularly the concepts of Modern Testing.

I loved presenting my topic, and hope my enthusiasm for raising awareness came through. I believe the general reaction was positive and I certainly had a lot of comments and questions which suggested to me, it’s a topic which needs exploring further. The key sticking points which were suggested were that we maybe shouldn’t just be looking at University students as some delegates said, they never attended university and they have since had a successful career. The other point to make was that the skills suggested for #MakeATester were all soft skills and a University would find these difficult to teach. This is something which needs more exploration, but having completed the talk, I have a few more people willing to work with me to keep raising the awareness.

Photo 13-03-2018, 14 28 51

The conference was a great experience and I really can’t thank the organisers enough for asking me to talk and giving me the chance to fuel my passion of continuous learning and growing my knowledge for my career.

A Change in Perspective – Moving from Tech Lead to Manager

I’ve been in Software Engineering since I left University as a graduate in 2006 and have performed many roles such as Software Developer, Scrum Master, Build Engineer and then in 2010, I moved into Software QA. At that point, I had several awesome mentors who I owe so much for fueling my love and passion for all things Testing/QA.

Fast-forward 6 years and I had moved teams and become the QA Tech Lead in my new team which are an Operations Engineering team. I finally got my head around the complexities of the systems we were responsible for as a team and was starting to move the teams focus to processes and ways in which i felt could move the team forward. So at this point, I felt I had got to grips with the production process.

In 2017, I started working towards becoming the manager of the local team and also taking on hiring a new team for a second project. That team were to be located in Ireland and I took on building that team from scratch. Hiring that team was my first real taste of management responsibilities. I had previously been involved in hiring from a “who would I work well with?” perspective, where as now, I was looking at the overall dynamics of the team, how they fit salary wise with the rest of the team and whether there was anything about them that might make them difficult to manage. This really opened my eyes to how things would change with my new role.

Over the next year or so, to now, there were several other parts of the role which opened my eyes to there being more differences than me just taking on line management duty of my team mates.

1. Trusting the team to be Technical

Once I got the Irish team set up, it became obvious that I couldn’t be the technical point of contact for two teams and had to start backing away from the deep down technical details and trust the teams to pick that up. It really became clear that I had to trust my team to pick up the details and I needed to enable to do them that.

 2. Time is for your People

I soon learnt that to enable the team, it required them to be my main focus. Therefore, giving them all time with me, through 1-1s and spending time sat with them at their desks, meant that I started working longer hours to give them the time they wanted/needed and then still performing the other duties i still needed to do. Over time, this has got easier to manage, but with two teams on completely different projects, it’s certainly been a challenge.

3. Difficult Conversations

One element of the role which I needed to adjust to, was having to have conversations which I wouldn’t have previously had to worry about. It really was about working out where the line is in situations and then being strong enough to talk to team members when that line is crossed. Then also being consistent to ensure that everyone is treated the same way.

4. Technical Advocate rather than Technical Leader

With having to trust the team to take on the technical leadership role, it became clear that although I still need to understand the technical detail to some degree, I would give the team the freedom to advise me on technical directions, then be their advocate when talking to others about the technology, ensuring the team know I have their back and support their decisions. While also still offering my opinion and helping to guide the team, the directions of the team would not be down to just me.

5. Someone Resigned! Was it Because of Me?

This was a tough lesson, and caused a lot of over analysing and over thinking. But ultimately, I had to try and not take it personally. Then, secondly, try to turn it into a positive as it would give me a chance to re-build the team in the way that I feel works.

6. No Favourtism

Before I became a manager, I felt I got on well with all the team I worked with, but becoming manager changed the dynamics. Some suddenly started being more formal with me and I couldn’t understand why as I hadn’t changed. There were some members who I found very easy to talk to, but I had to show that I valued all members of the team. That meant backing away from socialising with them regularly over lunch or out of work and only really doing so when all the team is present.

The Future

I love my role and I love the fact that I am learning and developing every day. I value the work my team are now able to do, with my guidance and seeing them become more self sufficient, means I am starting to be able to focus on more strategic work and still see my teams move forward, knowing I have their back, encouraging them to do the best they can.