SRE and SDET

Performance testing has traditionally occupied a secondary position in quality assurance - sometimes appreciated, often seen as an impediment. Recently, two major tech companies have reshaped this landscape. Google introduced the Site Reliability Engineer (SRE) model, while Microsoft created the Software Development Engineer in Test (SDET) role.

Site Reliability Engineer (SRE)

Google developed this position to embed performance considerations into software development from inception. An SRE combines traditional software engineering expertise with performance optimization, ensuring applications remain efficient as user demand scales.

Beyond coding, SREs handle operational responsibilities including:

• System availability monitoring
• Performance optimization
• Capacity planning
• Incident response

The SRE model provides a method of creating efficient software, developed by software engineers with performance in mind from the start.

Software Development Engineer in Test (SDET)

Microsoft pioneered this hybrid role, typically filled by developers capable of both building applications and validating them, including performance assessments. These professionals simultaneously fulfill developer and testing responsibilities.

QA automation engineers frequently transition into SDET positions, leveraging existing code development experience from automation frameworks. The role bridges the gap between pure development and pure testing.

Key SDET Responsibilities

• Writing production code
• Developing test automation frameworks
• Performance testing and optimization
• Code review and quality gates

Performance Testing Evolution

Performance testing has shifted from a post-development afterthought to an integrated continuous integration component. While historically a QA domain, developers increasingly recognize it as an essential pipeline activity rather than an optional final step.

The Shift Left Movement

Modern development practices emphasize testing early and often:

1. Unit-level performance tests - Catch issues at the component level
2. Integration performance tests - Validate system interactions
3. Continuous performance monitoring - Track metrics throughout development
4. Production observability - Monitor real-world performance

Conclusion

It will certainly be interesting to see which direction businesses will take. As can be seen, even Google and Microsoft have their own ideas about how to best integrate performance considerations into the development lifecycle.

The common thread is clear: performance testing is no longer a separate phase but an integrated discipline that spans the entire software development lifecycle.