Mismanaged QA roles

“We made the first separate testing group that I know of historically I’ve never found another for that Mercury project because we knew astronauts could die if we had errors.We took our best developers and we made them into a group, it’s job was to see that that didn’t happen. They build test tools and all kinds of procedures and went through all kinds of thinking and so on. The record over half a century shows that they were able to achieve a higher level of perfection but it wasn’t quite perfect then, had never been achieved before since.” By Gerald M. Weinberg at Testing IS Harder than Developing Gerald Weinberg

After over a decade of work experience in software development, it is my impression that Quality and Assurance roles have evolved in a wrong way since the Mercury project. I am still not entirely sure why that devolution happened. However, I suspect that the new age fashion of accounting management style has had a dreadful impact on this subject during the last decades. What I am able to understand is that the metrics of any development effort looks much better with flaky testing strategies.

Good testers are those who become great experts of the actual behaviour of the solution under test. These testers know what is the actual logic and performance. They have real users’ experience on a daily basis. Those testers are the most advanced users an organization could have. Surprisingly though, most of the companies still disregard Q&A teams as valuable resources for business value. Even worst is the fact that companies do not care much and do not actually support good career paths for Q&A professionals. Some organizations go as wrongly far as taking such careless approach when hiring QA resources. In the end, “Anyone can be a tester.” Right?. NO! Not really!

Thus, I have renamed these professional “testers” as Business Experts (BEs) LINK PREVIOUS POST!!. They are the ones who know better how the application actually behaves from the user’s viewpoint. This behaviour is ultimately the only thing that provides business value or frustration to the world.

In general, most of the current organisations do not really understand where the value of solutions comes from. Having a ton of Business documents and a ton of lines of code does not generate any value “per se”. The only value comes from listening to the users and understanding them very well by becoming one of them. BEs then very quickly and naturally become the user advocates of the application or service delivered to the world.

A great support for the BEs are the Software Developer in Test (SDT) or abbreviated as SWEITs. They also have kind of a negative aurora which can be seen from time to time, when the magnetic poles of the team become visible after a customer burst of a sudden set of demands. Usually, those roles are considered as half developers. When far from the truth, the good SDTs should be the top developers which can move on to solve wider and more complex issues than coding new features or fixing bugs. Just as Mr G. M. Weinberg’s quote.

An SDT needs to understand all the development tools and all the business limitations in order to layout the most effective Testing Framework which will allow to seamlessly test the application with the minimum overhead of maintainability.

All things being equal, all roles in a development team require a huge amount of technical expertise. The subtle difference is that SDTs require a much broader set of skills to provide actual value, while DEVs and DevOps should be specialized in a focused set of technologies in order to implement high-quality implementations.

In the T shape skills analogy, DEVs and DevOps would be then the vertical bar and SDTs the horizontal one. Once this relation is understood, there is no excuse to mystify some roles upon the others in a truly collaborative environment. So those companies pressing down the “testers” are missing a huge opportunity to improve their solutions and ultimately their bottom line.

In summary, companies that seek software development performance with high-quality results should lay out a Q&A team formed with the best people from all the development teams. This would require a proper environment with an organic hierarchy structure of roles to incentivize respect and healthy discussions.

Keep on testing, better!

Posed by Marc Andreu Fernandez