Unveiling the Mythical Creatures of Software QA Job Descriptions: Navigating Unrealistic Expectations in a Tech Wonderland

For the past 5 years, I’ve developed a habit of regularly scouring QA job listings. It’s not just a pastime; it helps me gauge the trending technologies and assess how well my career aligns with the market. Lately, particularly in the last six months, I’ve noticed a trend: QA Engineering job descriptions seem somewhat unrealistic. I’m not even sure who sets these requirements. Is it the HR department acting alone, without input from a hiring manager? Or perhaps it’s the VP of Engineering? Maybe even a QA Manager? Honestly, I don’t have a clue. But when I read a job description that expects a QA professional to possess the following… (and I’m quoting verbatim here):

These are some of the requirements (Minimum and Preferred) for a QA Lead position:

• Experience with software development in one or more programming languages, or an advanced degree.
• Familiarity with data structures or algorithms in either an academic or industry setting.
• Master’s degree or PhD in Computer Science or a related technical field.
• Experience with web and mobile test automation.
• Proficiency in performance, load, and accessibility testing.
• Experience developing accessible technologies.

You might argue that these expectations are reasonable for a QA Lead position, and I’d partially agree. But being an expert, or at least very proficient, in data structures, multiple programming languages, web automation, mobile automation, performance testing, load testing, and accessibility testing requires years of experience or significant exposure to various technologies. Let’s put it this way: you don’t expect a web developer to also be a mobile developer. Typically, you’d have separate roles for back-end developers, front-end developers, iOS developers, and Android developers. Sure, there are full-stack developers, but even they have their limits. And that’s not all. On top of everything else, QAs are now expected to have DevOps knowledge, along with proficiency in API testing, UX, and sometimes even domain knowledge.

Now, let’s consider another example, this time for a Test Engineer position:

• QA experience with mobile and web testing is a plus, along with proficiency in automated testing techniques throughout the software development cycle.
• Experience with various frameworks like TestNG, Appium, Selenium, Cucumber, etc.
• Strong object-oriented programming skills, coupled with coding and debugging expertise.
• Proficiency in Java and/or Python.
• A strong customer focus, exceptional problem-solving skills, and analytical abilities.
• Ability to work across different operating systems like Windows and Linux is a plus.

While this position seems more realistic, the expectation of blending automation testing techniques for both mobile and web testing still appears excessive to me. I’ve been in roles where I had to handle automation testing for both web and mobile platforms, and let me tell you, mobile automation demands significantly more time and effort than web automation. Don’t get me wrong; I enjoy working with both. But what bothers me is that being an expert in both seems to be the norm these days, and to me, that’s unfair. While having strong technical skills and a customer-centric approach in QA positions is crucial, companies should understand that meeting these requirements requires considerable time and dedication. When I see all these technical requirements, it raises questions about how one can consider customer needs while juggling responsibilities such as building automation tests for both mobile and web applications, maintaining the automation for both, ensuring the robustness and reliability of tests, managing the pipeline, defining proper test strategies aligned with customer flows and behaviors, and participating in agile meetings.

Furthermore, these demands can lead to employee burnout, talent shortages, or even have negative impacts on product quality. Now, let’s examine another example, this time for a Test Engineer position:

• Experience validating acceptance criteria and utilizing Behavioral Driven Development or similar approaches.
• Experience building and/or maintaining automated UI and/or API tests.
• Knowledge of non-functional testing.
• Familiarity with engineering practices and coding standards.
• Leading one or more teams through the Software Testing Life Cycle (including shift left and CI/CD).
• Ability to research and learn new test tools and techniques.
• Excellent communication skills.
• Dedication to self-development and mentoring others.

In my opinion, this is an excellent set of requirements for a senior position. I believe a senior QA professional should possess a solid understanding of UI and API test knowledge, along with expertise in automation that aligns with CI/CD practices. They should also be adept at mentoring others. As for non-functional testing, I’m a bit skeptical, but I believe seniors can figure it out, given their consolidated knowledge and experience. By this point, they should be capable of expanding their knowledge into other areas of testing.

Now that we’ve discussed the challenges faced by QA professionals, let’s consider some potential solutions. Here are actionable recommendations for both QA professionals and hiring managers/recruiters:

For QA Engineers:

• Continuous learning: Stay updated on emerging technologies, tools, and best practices through online courses, workshops, and professional certifications. Focus on your main domain, whether it’s mobile, web, or desktop, and become an expert before expanding further. Also, reach out to hiring managers to learn about their tech stacks and current trends.
• Advocacy for balanced job requirements: Advocate for more balanced and realistic job requirements in QA job postings. Encourage hiring managers and recruiters to prioritize essential skills and experiences while being mindful of the practical limitations faced by candidates.

For Recruiters:

• Collaboration with hiring managers/recruiters: Foster open communication between QA professionals and hiring managers/recruiters to ensure that job requirements accurately reflect the skills and experience needed for the role. Encourage hiring managers to provide clear, realistic expectations in job postings and be transparent about the technologies and tools used within their organization.
• Solicit feedback from hired QAs: After a QA has been in the role for 3–6 months, ask them how aligned the job description was with the actual role. Although roles may evolve over time, it’s essential to understand the accuracy of the initial job post.

In conclusion, writing this article has made me realize how much the QA Engineering position has evolved, and mostly for the better. However, the current trend of unrealistic job requirements raises concerns. When I started as a QA eight years ago, all I needed to know were Test Rail, web testing, test planning, test reporting, and regression testing. But as applications have become more sophisticated and complex, the role of QA has evolved accordingly. Over the years, I’ve had to learn HTML, backend and frontend development, SQL, API testing, automation testing for UI, CI/CD practices, and much more. And here we are, eight years later, seeing what were once considered bonus skills now being regarded as essential. I love technology because it’s always evolving, forcing everyone who works with it to adapt. While this article expresses frustration about some unrealistic requirements in QA job postings, I absolutely love and enjoy all of this, yes, sometimes I feel my QA career is like running a start-up but it is so enjoyable and fun. In the end, these challenges will only make us better. So to all the QAs reading this: keep learning, as change is the biggest constant. And to the hiring managers and recruiters: be a bit more realistic about the QA role and its requirements. Clarify what you’re asking for versus what you really need, and include your tech stack in the job post. This will help future QAs understand what you’re looking for and narrow down their learning topics.