17

I'm a software engineer. I work in a mid-sized startup that is growing very, very fast. Overall, I love my job, my coworkers and the atmosphere.

One thing about my company is that most staff have technical background. Even our product managers, QAs, customer support, sales team have engineering background. This may sound ridiculous and unnecessary to some people, but it makes a lot of things very easy for me. I can just go to a support member and explain the bug/feature/algorithm in engineer-speak and they'll immediately understand and respond to the customer in the appropriate human-speak/business-speak language. This enables product managers to design a good tech product. E.g. one of our product manager is EE engineer by education so it's very easy to talk to them about various aspects of my work, they understand the difficulties, priorities etc.

There is one coworker in QA team that unfortunately frustrates me though. I've been working with them closely last few months since we're making a brand new product and I'm the tech lead of one of the parts. Their job title is "Hardware QA engineer". They do know basic things like how to use terminal, read code, basic electronics etc. But whenever we go into more tricky topics like debugging non-trivial stuff, they seem a little helpless. I end up debugging with them for extended periods of time. At some point, they dictate me what they're trying to test, and I run (manual) tests for them. These parts aren't even related to my part of the pipeline. My work is tested and working, but there are other issues elsewhere and to make sure my work isn't buggy I need to understand bugs in other parts too, and since they do it inefficiently, I end up doing the work.

I must also say that I'm definitely not talking about a coworker who's slacking off or anything like that. (and even if they did, I wouldn't care since I'm not any higher position than them; in fact, I'm more junior). I'd imagine for a QA position they have more than enough technical expertise. They understand technical concepts and can perform tests. It's just that they seem to bottleneck the development as everyone else, even in less technical positions, have more knowledge in the field. This frustrates me. How should I approach this situation? I believe since they're doing everything right, I should correct the way I approach this issue?

I just want to make sure I respect my coworker and improve my and company's productivity and make the best product we can make. Any ideas?

Improve this question
5
  • Is your colleague aware of their relative lack of knowledge? Based on your time with them, have they shown proof that they want to learn more that's useful to their job?
    – user34587
    May 7, 2019 at 14:32
  • 1
    I don't understand what you think you can do. You can't just suddenly make someone understand testing and if it's not part of their job (they've managed thus far) then there is no requirement in them learning it
    – Twyxz
    May 7, 2019 at 14:34
  • 11
    Why are you getting into topics about algorithms, with a QA person in the first place? And why debugging and running manual tests "together"? The task should have a clear requirements and "acceptance criteria", you meet it or you do not. QA is responsible to report if no match, or if side effect bugs.
    – Sandra K
    May 7, 2019 at 17:20
  • There exists a serious question of process here - who's responsibility is it to design, validate, execute and report on test cases? I have to design my own test cases, have them validated by another developer, and then they are executed and reported on by non-technical staff, at which point it is go/no-go.
    – user71257
    May 7, 2019 at 22:12
  • “My work is tested and working, but there are other issues elsewhere and to make sure my work isn't buggy I need to understand bugs in other parts too” — if your work is tested and working, that should prove that your work isn't buggy. If not, then the testing might need to be redesigned, or the product might need to be, to provide better isolation between components.
    – Paul D. Waite
    May 8, 2019 at 10:05

3 Answers 3

Reset to default
20

I end up debugging with them for extended periods of time. At some point, they dictate me what they're trying to test, and I run (manual) tests for them.

Please discontinue doing that immediately. It seems somehow they want to depend on you are you are (unknowingly) helping them to be dependent on you. Occasional chat / help is understood and appreciated but that should never reach a point where you're doing someone else's work for them.

I'd imagine for a QA position they have more than enough technical expertise. They understand technical concepts and can perform tests. It's just that they seem to bottleneck the development as everyone else, even in less technical positions, have more knowledge in the field.

This clearly indicates that they are not suitable for their role. There is no excuse for being not qualified for a role / position. You have to either

  • Learn the knowledge / qualities required for a job / position
  • Make way for someone who is qualified.

Suggestion (in the given order)

  1. STOP helping them for all the tasks. Let them work it and prolong or fail.
  2. Try to visualize the overall bottleneck without finger-pointing, to your manager / boss. Also, make a list of occasions where you helped them to achieve the outcome, over and above your expected schedule / jurisdiction.
  3. Communicate the solutions you can offer (ex: any training / orientation session that can be conducted to bring them up to speed).
  4. Finally, re-affirm the fact that due to the bottleneck, the overall team productivity is lessened.

If the upper management is sensible, they should be able to get the "hint" and take necessary actions.

Improve this answer
3
  • 2
    You didn't define this person's role, and neither did the original asker of this question. At a small organization this mismatch can often come from unmatched expectations about roles and responsibilities, and how that might affect a process that wasn't clearly defined to begin with. That doesn't make it the QA Hardware Engineers deficit, that is a process problem. It is not uncommon or unsustainable for a developer to help QA reproduce/diagnose an issue - That could be a valid process, someone just needs to make it clear that it's part of the process if that's the case.
    – Iron Gremlin
    May 7, 2019 at 19:01
  • 1
    The OP might also want to let their supervisor/boss in on the situation. Not to call them out for discipline, but to get them more training. In a good work environment, you can get them, their boss, and the OP's boss into a meeting to discuss training strategies to help the person in question, rather than get them in trouble.
    – computercarguy
    May 7, 2019 at 21:30
  • One thing the replier didn't bring up - if you're helping them, it may actually make the problem worse. Either they are unsuited for the job as written, or they are suited and their work needs to be tailored as appropriate for QA, with all the necessary tooling. It's one thing if they're a test engineer; it's another thing if they just have a flat-out old-school QA background where they're used to breaking things and writing bugs.
    – J B NY
    May 7, 2019 at 23:47
5

They're a hardware engineer. You're lucky they can even write code. That's not a software focused role.

If it's supposed to be a software focused role, it needs to be made clear that a hardware engineer isn't going to cut it. People take a while to warm up to being good at their job too. Try giving this coworker some time. QA doesn't mean not junior.

After being corrected on what a hardware QA engineer does, this person just sound like a junior. For a junior, this doesn't sound like a big deal.

Improve this answer
5
  • 14
    False. A hardware engineer who can't write code has been obsolete for a few decades now. Even if software is never someone's work product there are just too many points in a hardware workflow where being able to write some code to model something, or exercise your project, or make trivial fixes in what someone else wrote is absolutely essential. Someone who can't do that is trying to work with both hands tied behind their back. Further, such an inability would indicate a huge gap in ability to think like an Engineer.
    – Chris Stratton
    May 7, 2019 at 18:52
  • 6
    But in this case you are completely mistaking the job title - a "Hardware Q/A engineer" doesn't design hardware, they test it. And software is the beating heart of such tests.
    – Chris Stratton
    May 7, 2019 at 18:54
  • @ChrisStratton testing software to make sure it works on hardware requires you to know how to do exactly that and nothing more at this point. Another thing to consider is that if this person just came out of school or is unfamiliar with the language they're essentially a junior.
    – user53651
    May 7, 2019 at 19:03
  • 1
    You're interpreting "Hardware QA Engineer" as someone who tests software on different CPUs. That would be a "portability QA" role. I'm with Chris's interpretation: someone who's testing new hardware designs to validate the hardware. The OP gives multiple clues that the company employs people with hardware-design skills, so they're probably not just creating+testing software. Hardware QA means they might have to write software to test any hardware corner cases they think up.
    – Peter Cordes
    May 7, 2019 at 20:11
  • I'd guess the 'Hardware QA Engineer' is not an engineer at all.
    – jcm
    May 8, 2019 at 8:14
1

Either it is the case that Developer's assisting QA is an expected part of the Hardware QA process, or it is not.

If it is the case that Hardware QA should be self-sufficient, this gap in technical capability should be reported to this Engineer's management as a drag on project velocity.

Either way, from your description, it sounds like you're spending a lot of time testing that someone else's code works on hardware. You're the wrong person to do this. The person to do this should be the developer working on that code, not you.

Direct this Engineer to work with the Developers who are directly responsible for the functionality he's trying to test. It should be part of any development process for Development and QA to work together to some degree to make sure the product is tested, but that doesn't mean some arbitrary Development resource, it means the actual author of the code being tested, or at minimum, an individual whose recent work has been focusing on that part of the codebase.

Spending time with QA trying to test someone else's code from a part of the product you don't normally touch is fundamentally inefficient, this particular Engineer's expertise aside. Try to fix that problem first.

After addressing that, if the extra effort to support this individual is still a huge drag on development resources, try to see if you can get this individual to pair with someone else in the QA org for more in depth debugging or reproduction efforts. They will likely benefit from instruction/knowledge transfer from someone who is used to looking at things from the same perspective, and solving the same general sorts of problems. If they are completely unteachable, then that problem will naturally bubble up to the places in the management structure that are best suited to address them, and if they aren't, they'll learn to be self sufficient and you'll no longer have the problem.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .