As engineering roles evolve in product development companies, one change I have been noticing in the last few years is companies emphasizing on aligning test roles with the development counterparts and seeing them as part of the development teams rather than as stand-alone test teams. For e.g. a test engineer’s designation is being made Software Development Engineer. I have definitely seen several cases in the past, where they have been called, “Software Design Engineer in Test or Software Development Engineer in Test”, which makes a lot more sense. However, this recent change I have been following is how they are rolled into a hierarchy which fits into the development organization from a reporting perspective. This has often intrigued me as to why such as role re-alignment is being necessitated and what triggers the thought process. Is this positive or negative and what impact does it have on overall product quality. Here’s my take on this; if you have any thoughts/inputs, please do share and I would be very happy to hear other perspectives you may have.

On the positive side, such as re-alignment has:

1. Given a face lift to the testing profession where testers have in the past been given a secondary treatment compared to their development counter-parts. This includes both a moral as well as financial boost
2. Forced the testers to become more technical and aware of the system internals to help surface more complex issues rather than focus on pure-play UI and black box issues
3. Empowered testers with the required resources to build internal frameworks, tools and extensible technologies to maximize their testing potential and productivity
4. Provided better career progression opportunities, for developers who want to explore the testing discipline
5. Improved overall engineering accountability amongst senior management reducing unwanted managerial layers and overhead
6. Helped test participate in product design and requirements phases with equal visibility as that of the rest of the product team, enabling them add true value to the product under development rather than merely testing against implemented requirements

On the down side this consolidation of roles and reporting, has lead to or can potentially lead to:

1. Dilution of the test focus – I’ve seen cases where the test has been tasked with fixing simple bugs such as content issues, typos etc. This not only takes away valuable time from the tester’s plate, which could be used further testing but also dilutes their overall testing focus
2. A more inward look into product development where the tester misses to see the bigger picture of user focus and delves too much into core product development and associated tactical issues. This is all the more true with junior level testers, who take their role much too literally that they find themselves lost and lack the holistic product development view
3. Lack of strong leadership in guiding the team towards a quality focus. When managers and directors with a development background, take on responsibilities to lead both the development and test teams, they are often biased towards the technical and implementation aspects and are not as much focused on the quality assurance and testing aspects (either because of incompetence or because of incorrect prioritizations)
4. Ego-clashes between the developers and the testers, especially when testers share the same designations and near to same salaries as that of developers, forcing a cold battle around who’s more technical and again missing to see the user centric focus that needs to be maintained

Given that this re-alignment has both positives and negatives; it is certainly a model that offers to be promising. One has to carefully leverage the positives, acknowledge and mitigate the negatives to draw a balance. I would think it is important to start with the management level and work this model top-down, with a clear understanding and delineation of roles and responsibilities, focus and career paths so the teams understand their individual and common goals. There is a clear need for effective leadership that understands both development and test engineering and more importantly the testing process, methodologies and potential to maintain individual disciplinary focus yet streamlining reporting into one mainstream flow. When such realization and model implementation sets in, the reporting structure is merely a facilitation process for successful delivery.