Software QA Hoax

The awareness of Software QA was raised in the last decade to a new realm. However, there has been some natural resistance as usual for any new evolutionary movement. This resistance is the new trend of merging development and quality and assurance into a kind of “DEVQA” roles. The movement is promoting “We have just developers! NO QA roles required!”

“The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: divide and conquer”
Bjarne Stroustrup

In the current highly complex world, the quote from “Bjarne Stroustrup” certainly fits this debate. To merge developers and QA skills into one role is to go against the ‘divide and conquer’ principle. Yes, it is possible of course. It just depends on what level of quality is required. In case of developing just simple applications, software architecture and testing are not really critical. It could be enough with DEVQA roles. However, it is important to remember that software solutions tend to grow, rather fast, and if the team hits the “Jack pot” it would be very expensive to refactor on time.

In Spanish, there is a saying “Juntos pero no revueltos” which means “Together but not mixed”. To become a QA specialist requires years of real work experience as well as becoming a proficient developer. The ideal goal should be not to mix the two subjects but to reduce the distance between them.

However, nowadays with the intention to be “Agile”, people get confused and start crossing the line. The original trend was to try to reduce the distance between DEV and QA but some teams are crossing the limits too much and they mix everything on anyway and for any reason. “Because we are agile!” Yeah, happy Agile party! All get mixed into a “DEVQA” orgy.

Therefore, in this new chaotic “agile” environment the questions raised to organise workflows are Who is more important?, Who has main responsibility? Who is shouting more? etc… These are a set of wrong questions. Instead, team members should start asking this way: “Who can contribute more to a given task?” “Who has more expertise and thus can be the reference leader for that task? “And who is the reviewer?” In a healthy environment, we should not even need a team leader to define these roles. Good professionals know when to lead and when to follow.

At the end of the Joe Colantonio’s podcast with Gerald Weinberg, Gerald explains in more detail that in the good old days ** the QA team was formed by selecting the best Developers in each area**, thus the collaboration between Devs and QA was optimal, exactly because there was no such huge separation of concerns and there was huge respect for each other. Yes, they were a team of only developers, **the key point here is that the QA team was focused on building tools to improve quality rather than shipping new features.**

There is another great source in order to dig in more detail about why promoting DEVQAs is a bad practice. “Joel Montvelisky” has a great post called”Why can’t developers be good testers?". Even the title is not perfect, as it should be something like “Why developers cannot focus on testing” the post has a good summary of key reasons:

1. Developers have “Parental feelings” towards their code.
2. Developers usually only focus on the “Positive Paths”.
3. Work based on the principle of simplifying of complex scenarios.
4. Developers are unable to catch small things in big pictures.
5.Developers lack the end-to-end & real-user perspective.
6.Developers have less experience with common bugs & application pitfalls.

While all the points are core principles of a good QA strategy, I would stand out the fifth point of “real-user perspective”. This point is a core concept of testing. If this is missing, all QA strategy becomes a hoax. The QA expert “Neeraj Tripathi” emphasizes this point clearly in the Joe Colantonio‘s podcast”Principles of Effective Software Quality Management with Neeraj Tripathi". As Neeraj states, “a QA specialist needs to keep customer perspective in mind”. Customer experience is the first class driver for a tester. One way to achieve this could be to do more BDD. Moreover, the main strategy is to have QA people in operational meetings and have direct contact with customers on a daily basis.

In summary, a QA expert should keep a customer mindset with full knowledge of the technical capabilities, while a Dev should have a more focused technical mindset. By correctly leveraging both mindsets, the project will be able to find the best strategies to succeed.

After all, we should be able to agree that having both mindsets in the same brain opens the dangerous highway towards the new world of testing hoax strategies.

Many thanks for reading, please leave a comment if you have a testing hoax workaround.

Keep on testing, better!