QA != Tester — Mindset แบบไหนที่ QA ควรมี (Which mindset should QA have?) — TH/EN
Tags: QA, Testing, Quality Assurance, Thoughtworks

English version

When I was in the 4th year, I had a wrong mindset that I would apply a QA job to be a bug hunter. However, after my interview ended, I realized indeed QA wasn’t a bug hunter but the person who prevented a bug! I have to say thank you to my interviewer who give this feedback to me after interviewing, and this made me understand more about QA’s works.

Even though I understood the concept of what QA does, I felt this was only I knew if I didn’t learn from the real project, felt a pain, and got the real experience. As such, after I attended to ThoughtWorks University, I could obviously see why we should put more time and effort to prevent a bug at the beginning rather than finding a bug at the end after finishing code or develop each feature.

To illustrate, I will give an example from my real experience during my training ( I have to say that it is the project simulation for trainees to learn from the real project implementation not the project from the real client).

QA received a defect from the PO that her technical team could detect a security issue, which users’ passwords stored as the plain text in the database.

This defect was a high priority, which should be solved quickly, and of course it was easy to solve…..but! wait…the point is this feature (Register/Login) had already deployed to the production!

This meant even if we encrypted passwords from new users and stored them in the database and implemented authentication encryption, which allow new users were able to login, we still got a problem, which was existing users couldn’t login to the website anyway.

Luckily, it was a happy ending at last, but I will skip to talk about this part since it is out of scope hahaha.

Come back to the QA mindset. Why do I have to give this example? How can we as a QA help to prevent this kind of issue or make it happen at least as possible?

The answer is… what if QA told this to the developer before they started coding this Register/Login feature.

‘ I thought this acceptance criteria should have users’ passwords stored as encryption.’

Could you see the clear picture? The developer would implement an encryption password at the beginning before deploy it to other environments until the production, and we no longer received this kind of security issue or solved the defect that make us waste our time for developing other features.

After we understand why “ Prevent a bug more than Finding a bug ”,

the question is what QA should work to achieve ‘ Prevent a bug goal ’ ?

The answer is we have to be a QA who works in Agile world.

To make it clearer, see the picture below.

We can see QA can work at the initial stage like analysis phase. QA can pair with BA to check there is anything can add into the acceptance criteria to make sure there will no future bugs or issues, as the example of writing ‘encrypted passwords storage’ in the acceptance criteria, which allow developer can code based on it.

This is why QA isn’t a tester because not only finding a bug we also analyze to see the whole view and know what is a big hole, which can bring a negative impact to our team later. Doing so, we can prevent those issues early.

Apart from that, QA can also pair with developer in the development phase to check whether test cases in unit test or functional test covered enough or not.

Lastly, I would like to give my lesson learned from training in ThoughtWorks University about QA responsibility as follows.

Quality analyst → Do we know the right things?

That is we have to always ask ourselves what we should do to ensure every product or software will deliver to client or user’s hands with the best quality.