Thinking outside the "QA's boxes"

If you think the QA engineer is a person of strict principle, who does not need creative thinking, then you are wrong.

When we step into the field of software testing, the first thing we are being taught or we learn is the Two Boxes – a white box and a black box. And as a result, we just focus on doing those two boxes testing. This has limited our minds from thinking beyond the boxes. The school doesn't teach you to think outside the box to consider more aspects and find out more important things as what a QA should do.

Imagine that when testing, if you were given two options, would you choose only those two options? Or if you were only provided one tool, would you only use that tool?

If your answer is no and you actively search for tools, other ways of testing, it means you're starting to think outside the box. You don’t need to think of something too great, just some creative moves and "think better way, try new things". If you want something you've never had, do something you never did!

To have more specific answers, ưe will be discussing here a few techniques trong while doing Software Testing!

1. Rapid Fire technique

Rapid Fire shows us how to create rapidly test cases. This technique links testing directly to performance. So here, how do we think outside the box? The initial things that come to our mind when we talk about test case creation are a Requirement Document, an Excel Sheet and some guidelines provided by the organization. For once, keep aside all these things and get an idea of what you think you are about to test.

Pick up a Pen & a Paper and write as many scenarios you can write within 60 seconds. Repeat the process till you are not able to think of more scenarios or ideas and finally review them. You will be surprised to see the number of ideas/test cases you already have.

2. Reverse or Backward Testing Ideas 

What is the normal workflow you follow while testing?  Isn’t it the exact same steps that were used while developing the application:

“Requirements >> Unit Cases >> Integration Testing >> System Testing”

During the product development process, the dev always look for ways to bring the best experience to users. However it doesn't always work because the End User might not think in the same direction every time. That is the reason why Production Defects or UAT Defects exists even after extensive rounds of Unit Tests, Integration test, and System Tests.

For Example: Requirement says that you can upload a file that does not exceed a file size of 10 MB. Most of the testers will follow uploading a 1MB, 2MB, 3 MB and so on till 10 MB is reached or an error message is displayed. Why not start with 10MB and then try 11MB and then 9 MB?  This example is nothing but a BVA (Boundary value analysis). Still, how many of us have tried using BVA in scenarios other than an input box.

3. Questioning 

Every QA engineer should know the purpose of a requirement. Putting up questions will help a QA Engineer to refine his purpose of testing. To be good at testing by default, you need to be good at questioning. Make sure none of the questions (how so ever small or silly) is ignored. Questioning will also enhance the Domain Knowledge of the person who is performing the testing.

Regarding the question of whether we should frequently ask questions or not, Tran Thi Ha, the beautiful QA engineer said: “During the course of work, I found that Q&A questions are often related to project spec. Sometimes there are uncertain issues that I want to ask the customers to make sure but I’m afraid that they will be annoyed and consider "it is too easy to be asked". However, “a polite no is better than a rude yes”, sometimes I have to consider asking the questions as reasonable as possible since the most important thing is still the final result of the project. ”

Remember: “The only silly question is the one that is unasked.”

(Source: https://blog.testlodge.com/what-does-qa-stand-for-in-software/)

4. Researching old cases

Researching proves to be very beneficial before starting the testing. Just be aware of the issues which other people have faced while doing a similar assignment. Say, you are required to start cross-browser testing. Before starting the tests, researching the issues which other people encountered while using the same browser will help you find defects before starting the actual testing.

5. Making use of experience

Sometimes, you will see some similar applications that you have done before. Then, remember what you have used in the past, you'll be able to identify similar problems in a faster way and of course solve them more quickly.

Experience is sometimes the way you handle difficult situations flexibly when cooperating with colleagues skillfully.

We can see that clearly from the following story shared by Ms. Vu Thai Ha:

“When being a QA engineer, you have certainly worked with many young, newly graduated, enthusiastic and young developers. And QA is probably the one that you think is the most strict to your work. Sometimes even senior devs have that mindset. But finding something wrong is our main mission, isn’t it? Both QA and Dev do their own work to improve the product. So QA, what would you think then:

1. Never mind, just leave it for BrSE or BA to confirm to do it or not

2. I need to act a bit!

If you choose option 1, it is a simple way without thinking too much, which is good for you but not necessarily good for the project as well as for the customer or your relationship with the developers.

For me, I choose option 2. When I say "I need to act a bit" here is not to argue or fight. I mean, I should have some impact on Dev before giving it to BrSE to confirm. For what? For explaining why I want to fix that bug, what the consequences of not fixing would be like and friendly reminding the developers if we can help the partner to appreciate us more by just a few small skills and a little time of the developers... I think it will not be difficult for them to agree and cooperate with us more.

For me, such small action to make use of experience and thinking is already an “outside the box” thinking in work"

6. Pause testing

Testing sometimes could be a monotonous process and the ideas may begin to saturate. You might start feeling that none of the solutions is working out or you might even run out of ideas. In such cases, an effective Pause can do a lot of wonders and could help you kick start from where you left. A relaxed mind will bring you new creative ideas, opening the knot that almost seems to be out of work.

Reference source here

#QA