Introduction
Recently I thought to myself that I spend the majority of my time not really thinking about testing as my role involves me stepping into the shoes of the product owner, the agile coach, the release manager, and the tech lead. Throughout this article, I will explain more about what I mean by this statement. Although my experience is centered in and around software development, I also contribute towards developing best practices with the senior developers, discussing architecture with the software architect and continuous integration with the DevOps engineers, and reviewing each PR whether it be backend, frontend, infrastructure as code or user stories. Often, titles can be misleading when it comes to what you actually do day-to-day. Job descriptions only tell half the story!
Currently, I am the QA Lead at a homecare start-up called Cera Care. Working in a start-up environment means that my role involves getting hands-on as well as managing a team. Being a QA Lead doesn’t just involve thinking about test plans and test automation frameworks. In order to embed quality within teams, the role requires me to get involved in product, delivery, development & DevOps. Influencing all these areas involves understanding things from their perspective and talking their language. The way that I have been able to influence these conversations is through getting hands-on myself, pairing with experts in the area and ultimately being involved in the conversation, attending a lot of meetings.
What People think QA Leads do
QA is a field that is often misunderstood and undervalued. The perception can often feel outdated or not prioritised as much as other disciplines.
What people think we do: write test plans, draft test strategies and discuss testability, advocate quality, run post mortems and encourage developers to improve test coverage. Yes, I do these things but this is only a small part of my job. Attending meetings does take up most of my time to understand the product and priorities of features. Also, people expect me to think on my feet and identify the risk quickly for urgent releases due to everyone thinking about testing late in a project.
I am in a fortunate position where my manager, the director of engineering, allows me to drive the QA strategy and has backed how I am building the team. This means we only write single-page test plans, implement a high-level test strategy for each individual team depending on many factors and I work with some amazing Tech Leads who advocate for quality with only a gentle reminder from myself.
What People want
Really what people want is to reduce the testers and create efficient development teams who are autonomous without the testing bottleneck. I do agree with the Modern Testing Principle no. 7 which promotes this view. However, this requires a very mature development team and this is not an overnight change, therefore, the need for testers is often required for longer than people ideally want.
What people expect from QA involves: estimating how long testing will take on a feature (very hard to do), testing “everything” (impossible to do), making everyone a testing expert (long term project), automating all tests (also impossible to do).
Testers offer so much more than these expectations and the quality of your product is greatly improved with their contributions… Not saying these things aren’t nice goals to aim for but as always it comes down to the context you are working in. For example, working in a startup you cut corners to get the product to market, and on the contrary, working for a healthcare startup, you also have to sustain a high level of quality to retain patient safety.
Many hats of a QA Lead
On a project with a Product Owner, Agile Delivery Manager, Tech Lead, Developers, and QA, cross-functional members are essential to moving it forward by offering another point of view or simply being a sounding board. Being involved in building user stories to technical implementation discussions means as a tester you can understand the software from all points of view. Not only does this build trust with the other members of the team but also allows you to influence quality right from the start.
Shifting left is therefore not just about moving test automation down the pipeline but starting communication earlier in the development process. I will be talking about these hats in reference to my current team setup at a startup that may differ from others.
Hat 1 – Quality Advocate
This involves talking about testability and asking the question “how are we going to test this?” A lot!! Constantly I am trying to get developers to think about how to start testing before it gets to the integration environment when they forget about it and pick up the next story. Also by raising this in the refinement with all stakeholders it means the product owner to business analyst think about these requirements the next time the story comes around.
Hat 2 – Business Analyst
Currently, we don’t have BA’s so it falls on other members of the team to adopt this hat from time to time. Product owners go out and do the research and write the user story, the tech lead gathers the technical requirements. And then I adopt the BA hat to add scenarios to the acceptance criteria, review the technical requirements to ensure impacted services or downstream systems have been considered.
Hat 3 – Software Architect
I am lucky to have been a cross-functional team member in the past and have worked closely with a couple of awesome software architects in the past at CRUK & ASOS. Everything I know comes from their attention to detail and involving the whole team in their decision-making. Therefore in my current role, I often question the proposed architecture or throughout the development of new features highlighting gaps or improvements that could be made in relation to performance or ease of testing.
Hat 4 – DevOps Rep
Currently, we have a DevOps function but their resources are spread thin and are not assigned to a team full time. Therefore, whether it be making changes to the pipeline in Azure or considering environment setup often falls on the engineers. Again cross-functional teams are the end goal with this approach and are a steep learning curve, especially in a fast-moving startup.
Hat 5 – Release Manager
Often as the last line of defence, the release notes and “sign off” (which is not the correct term or the correct responsibility of the QA but the whole team…) fall on the tester. This means they are also in the best position to kick off the release train. This hat is one I always try to shift to be a team responsibility and also shift the release notes to be automated via Jira or move to the Product Owner.
Conclusion
The thing about being a QA Lead within a startup is that you have to be able to review the Tech Leads work, help the Product Owner write user stories, be a junior architect to analyse the software vulnerabilities, and be hands-on working on test automation while you are at it. As a QA Lead you are often the hidden figure, someone who makes conversations happen, prevents incidents from happening, thinks about the production monitoring before you need to investigate something.
All these things often go unnoticed or even sometimes unused as you may never need them or the incident may never have occurred with the real users. Therefore it can be hard to sell these initiatives to the business stakeholders or for people to prioritise them over new features.
Thanks for reading my article, if you want to learn more about testing in microservices check out my online courses at https://pactman-consulting.thinkific.com/, podcast https://www.pactman.co.uk/podcast or my blog https://www.pactman.co.uk/
Article written by Lewis Prescott, QA Lead at Cera Care
Interested in QA? Why not register for our upcoming National Software Testing Conference 🤩
