What is an efficient QA? Sometimes it is quite hard to understand what is the best path you should have to have an efficient QA process. This is why in this article you’ll find some suggestions in how to do it.
This is the path for efficient QA
You want to test the product after each section that is being added to it – or just modified.
It’s not recommended to run just one test when the project is complete. By doing this you will end with a ton of bugs, because they work somewhat like an avalanche: a mistake here can affect the code further and it can result in 2 mistakes after a couple of lines, and so on. And you can imagine that trying to fix that would be a nightmare.
If you test the product on a regular basis you will find les bugs at a time and they will be easier to fix – the root of the mistake will be easier to identify and the morale will not be as affected as it would be after realizing that there’s an enormous amount of errors that needs to be fixed.
You know for sure that a software will behave differently on different platforms. Make sure that you test the product on all the platforms on which the software is intended to run on. You want the software to “have experience”. It should be familiar with all the platforms so nothing will be able to surprise it.
3. Try the unexpected
The product will most probably do great with general input values. What you really want to check is how the software behaves when it receives unexpected characters. For example: in a field which requires the date of birth try to use “#” as an input. What happens? Here you can go wild. Write the name using numbers, write numbers using words, see if this manages to break the software.
4. Logical testing
You need a plan. Everything need to be done in a certain order so you will not overlook any aspects. Try to create your own logical system, it’s always easier this way. Write down your plan so you will always have it in front of you. But don’t worry, It will become routine over time – you will not need the guide forever.
5. Get feedback from the others
And by feedback, I mean – of course – bug reports. The software will be passed from one person to another a lot of times. And this is something that you can take advantage of. One can see something that someone else might overlook. You know what they say, 4 eyes are always better than 2. Try to gather feedback from the previous persons who got to work with the product. Ask them to send in bug reports when they notice that the product misbehaves. It will save you a lot of time. Also, feedback from customers is essential, so do your best in order to encourage them to file bug reports if they notice something unusual, especially while running the beta/alpha releases.
6. The bug database
Bugs are being categorized depending on the impact that they have on the product. Low priority to high priority. You want to get rid of the high priority bugs first since they have a greater impact on the quality of the product. Now the priority of the bugs shouldn’t be modified under normal circumstances. A low priority bug cannot turn into a high priority bug just because there are no high priority bugs left. And it goes the other way around as well: a high priority bug shouldn’t turn into a low priority bug because, for example, no one wants to fix it. Keep in mind that the bug database should always express the actual state of the product.
In conclusion, if you start early and you keep your work organized while you try to trick the product into showing you its weaknesses the customers shouldn’t have issues with using the software after its release. Just don’t forget to use all the resources that you have at your disposal and you’ll have an efficient QA process.
If you have any question, write me directly here.