Post

Context for working with software quality

I’ve recently been exploring what the differences are, between the role of a Quality Engineer, a role I’m currently inhabiting in my work at Ada Health, and other roles in Software Quality.

One of the realisations I had already, that probably isn’t news to anyone who has worked multiple jobs in any role in technology, is that the way different roles actually work, the expectations and reality, is very different from company to company.

Where you work, makes a huge different to the opportunities you have to explore and execute on different parts of your job, different tools from your tool box you get to use.

You may already know this, especially if you work in software and especially if you work in quality, context matters. But what do I mean by context? And what do you mean by context?

In this post I will discuss a few key points that have mattered to me, and setting my context, in different companies and teams. Naturally your experience will be different, it must, your context was different, and it still is! But you might find some of what I say relatable, and I hope you find any of it useful.

Consultancy vs product company

Consultancy context

I worked for two years, in a small software consultancy company in the UK. The model was simple, the company had a number of clients, with different contracts for different types of work, depending on their needs. The way quality and testing was handled for this different clients was not uniform, but depending on the project and the contract we had with the clients.

The biggest contextual impact here, is how work, and therefore any changes, were paid for. Find a bug that stops us from meeting the acceptance criteria agreed with the client, that’s on us! The bug is likely to get fixed, and probably pretty quick, because it might stop us from getting paid. Run! Go fix that bug now!

Is it a bug in requirements? Maybe a whole missing feature? uhoh! This means negotiate a change request with the client, and getting them to pay for the work. Sometimes I would advocate for our clients, that the missing functionality is something we should have specified and flagged early, and the client had a reasonable expectation for it to exist, sometimes, I had to help explain the bad news to the client. Either way, it definitely impacted how I raised issues, and how I had to relate these issues back to the tickets and specifications, I HAD to, or call it our as potential missing work.

Also, I had to be careful what testing I did, how long I spent doing it, and how the testing was recorded and reported. Some clients wanted test scripts, to have as regression packs that we would hand over. Others, didn’t want to pay for testing at all, so I had to talk with project managers, to convince them it was worth our time spending our money for me to do testing, even if it wasn’t a billable line item.

I understand this is not the only consultancy model that exists, I have friends who have worked for larger consultancies, where they have been effectively loaned out to companies for entire projects. In some of those projects, one might not be testing work that built by the consultancy, but by the client or even a different consultancy. You might be providing specific, or specialist testing services only. I haven’t worked in this context, but I know it’s out there.

Product context

Contrast that very commercial, consultancy context, with the one from working for product companies. Most of the companies I’ve worked for, have produced some kind of product or service that is sold, either to other businesses or directly to consumers, or a mix of the two.

In the companies I’ve worked for, the teams have been somewhat fixed, apart from the occasional re-org or individuals leaving or joining for their own reasons. Most of the products I’ve worked on have been in some way long lived, they haven’t been project work that was handed over once shipped. Rather software was maintained and developed by the team who built it.

Bug advocacy in this context is very different, it’s about balancing the priorities of building new features or products, vs improving existing ones. Bugs in production are a big deal, considered incidents and the team jump on them with high priority where appropriate. This doesn’t mean all bugs are fixed, and often pragmatic choices have to be made, recourse is limited, but it’s at least all under the control of one organisation.

In my experience in this context, larger systems are typically split into smaller parts, owned by different teams. This creates long lived dependencies, and necessitates long lived relationships across teams. Some companies I’ve worked for have had different teams cover the testing of these integrations between software built by different teams, or integrations with third parties. While others have left it down to the choice of individual teams, to work out the testing and development coordination.

Overall, in my career so far, these have been some of the most impactful differences in contexts between the different companies I’ve worked for.

In a quality team vs in the development team

Once at the start of my software quality my career, I worked for a company that had a team of testers, in fact in this case multiple teams of testers at different levels across a large organisation, with dedicated leadership. Even at that organisation, over time they transitioned away from this model, and I became embedded into a software development team, while the company took on an agile transformation.

My context in all other places I’ve worked, is that I’ve had a home directly in a development team, and either been the sole person with a testing and quality specialism, or had one other person join me.

I’ve encouraged, supported and engaged in various communities of practices in these contexts, some of them explicitly for quality or testing, and others for specific topics such as accessibility. In all cases, I’ve done some work across teams, and with other testers, but my day to day has mainly been testing on my own, or pairing with developers, designers, product managers or even doctors.

Quality team vs development team significantly influences the way you work, from how work is allocated to line management, and in fact I’ve rarely been managed by people with testing experience. One of the results of this, is that I’ve had to be very self sufficient in planning my personal, technical and professional career growth.

Technology company vs engineering department

The third thing that has had a huge influence throughout my career, is the contrast between working for a technology company, or working for a company that happens to use technology as a strategic part of their wider business enough to have a technology or engineering department.

This makes a big difference, from how stakeholders and management influence the work to be done, to how well the company understands the business domain they are operating in.

It also impacts salaries, benefits, and freedoms. In my experience, technology companies as less worried about what you wear, or when you work, and more worried about how you deliver your work. They also understand how engineers progress in their careers better. They also understand the kit needed to do the work better, and have less restrictions, and more trust.

Where as business that have their own thing going on, and their own culture outside of technology, tend to have some restrictions that can be very wired to us folks in tech. From things such as admin rights to install software on your own machine, to the cloths you were or when you can take vacation. The upside, is that technology is often enabling a business model that is in someway independently successful. You also tend to have experts who understand what the business wants from the technology.

Your context will be different

Of course, this is my experience, from the limited number of companies I’ve worked for. And, I’m me, other people working at the same companies will have had their own experience, you are a big part of your own context!

I won’t get into detail here, but that industry or domain your business operates in also makes a huge difference, from regulation and compliance, to operating model and funding.

If you take away one thing, please let it me that taking the time to thoughtfully think about your current context, what makes it similar or different, can help you better understand your day to day work.

This post is licensed under CC BY 4.0 by the author.