Love Quality? Become a developer!

If you love quality, you should consider becoming a developer

Random drawings I’ve made for this post

As an engineer who started in software as a full-time manual tester I believe the most efficient way to achieve quality while building software in a continuous delivery fashion is by embracing development as the main activity, deliver actual production code, and advocate the removal of QA as an individual role.

This is an attempt to walk you through the arguments and events as well as the patterns that are emerging in the software industry, which strongly encouraged me to think that way.

Lipstick on a pig

One of the arguments that started a spark in my mind sometime ago came from a presentation held by the Test Engineering Director at Google Dr. James Whittaker, in which he said that you can’t build a product and then paint quality on top of it. His point was that testing a bad software would only show that the software was in fact bad.

Testing alone does nothing to improve the quality of an already existing piece of software, it’s too late, the problems are already in there.

At that time I was working as a Quality Assurance Consultant, and yes, I knew about Agile Testing, yes, I was doing test automation but yet something felt wrong or at least sub-optimal.

Crisis of Faith

I started to question if the QA role, the role that I was playing wasn’t being too test-centric, reactive most of the times and devoted to tools. The answer was yes in most cases. You can reach the same conclusion by doing a quick search about software quality practices. I did reach out the community, blog posts and literature in general and almost everything written by a QA was something related to reactive processes and the tools you should use or avoid when doing test automation. Even the famous Agile Testing book felt obsolete for me, because it still invoked a undesired separation between developers and testers and who should do what.

I felt that I was only doing a support role, kinda like a walking cane for developers. The feeling that I should get my hands dirty and become directly responsible for the development of the software whose quality I cared so deeply about was growing stronger everyday.

When I learned that TDD was not for QAs

There is a day in the professional life of a QA that he hears about this famous acronym and just by hearing it, it seems like something meant for QAs as it has the test word in the name. But the reality as you get to read some books, is that Test Driven Development is a design activity meant to guide the development of a small piece of behavior incrementally from the outside-in. Unless you are technical enough to know how to even make a test fail for a reasonable reason and then drive out its implementation you have absolutely no reason to bother with TDD.

That knowledge was really a game changer for me, how come a technique that actually helps to build high quality software was not really for QAs? Sure there is a lot more to software quality than TDD, but this realization led me to question even more the range of impact of my role.

You could argue that pairing with a developer would make the QA familiar with the TDD process, but again if the QA is not technical enough to really grasp what is going on, he or she will probably just watch as the developer drives the pairing and tries to explain what he is doing slowing a lot the whole process. In the other hand if the QA is substantially technical he could have a major impact by becoming a developer himself.

Development and quality should be an atomic activity

The reality that very few are willing to admit for the sake of their own jobs is that if you have developers capable enough to care about quality, the team will be better off without a person that can act only as a QA. I know this is a harsh affirmation, but bear with me. Quality should be built-in the software, before and in the moment of creation. You can’t delegate quality to a later stage (lipstick on a pig). Quality is a core concern and not an add on. By making QA a job title companies are inadvertently affirming quite the opposite.

The Developer path

Becoming a developer felt like a natural next step for a QA that was substantially technical like I was. I had enough background in automation to start. Of course it takes much more than a job title change to become a developer but I was motivated. I studied a lot doing online courses and personal small projects in technologies that I felt more comfortable with. More importantly, I started to code like there was no tomorrow.

Then came my first project as a developer, I was really worried about being able to be fluent in every technology of the tech stack, but guess what? So was every other developer in the team. This feeling is what makes us keep striving for technical excellence, and it is healthy till a certain level.

There was no QAs in the team, I felt like a spy, I was devoted to inject quality in every moment of the software creation, from the story narratives using what I learned from the amazing Specification By Example book, doing TDD with my pairs, acting on code quality with ideas from books like Clean Code and even promoting short time-boxed exploratory testing sessions with all the team involved.

The team as a whole had taken quality as a core principle. It was like a virus spreading to everyone. The other developers were very open to the quality practices that I (as a developer) was suggesting, in fact they were eager to maximize their existing knowledge about quality. Without the boundaries of the role the team was free to become multi-functional and self-organized.

I finally felt like I was having a major impact in the quality of the software that we were delivering.

Conclusion

I feel that the QA as a role was necessary in a given time frame, but as the years go by it is necessary to make a definitely disruption from that practice, otherwise quality will not be a core concern in the industry.

My personal experience taught me that as a developer I’m able to have a greater impact in the quality of the software delivered due to the fact that people are inclined to follow practices that they actually see happening in their day to day work. For instance as a QA I could recommend the developers to do TDD, but as a developer I can actually show that it really works by doing it.

The “hows” are not really the scope of this post, what I wanted was to expose the “whys”. So stay tuned for more content related to the “hows”.

Inspirational references:

Dave Astes and Steven Baker - RSpec and BDD

Vinicius Gomes - More Testing. Less Testers

Gojko Adzic - Sleeping With the Enemy