Why I think it is okay for testers to call themselves QA- X? (where X= Analyst/Engineer/Associate/etc)

A new lesson learned in my testing journey!

Quality Assurance-- a term which testers 'prefer' using has been quite debatable lately.

I will take one side and after reading about it, I have come to the conclusion that testers do assure quality. For some, today it might not be what that actually meant and may argue: "Quality is everyone's responsibility"

I do believe in "Quality is everyone's responsibility"-- yeah true but a tester is the one who assures that yes the necessary quality is NOT compromised. A tester needs to be creative in thinking points while testing like

1. Where can there be a point which can break the code

2. What's there in the requirement the development and business team might not have thought of.

3. Does this actually bring value to the users who are going to use the application.

4. What could be the pain points from a users' perspective that one could feel while using this?

This role does not only require testing the application and bring to the table where the application fails but also diving deep into the business aspect regarding the usability of the application. Hence, in my opinion, testers do assure quality in one sense.

Supporting this with a real-life incident that led me to this realization.

So, was working on a small project where the latest feature was to create CSV files based on an event, and then those files will be mailed to 'some system' (yeah wasn't clarified what was going to happen to those files next. No, not even on asking.)

The time for testing this was 3 days (Unbelievable right? was unfortunate to work with folks who gave testing the least importance and were simply chasing after "sign off").

Before testing, I was given a brief idea of what the technical feature was about and was shocked to see that they didn't even have proper documentation-- just a mail chain to view requirements(alas!). They expected me to just do the checking job -- if the CSV file contains the right details and they were not further interested in explaining what happens next?

I did the 'checking' for the first 2 days and on the last day, as I was scratching my head to connect the dots, I (again) asked the business: Could you please help understand how is this latest feature impacting business and what value does it bring? and how exactly will the file data be fed to the target systems?

I was explained that the files will be mailed to some business folks who will feed the file data manually into another system. On asking further how will they read the files, they said they expect them to open the files in MS Excel.

I was surprised. Because the format of CSVs did not even appear to be easily readable by a non-technical person. It had '|' (pipe) separators instead of ','. I knew that by default Excel Application accepts comma separators only unless some other separator is specified explicitly in the CSV. Since I was already aware of this, I added the separator explicitly myself in order to test the sample files. But the unaltered files looked messy and it was the last day of testing.

I brought this to the business' attention and they considered this a valid issue and were clearly unhappy with the look of that because they did not expect business users to understand that.

Being lucky to have worked with CSVs during the initial phases of learning automation, I knew where exactly the problem was and also, how to resolve this.

The business reached out to the developer and he said that he will need to look into it and see some CSV formatter options and will take 1 day extra for the solution he had in mind.

Since I had dealt with CSVs earlier, I suggested to the developer and the business that the CSV will open just fine in Excel if you append one line: "Sep=|" at the top of CSV. I did not know how the process was coded, but I sure did know that this method was not unrealistic. The developer did that in half an hour, and the business was happy with the outcome! We had clear, beautiful, and readable CSVs directly opening in Excel.

And no, the business still did not thank the tester for bringing not only the issue based on what was NOT told in the testing requirement but also coming up with a quick solution to a development process.

After this incident, I do believe that testers play a major role in assuring quality given that they are rightly told both the technical and business specifications. It should not be expected of them to ensure a 100% bug-free solution since that is a myth. It also highlights that a so-called 'bug' shall not be explicitly mentioned in the requirements!

I wonder what would have happened if that minute code change would not be there and how I would have been blamed if that went to production!

Why do I think I took on a role for assuring quality here?

1. Questioned who would be using the application
2. Thought from a users' perspective
3. Made sure that it was resolved before it went live

I feel it was somehow assuring that users felt at ease with what they were going to deal and hence I feel testers do take on a role of assuring quality to a major extent. Yes, they aren't to be blamed for the quality of the solution as it is everyone's responsibility and they do not design or develop solutions. But a tester is someone who acts as a middle-ware between business and development teams. A tester is someone who can think with both mindsets and hence is the best person to think of ways and make sure that the proposed solution fits just well.

I feel happy about this little achievement and the way I could see myself as a problem finder and problem solver as well as someone who made an impact- even if it wasn't recognized ( and it is okay!)

Testers do make sure that the issues they find are resolved and track the journey for each one of them. I understand that testing is a subset of quality assurance but I will not deny that testers are the ones who have quality bent thinking when it comes to UX. Yes, they aren't supposed to be flag bearers of quality and cannot guarantee 100% quality (no one can do that actually) but they do think of quality in whatever they do. If testers were meant just to find bugs, I wonder why they are also expected to make sure that the bug gets resolved. In my opinion, this is the part where testers are expected to 'assure quality'. So I feel that if testers do call themselves quality assurance with whatever suffix, I do not think that is questionable! In the setup that we usually work, even if by literal meaning QA and testing are widely different, the role is overlapping and the general expectation is to take up both responsibilities. And to steer clear of this confusion, I have found a midway for myself- QA Tester!

Well, I'd say to each their own with whatever jargons they like! I feel testers/QAs should be given a shoutout because they do work for the betterment of user experience and also act as saviors for brand reputation directly or indirectly! Those who care about the product will never compromise on that aspect. Testing by the very nature of it means questioning/suspecting what's perceived as normal (don't get me started on "existing production behavior" :( ) and hence testers are an asset to every organization. And to those who do not believe or give undue importance to testing:

And to all those who hold trust in testing and value quality:

Cheers!

Disclaimer: This article is entirely based on my personal experience and my opinions are subject to change with time, experience, new insights. I would love to discuss in case anyone disagrees with any point mentioned and open to a healthy and rational conversation. I am open to new ideas and perspectives. Also, the images and gifs used are directly downloaded from google.com and I do not hold the copyright to these.