Specifics of Software Product Testing

There are differences between testing of software developed internally and third-party products. BelVG testers deal more often with our newly created Magento and Prestashop extensions than with customized products.

When you work for a client, you choose software testing methods depending on a number of hours paid. As a rule, there is enough time to do all positive testing and at least part of negative testing. Testing of own software can last for a long time which is something to be avoided.

There are a lot of players on the module development market and the probability of them working on the similar projects at the moment is high. That is why time is precious. In order to find the right balance between product quality and testing time, the following factors must be considered.

The earlier testing begins the better. The tester should start specification analysis and draft test plan creation immediately after developers receive the task. It will save time to write software test documentation when the project is released.

It’s good to use a version control system to organize work on a project properly. Such a system saves time for file transfer and clarifying what version the tester is working with.

One important point in timesaving is that testing priorities should be defined clearly. All the test activities are a long and expensive process. It makes sense to confine ourselves to positive testing at this point. Positive testing implies most likely user activity scenarios. Unlike negative testing, which ensures that your application can gracefully handle invalid input, positive testing provides information about proper work of module’s key functions.

Partner With Us Let's discuss how to grow your business. Get a Free Quote.

Talk to Vlad

There is no need to waste time on low priority tests considering low probability of this or that user activity. That’s why it’s prudent to handle test documentation at least on the checklist level – the tester can’t keep every single detail in mind. It will cover human factor related risks. So if you still don’t have testing documentation – create it without delay.

After tracking the bug, it’s necessary to define its criticality correctly. It will help manager get all the bugs prioritized quickly. It’s not always advisably to fix the bugs before the release.  For instance, graphic defect that doesn’t affect user perception of the project can be fixed in the next version or in the patch-release.

The correct name of the bug would save users time and nerves. The name should be short and characterize the problem completely. If you or your employees experience difficulties with it, use the “What? Where? When?” rule. For example, “Data is not saved in the Title field after clicking Add New”.

Steps to reproduce should be made the way a person who doesn’t work on this project would follow them easily. This is the case when 5 minutes of tester’s extra work help avoid additional explanation for developers.

Attach screenshot to every bug report if possible. Try to include If there is a number of project pages, try to include them into a single screenshot. Create it the way developer would understand the gist of the problem without reading the defect description.

After the bug is fixed and checked, the tester changes its status to Closed. Don’t forget to comment the change of the bug status. In this case it should include the tag of the version that has been changed after the fix. In case of a problem it will help determine and solve its cause and determine the latest stable version.

The day of the release beggars description: it is very special for each particular company.

However there are no reasons to relax even when the module is released. It’s time to do all the tests we’ve put aside before and fix all the bugs with a lower level of priority. The faster more stable version of the extension will be released, the more happy customers company will get and the less workload the support will have.