How to not be "this annoying nitpicking Quality Engineer"?

Question

I am a 23-year-old woman who was hired 2 weeks ago.

As a Q&A engineer, I have to ask developers to change the way they are coding in order to improve the code's quality, maintainability, and testability. People do not like being asked to change their code, and I am afraid they will resent me for doing so.

Question

How can I make such a request while minimizing the risk of being seen as an annoying and nitpicking person?

Background about the company

• The company didn't have any Q&A before.
• The company is about ~30 people with ~15 of them being developers.
• The employees are all mostly young (I'm terrible at guessing age but they have small children)
• I haven't seen the delivered code yet and will use SonarQube to make sure that the code fulfills the minimum quality criteria. However, I have already had to ask them to add "id" for all the button and field HTML elements (I needed it to automatize User Interface test).

What I'm doing now

I have only had one request for now. I went to one of the developers and turned my request into a question because I have noticed that people seem more accepting when they are asked this way.

So I asked:

I am not able to find the id attribute for this element. Is there any?

The dev looked for it, said it was missing and that it was a mistake. But they seemed annoyed by the idea of needing to fix it and started explaining to me that I don't really need it.

After that, I kind of panicked and agreed that I will try to do without it for now. However, since then I have had to ask for this twice (because I realized the issue was more important that I first thought it was). The developer looked kind of annoyed at me each time I had gone to ask him.

Note and clarifications

• I could do without the id by using a more fancy selector. However, this will reduce greatly the maintainability and readability of the tests which I don't want to do.

• The dev asked me why I needed the id and I explained it to them (but it's possible that I have done so poorly).

Answer 1

Note: I'm a 25-year veteran of software development as an engineer and tech lead.

A good QA engineer is worth their weight in gold to a dev team, and part of their job is to be nit-picky - but on specific things.

There should be an expected outcome for a delivered piece of functionality - in this case, the interface is a UI. A QA engineer should know the expected outcome, and check the delivered functionality against the expectations. If there are any differences, you document them in whatever fashion is agreed (bug report tool etc) and provide as much detail as possible - at minimum, the expected result, the actual result and the steps to reproduce the actual result.

Sonarcube etc checks code quality, which in my view isn't part of the QA engineer's responsibility - the senior devs or tech lead should be picking up on this.

Asking for IDs on buttons and fields to allow automation is an entirely reasonable request, and if the devs are reluctant maybe it's because they don't realise the benefits of the automated testing? You could explain to them - maybe a quick presentation, with working examples, would be good - good devs will realise quickly that anything that checks for bugs early in the process will ultimately make their lives easier.

Focus on the things you're tasked with - software accuracy, conformity to the requirements, automation of the testing. Deliver this and people will see your worth to the process.

Answer 2

^{background: I'm a young software developer}

Explain to them why they need to change the way they code. I assume there are good reasons for why you ask them to do so.

"Code quality, manitainability, and testability" are terms that sound like insults to the devs (i.e. "your code has poor quality"). These terms are too general and are usually not received well.

Instead, explain in full detail what the problem is and why you need them to change certain things. This will either make them understand, or at least mitigate their anger/annoyance towards the decisionmaker (i.e. the person who decided you need proper tests. If that happens to be you, you can also explain the need for the tests). Using the example of testability: Explaining your issue like this will wield much better results than general critique on testability:

I have noticed that certain important HTML-Elements do not have an id-property. I know that they don't necessarily need one for our application to work, but without them, we can not create proper tests for the UI, which have been demanded by decisionmaker XY. Therefore, I need to see id properties added to this, this and that element, as well as on all buttons and input-elements in future views. I understand this requires more work on your side, but it is necessary for proper testing of our application.

TL;DR
Get the developers to understand the reasons for the change in coding. When they understand exactly why you ask this of them, they will no longer hold a grudge against you.

Answer 3

The way that developers are coding is frankly none of your business. If you try to make them change this, you will get nothing but a bloody nose (figuratively speaking). What's your business is the quality of the product, and everything that helps you doing your job or makes it harder. Developer's code is not part of this.

If there are no processes in place to facilitate QA, then sure, create these processes, discuss them with anyone involved, implement them.

If there are product features that would help you testing, sure, identify these features, ask for them, and they will be prioritised like other feature requests. If there is anything you need, ask nicely, and in a reasonable team will help you if their time and other priorities allow it.

But telling developers how to do their job will make you lots of enemies, no matter how you try to do it.

As far as "nitpicky" is concerned: You are supposed to be nitpicky when you check that the product does what it is supposed to do. "Nitpicky" is a positive quality for a QA engineer. I have one QA engineer who is not nitpicky, but absolutely evil, and it helps a lot improving the product quality.

And if a product has lots of little faults that only a "nitpicky" QA engineer complains about, then customers are a lot less forgiving if they run into big problems. Another advantage of the nitpicky QA engineer: Developers often know about small faults and would like to fix them but have pressure from management to do other things. That developer may be grateful for you to create a bug report, because now they can say "I must fix this, because QA complained" instead of "I would like to fix this, because it doesn't look quite right".

After your additions: If developers look annoyed about extra work, that's normal and nothing to worry about :-) But you need to investigate how work is handled at your place.

If you just say "I need XYZ" and the developer takes a day to do XYZ for you, then it looks to his boss as if he hadn't done anything all day. At my place, you would fill out a request, I'd do the job, I mark the request as "done", and I can say to my boss "no, I wasn't lazy all day, I did this highly important thing that Noon needed to do her job". That makes all the difference.

If your place isn't well organised that way yet (and having introduced QA just 2 weeks ago I might fear for the worst), that's something that needs doing. It's probably something where it would be worth taking the initiative. The important thing is that you create extra work for developers (and that is exactly your job), then it must be done in a way that is visible to the boss.

Answer 4

I am speaking from the point of view of a DevOps Lead/Software Architect with numerous experiences collaborating with QA folk, including automated QA.

My official answer to your question is to pick your initial battles carefully, and eventually increasing the scopes of your initiatives to make the impacts you desire and know to be good.

My meaning: add code quality initiatives that have the fastest payoffs before long, slogging campaigns. Adding id to things in HTML is a good example. It makes the code testable in an automation environment, and should be quickly realizable.

Code quality has long term benefits, but at short term resource costs due to it being work that is not usually seen as productive (for certain definitions of productive: i.e. "getting new features done").

In an established code base, getting code quality up across the board is a tough sell. I also advise a more strategic, piecemeal process, as it is already working code and changing code incurs risk.

I recommend finding a few shorter initiatives that demonstrate benefits, at which point the devs are more likely to realize that your initiatives are not simply pedantic annoying rules to follow but rather activities that will have a benefit to them long term.

I also highly recommend minimizing front-loading and boiling the ocean by putting too much backstory and background behind why you are doing something. Code quality is important and good, but many people find it uninteresting.

And it is essential to come up with a good way of delivering initiatives. Prefer statements like "Please do Y instead of X" rather than "Don't do X, do Y." (If you observe carefully, this very sentence is structured according to the guideline it espouses).

Answer 5

Ok, we have here now already a lot of answers giving advice concerning your question from the professional engineering and workplace aspects. I can more or less agree with all of them so I will keep in that regards my 2 cents for me and try to just give this answer considering the interpersonal point of view for your situation.

Disclaimer: Being on the autism-spectrum I might go into details that most won't even see as a problem. But since they were/are problematic for me, its the backup for my way of handling it.

So, the first contrast I am seeing here from most of the answers contrary your situation is, most people answering are professionals with prior experiences in QA. As long not most of the employees in your company are senior developers, you can assume THEY don't have such prior experiences.

In my previous jobs I had always been "that nitpicky annoying coworker", but that was primary cause QA wasn't my job. The interesting thing I can tell you from back then is: People usually didn't disagree with me. They were just in a working culture not caring of quality and hence found someone caring for quality a restraining noise.

So keep in mind this might be the case at your work, too (Even if apparently it is supposed to be changed).

Let me tell you a little about my current job position. I know this is something that neither you can't implement alone nor is it a cultural change that can be implemented on short terms. But it might give you an idea of how to not be the nitpicky annoyance, if company's upper level is on your side¹.

So contrary to my previous jobs I am now working for a very large company, spending a huge amount of resources for quality. I am not directly working in QA but as license compliance analyst, so in a break down it is still my job to validate other peoples code. Here actually any product has to pass our checks before it is allowed to be released. There are documented requirements a product has to meet, to be able to be checked by my team and all we need to do is checking it and giving approval or rejecting it. So it is not us deciding what hast to be checked. This has the result, that project teams aren't seeing us as the guys disturbing their deadlines, but rather ask us for help if their project isn't passing our analyses and they can't figure how to fix it².

So taking this well working procedure into account, I would advice you the following:

First, and especially most important for me due to being an autist³, make sure to be certain about what is expected from your role. Despite nitpickyness is a good trait for an QA engineer, your company might have a wrong idea of what the responsibility of an QA engineer should be.

So make an appointment with your superior, and ask them to give you a clear definition of your responsibility in your role. Try avoid telling what you think your responsibility is about and asking for confirmation and rather let them explain their idea. Try to see their explanation fully separated from your own idea of what your responsibility should be, if you find it incomplete ask for clarification, but don't argue.

After that, write a proposal of your responsibility. Again just how you understood them, not what you think it should be. And then add a section to that proposal stating what is NOT your responsibility. Here you can add all the parts you think that should be part of your role, but have not been mentioned. The more you feel uncomfortable with something not being part of your role, the more dramatic my wording would be⁴.

Give that proposal to your superior and ask them to approve it. Eventually adapt that proposal till its getting approved and voilà, you have a definite classification of your responsibility.

This gives you certainty in 3 ways:

• You know what aspects of quality are important for the company and hence what you have to care for.

• You don't need to worry about what you find important regarding software quality, as you have explicit written advice not to consider these aspects. This is also useful, to avoid being blamed in the future for not having taken care of these measures, as you have written advice to not to.

• Most important regarding OP. It is not your personal opinion of quality anymore but a written treaty of what is the company's opinion of what should be assured. So you can't reasonably be blamed for it anymore. Or if it is part of the "not to"'s, neither you nor the developers have to bother, as the company clearly expresses not wanting that part to be covered.

---

¹ What I hope they are, as otherwise your employment would be a farce.

² Well, I am quite sure within their teams they still see us that way. But the point is, we don't have to tell them how to fix their code, rather they have to ask us what to do if there are problems with the code making it not pass our explicit defined and documented checks.

³ I just realized how much here can go wrong, when I came into a working environment where fortunately everything in every aspect is documented, and I noticed how much room for misunderstanding there had been in my previous jobs by the lack of such policy.

⁴I don't know if this is a good or bad advice, its just what I would do.

Answer 6

I'm a developer (C++) and often I'm facing exactly the same problem. I'm a bit older (26) but still comparatively young. Our team consists of 5 people with an average age of 35. I'm the only one in our team who really cares about good code in terms of readability, maintainability and consistency. 3 of us are doing this job since 6-10 years and they have their (partially bad) habits.

When I try to convince them, yet I had the best success by explaining to them the benefits of changing specific coding behaviors. It's very important that you don't criticize them, but make the new style more attractive, because nobody likes to be told he is doing something wrong.

Your example I'd approach like:

Hi, your naming convention is understandable, though we can improve it by adding "id" to the identifier. This way it will be very comfortable to iterate through elements by finding all lines containing "id". Also we would have a better overview when using autocomplete/intellisense.

I experienced I very rarely have success if my suggestions sound like critics. If you know your suggestion is a real improvement, you will find good reasons why. Just never be personal but show the benefits over the actual coding style.

Answer 7

^{Background: I have 10+ years of experience in management, 19 years working in an IT environment, and my current role of 2 years is part of a development team.}

You may be right about how some developers may react to having their work checked, but as you appear to have a technical background and are using technical solutions to implement such checks I think you will probably be fine.

Development is only a part of my job, so I may be way less technical in my answer than some others, but I've seen my own environment change from one where there were almost no controls in place and developers were in pockets around a large organisation, developing with complete autonomy in their own style, to a properly controlled environment using Git repositories, version control etc. These things were quickly embraced by developers, because the one thing you can say about most developers is that they love keeping up to date with the latest tools. Having control measures brings a measure of administrative burden, but also many benefits, and as a technology in itself is pretty "cool" :) The same may well be true of you introducing things like SonarQube, the developers may love it.

My advice would be:

1. Make it all about the code, not about the individuals.
Make it clear from the start and in all you do that your role there is to oversee the quality of the code, not expose underperforming developers.

2. Be technical. But don't bluff
I've seen it dozens of times - people come to work in an IT environment and they are so scared of knowing less than everybody else they try and bluff their way through tech talk. Don't. You only end up looking stupid. Everybody has their strengths and weaknesses, so be assertive about what you do know, but honest about what you don't. Invite people to help you fill in any gaps in your knowledge. Many developers love an opportunity to speak about what they know, and you'll come over more approachable if you're humble enough to admit you don't know something.

3. Turn any new measures or controls you introduce into "personal development opportunities".
Many other organisations already have in place many of the measures that you will introduce. So rather than make them feel like you are introducing administrative burdens on them, "sell" the changes to them as something that will develop them personally. If they go for a new job elsewhere in the future, their experience here will be a big decider. Being able to say they have worked in a properly controlled environment with QA checking in place is a feather in their cap, so to speak.

4. Maintain your authority
Balance all of the above with maintaining the level of authority expected of you within this role. Managers who try to be friends with their staff usually find their authority is undermined. Although you may not be a line manager to the developers, you have a job to do, so make sure they don't prevent you from doing it. Sure, your stated goal is to avoid becoming a "nitpicker" and irritating the people you work with, but career-wise you may want to be more attentive to how you fulfil the expectations of your role and please your bosses rather than being accepted by the developers as "one of them" when actually you have a different and distinct role.