Hybrid Jobs: How Software Engineers in Test (SETs) Bridge the Gap between Coding & QA
Believe it or not, the concept of the ‘cross-functional team,’ which brings together multiple roles from traditional, skill-specific siloes on a single team, has only come to prominence in the last decade or so. It might be hard to believe because nowadays, building teams featuring employees with skills in different disciplines like technology and finance or marketing and analytics isn’t nearly as uncommon as it used to be. That’s because it works.
Accompanying the emergence of the cross-functional team has been the demand for people to fill ‘hybrid jobs’ with position titles like Creative Technologist, Hybrid IT Business Analyst and even User Experience Designer, which seems like a completely ubiquitous job title at this point. Just like cross-functional teams, hybrid jobs combine multiple hard and soft skillsets, but instead of a team, it’s an individual capable of fulfilling multiple roles through a single job.
At EPAM, hybrid jobs are in hot demand. A great example of one is the Software Engineer in Test (SET), who bridges the gap between writing code for software development and testing that code for bugs as a QA analyst. For more on the topic, let’s hear from Petr Kartashov, Head of QA at EPAM, to explore his perspective on the emergence, prominence and future of SETs.
When and where did you first hear about the SET position?
The first time I learned about this concept was in the early 2000s when one Microsoft blogger offered a glimpse into their Software Development Engineer in Test (SDET) role, then a more concrete description was given in the 2008 book called How We Test Software at Microsoft (Developer Best Practices). Google created an even more technical/lean startup definition of this job called SET and described it in the 2012 book entitled How Google Tests Software. I think Google’s definition of SET better describes the role we have at EPAM.
How has the SET position evolved over time?
After this hybrid job emerged as SDET in the early 2000s, it matured and was shaped to fit Google’s approach to product development. One of the reasons is because Google has always been a web-first company (as opposed to Microsoft, which represents the PC and desktop era) where product delivery and updates require near real-time operations and demand different technical and business skills, like agility and continuous delivery in a lean startup culture. That’s why sharing hybrid skills between both developers and testers was crucial to getting the job done.
As far as developers’ overall skillsets in Google and other fast-paced tech companies go, they too should be well versed in holistic quality engineering that includes both traditional QA/testing fundamentals and modern development practices to meet quality standards.
What are some of the organizational benefits of having people with hybrid jobs (like SETs) deployed within a project?
To summarize, I see two main benefits. Number one is enabling a truly frictionless build-test-deploy-operate process by automating everything possible (and, of course, only what makes sense to automate).
Number two is what I call time-to-market reduction without compromising confidence or quality, especially on the business side. There are plenty of practices and techniques that can reduce time-to-market, but what about maintaining the confidence level of the business? Can we really do both at the same time? This is a tough call and a balancing act for many business leaders. SET and other hybrid or cross-functional roles actually have these two KPIs in their deliverables, so organizations can ensure both are happening simultaneously.
Another example of a hybrid role in the testing world is the Site Reliability Engineer (SRE), which extends the traditional performance engineering role into production operations. Similarly, their KPI goes beyond performance benchmark testing as it also includes real-life performance metrics, incidents and SLAs.
What do you think the future entails for SETs and the enterprises who employ them?
While enterprises have been adopting and adapting to this role, the efficiency is still not there in terms of where and how to engage SETs, what the best practice is when it comes to employing a ratio of SETs to test engineers, as well as how to allocate and budget such resources for cross-project and cross-functional efficiencies. Efficient allocation is very important due to the fact that we are talking about a very unique, niche role that is both hard to find and well paid.
From a technical point of view, the adoption of cognitive computing and machine learning will bring even greater opportunities for SETs to drive holistic delivery automation. I think a few of the practical applications of AI/ML that will emerge and involve SETs include smart visual testing that reduces expensive page layouts and UI/UX comparison from build to build; test data management automation with intelligent data sub-setting based on risk and the affected product code; and real-time code coverage optimization that learns from production data. Furthermore, application performance monitoring will probably gain a lot from AI/ML-based technologies.
All of these technologies and tools will need cohesive technical integration within existing processes, so it stands to reason that a SET would be probably be the best candidate for this task.
In 2017, Mr. Kartashov wrote an in-depth article for CIO Review entitled “Why Digital Enterprises Should Embrace the Role of Software Engineers in Test to Build ‘Quality-First’ Products.” You can read it here.