Google Analytics

Search

To search for specific articles you can use advanced Google features. Go to www.google.com and enter "site:darrellgrainger.blogspot.com" before your search terms, e.g.

site:darrellgrainger.blogspot.com CSS selectors

will search for "CSS selectors" but only on my site.


Tuesday, October 3, 2023

Difference between QA and Dev

Difference Between Quality Analyst and Developer


In 1998, I was testing software development tools. I was testing an IDE, compiler, assembler, micro-kernel, scripting language, etc. It started off with me testing the work of a few dozen developers. It was my first QA job.

In 2001, one of the developers was talking about this new way of developing software. Previously we had Waterfall. This morphed into V-Model and later Spiral SDLC. QA was silo'd from Development and there were a lot of processes and procedures. Developing an application took months and sometimes years.

The new way of developing software was called Agile and included things like Unit Testing, eXtreme Programming, etc..

QA were the gatekeepers. We were the last line of defense against bad code. In some companies it was almost adversarial. Some developers looked at QA as the department that criticized their work. They were blocking them from getting their work done. 

I remember a time when a develop refused to talk to me because they honestly thought I was calling them a liar and just wanted to make things difficult for them. I had to call their team lead. I explained the defect to him. I showed him. He realized the junior developer fixed A defect, just not the one I reported. They worked closely with him and had a great deal of respect for him. I was just someone from a different department on a different floor who they really didn't know socially. In other words, there was a little bit of hostility between QA and Devs.

Shortly after Agile started to take off, someone posted a blog explaining why QA were no longer necessary. With unit testing and automated testing, QA was no longer necessary. A few QA people in my home town were honestly concerned about the future of QA in software development.

But shortly after the blog post, a number of high level software developers, some of which are signatories on the Agile Manifesto, started point out that QA were still necessary. They definitely didn't want management to get the idea they could fire all the QA staff and make the developers responsible for all testing.

I started wonder what does QA bring to the table? Why is having QA or software testers necessary? This questions was in the back of my mind as I learned how my role changed in software development.

I started working more closely with the developers. At first I would test the software a sprint later than the developer. For example, feature #1 is implemented in sprint 1 then I would test it in sprint 2. But if I found defects, someone would have to fix it in sprint 3 (can't disrupt the current sprint). After a month, developers had to remember what feature #1 was and fix the defect. Not efficient. 

So we started having developers and QA work together in the same sprint. The time between implementation and testing got smaller and smaller. I would even talk to developers as them worked on a feature.

Then I started to noticed a pattern (that is what good QA do). I'd ask, "What happens of the customer does XXX? And the developers would usually ask, "Why would anyone do that?" Essentially, many developers were brilliant technically, but not great at understand people who weren't technically smart. To this day I still test some software with the question, "What would my eighty year old mother do?"

A number of times I would paint a negative scenario and developers would counter with, "That would never happen." Only to find out later than the negative scenario happened more often than the positive scenario.

So I got thinking, what would be a good way to explain the difference between a QA and a Developer. I came up with:

Developers tend to make sure the code does what it is supposed to do; QAs tend to make sure code DOESN'T do what it's NOT supposed to do. -- Darrell Grainger


I still use this quote today. 

.