Questions for Quality Engineers (all help very much appreciated)

🙋 Questions
, ,
1

Calling all Quality Engineers, both those with the title and those doing that kind of work. Please could you answer a few questions for me as I’m interested in learning more about and digging deeper into what Quality Engineers do and their key skills. There are so many varied job descriptions with QE in the title it is very confusing so any help to clarify what is actually happening in the real world would be so useful. Thanks in advance.

  • What do you do on a daily basis?
  • What are the key skills, both soft and hard, that you use the most in the role?
  • What gaps did you find when you started and how did you learn the skills to fill it?

Any other insights on being a Quality Engineer that you want to share are also very welcome such as your background before moving to the role etc. Thanks

8 Likes
2

I’ve been one for the past 8 years or so in 3 different companies/product types/tech stacks/business domains.
My experiences varied a bit hence the larger amount of things I’ve done.

I am quite proud of most achievements and have really good memories about them:

  • Build custom scripts/tools for data analysis, log parsing, in depth investigations;
  • Bug-fixes, small code changes, code peer reviews, refactoring, merges, and other small things like repository/branching management and control, pinpointing bugs in source code, identifying and updating/migrating deprecated libraries; By chance I had when I left one team the second most code changes made during 3 years out of 8 developers.
  • Packaging the solution and deploying to pre-prod and prod environments (been a release manager for 3 years);
  • Automated frameworks and checks creation, pipelines maintenance and integration into the workflow;
  • Functional analysis and feasibility studies for various product changes and ideas, suggesting or providing implementation ideas, with stakeholders and managers - before they even reached the development team;
  • Data analytics and user-application behavior study to identify improvements;
  • Production systems monitoring and deep investigations to identify production specific issues missed (across multiple systems/products);
  • Management of mobile apps in the corresponding Apple and Google Store accounts;
  • Creating PoC and MvP products to backup the unavailable development team while keeping the business continuity flowing and helping gain new contracts;
  • Administration of the integrated payment system platform, template adjustments (and application management);
  • Supporting new architects and solution designers with my broad knowledge of the product (an architect was so impressed that he wanted me to work under his team on a new product as a technical analyst)
  • Technical platform support and managing most of the technical tickets/requests;
  • Reverse engineering several external 3rd party provided APIs, finding how they work, problems, document them and help developers/BA/PM to manage requirements creation and integration;
  • Creating and maintaining product monitoring dashboards;
  • Client/user data onboarding into the platform (custom data mappings/ETL management);
  • Introduce a localization tool, management of the i18n via angular and integration, content translations;
  • Writing, or maintaining specifications and replacing/being the PM for about 1 year in total over time;
  • Supporting internal teams and integrated products in the operations (favorite of the business operations manager who wanted me to replace him when he retired);
  • …and some testing related activities;

adaptability, initiative, leadership at times, collaboration, resilience, critical thinking, systems thinking, learning capabilities, solution orientation, ownership;

I was so scared when I started to go past testing. Then the mindset change/adaptation to other kinds of roles was a challenge. I had to learn plenty of technical and business domain and specific company details from the people around me and most of it alone. I relied on starting to find an actual problem worth fixing, making it explicit, finding the value of improvement, then ways to do the change.

Keep in mind the distinction between old/traditional quality engineering and modern quality engineering work. They sound the same by the name, but behind the curtains are wildly different.
Background: skeptic, critical thinker, explorer, experimenter as a child; masters in software systems engineering; amateur tester/competitor for about 3 years (won several dozen contests); pro tester/automation for 7+ years in different companies, countries, business, setups/stacks, dev & test methodologies / schools(bbst/istqb/rst).

4 Likes
3

There’s another thread on what do testers do and I relate to that long list. On a daily basis my preference is to keep it much narrower to have most of my time on highest value activity.

I’ve got about 8 products I’m testing on a weekly basis at the moment, that may seem high but it allows me to focus on that primary strength.

Daily. Identifying risks, creating experiments, designing best ways to investigate, picking appropriate tools, raising and discussing those risks and providing the team rapid product quality feedback loops. I leverage from semi-structured exploratory test sessions to in my view maximise value of this.

That’s the majority of my days when the team are progressing at speed.

The secondary side will be the coaching, quality planning and helping out on automated coverage alongside that plethora of things in the what testers do list.

Critical analysis and pattern finding when I run into something interesting are likely the main one’s I use most.

The early career gap for me, I came from developer background and had an over bias towards scripted coverage. Blogs and others who had boldy ventured into the unknown really helped me.

The other gap was partially self created as I was in an independent test group for a while that had an over focus on black box testing, some of my code and architect knowledge and skill dropped. I had to make a conscious effort to bring those back to the forefront even when doing hands-on session based testing. On web technical testing 101 was a great starter for that correction of what I had lost.

4 Likes
4

I have been working as Quality Engineer for many years now, although I might not have a correct answer what the role entails. I will share what I do, what I think it means.

As QE who works in an environment with no “command and control” leadership, I need to make sure my team is supported, have all tools and mechanism to deliver high quality software.

What I do is:

  • Help teams understand how to test and what to test. I am leading such discussion in planning and refinement sessions or can do some pair up discussion with engineers
  • Create test data in case we need a new one. If there isn’t, I will find a way to build it
  • Creating the process and optimising it. I am not a fan of testing after developers, so I will teach and encourage them to add unit, integration tests, we brainstorm and do it together.
  • I review PR for my knowledge sharing and also kindly asking to add tests if they are not there; I will work with engineers if needed
  • Building automation frameworks, optimising them
  • Building and optimising pipelines
  • Working with PM and EM to ensure our process serves us well
  • Looking for quality/testing gaps - in the process, in pipeline, expanding testing, mentoring people
  • Helping other departments to work effectively - ops, sales, customer success
  • Soft skills: influencing, communication with a purpose (why we do what we do), mentoring
  • Hard skills: coming up with testing approaches and ideas, development, pipeline building, being able to debug effectively
  • I think the challenge was to get out of my bubble to be QE in a single team to help multiple teams to be productive. To be able to spot the gaps, come up with solution, “sell” it to people, so they understand and invested. Basically effective influence and be confident in my approaches and values.
5 Likes
5

My short summary is that it’s not only about what you do, but also how you go about it. So overall influencing on approach in a delivery setting.

5 Likes
6

A job description from the past. This is to say that they started with the idea of a person to cover multiple things on system, product, project, code, user levels. This initial short requirement grew about 3-4 times only in the first year.

  • contribute to ideation of the product, reviewing and understanding of business
    requirements/functional specifications
  • shape the delivery method of the team, be an active member of the agile team
  • act as a back-up for the functional quality engineer
  • document system features
  • write FAQ, release notes and features description briefs for end users
  • assist in investigating and resolving technical errors in the application usage.
7

Sadly I don’t do this any more since I left full-time work on a team. But what I did do was a lot of getting the right people talking to each other, pairing, ensembling, helping non-testers learn testing skills. I think my biggest value was helping the team build shared understanding up front so that we delivered what the customers wanted and didn’t waste time on re-work.

I think one key skill set is facilitation. For example, when my team suffered from many delivered stories being rejected by the PO, I was able to persuade my team to invest 30 minutes in a quick workshop to see the value of example mapping.

Knowing how to design small experiments is another. So continuing on from that story, they liked example mapping so I proposed trying it for one 2 week iteration to see how it goes. We quickly crafted a hypothesis that included what to measure to see if it was working.

I had programming skills to start with, but, I didn’t need to write code on my own. I could usefully contribute pairing with a developer or working in an ensemble. So collaboration skills, listening skills, all that stuff are key. I learned skills by reading books, blogs, watching webinars, taking training online, going to conferences, and by pairing and ensembling!

3 Likes
8

Great questions, and I am glad you are digging into this. The title Quality Engineer can mean very different things depending on the company, the team, or the maturity of the engineering org.

As a QE Director, I will answer based on what my Quality Engineers do and what I look for when hiring, coaching, and supporting them.

What do they do on a daily basis
Quality Engineers on my team are embedded in cross-functional squads. Their daily work includes reviewing user stories, designing test strategies, and writing automated tests across UI, API, and data layers. They contribute to code reviews, investigate bugs, collaborate with developers, and look ahead for risks in upcoming work. Many of them also build tooling, help optimize CI pipelines, or develop workflows that make testing faster and more reliable.

Beyond testing execution, they regularly sit with UX and Design during design reviews to flag usability or accessibility concerns. They join user feedback sessions and participate in product discovery to surface possible risks and pain points early. Their job is not limited to post-build validation. They help shape quality from the very beginning.

Key skills I look for and see used the most as QE
On the technical side, being able to review both testing and development code is essential. My QEs frequently review PRs alongside developers, not just to validate tests but to look at implementation details that could affect reliability, performance, or testability. They are comfortable pulling down source code, exploring logic, and identifying potential issues before bugs ever reach production. This kind of hands-on debugging and early collaboration reduces risk and strengthens the feedback loop.

Other core skills include API testing, test automation in the language of the app or service, understanding of data flows, and experience with CI systems.

On the non-technical side, strong communication, curiosity, collaboration, and critical thinking are huge. QEs need to ask questions, push back when necessary, and help teams think through quality earlier in the process.

Common gaps and how they are filled
The biggest gap I see is when people come from a traditional QA background and have not had much exposure to coding, system architecture, or modern delivery pipelines. Another gap is understanding how to test beyond happy paths and UI interactions. We fill those by pairing, assigning small automation projects, doing architecture reviews together, and creating a culture where asking questions is encouraged. I also see newer QEs struggle with influencing or speaking up without authority, which gets better through mentorship and practice working across teams.

Other insights
The best QEs I have worked with are not just great testers. They are people who think in systems, who care about the user experience, and who actively work to remove friction from the engineering process. A background in QA, support, development, or data can all be valuable. What matters most is the mindset. Good QEs do not just test. They help teams build confidence in what they are delivering.

Hopefully this helps :blush:

3 Likes
9

What I used to do daily as QA manager: Collaborate with devs and product managers during refinement to ensure requirements are testable, and lot of others stuff more or less as mentioned by others… These days, you can get help from AI for almost any technical task be it coding, debugging, test generation, even writing infrastructure scripts. But when it comes to collaboration, there’s no shortcut. …Soft skills still need practice, reflection..

Two books I’ve personally found really helpful in building those skills are:
Crucial Conversations– great for navigating high-stakes discussions
Accelerate: The Science of Lean Software and DevOps– offers research-backed insights on collaboration, flow, and team dynamics

Would love to hear what others are reading or practicing to sharpen their soft skills

1 Like
10

Thank you for taking the time to answer, very much appreciated.

1 Like
11

Thank you to everyone for your insights on this subject so far. Very insightful.

2 Likes