Murali, from India, is an experienced Software Quality professional with over 18 years of testing experience, a passionate hands-on tester himself, who likes to contribute towards the larger testing community with thoughts on specific areas.

Bugs galore

Introduction: Despite extensive testing happening for software products, defects still pop and are seen by the end-users. If these were cosmetic defects, like spell errors or tiny defects, they would be tolerated. But when these are functional defects that are customer-facing, it is a cause of concern. These are the areas in which crowd testing can assist the community and the improvement of the software product by offering multiple hands to test with reasonable resources invested.

Here are a few real-world instances that I observed recently:

1. An investment arm of a banking organization incorrectly popping up spouse gender as “Male” instead of “Female”.
2. Video verification for Bank account opening KYC, failing multiple times due to browser and device compatibility issues, right at the time of getting introduced to the customer, leading to customer frustration.
3. In a stock trading application, the amount of monthly SIP being accepted is lower than the unit stock price, without any error message being prompted.
4. As a stock trading customer on a trading website, I was unable to locate the key functional requirements with ease.
5. Repeated SMS messages received for the same activity done by a customer.
6. Multiple SMS messages received with different content for the same activity done by a customer.
7. Not to mention all the spell errors noticed on the website of even well-established organizations.

All these are leading to a subject called Defect/Bug acceptance criteria, where bugs in software are acceptable to an extent by the end-user, acknowledging the fast-changing software application landscape and rapid evolution of software at the speed of a mobile button click.

Why are these defects occurring despite continuous testing?

Use case 1 – The integration between the Banking software and the Investment software was not tested efficiently.

Use case 2 – Browser compatibility and device compatibility were not verified to the extent required. The mobile app was given more priority than the identical website during the testing process when multiple service delivery channels were used.

Use case 3 – Field level validations were not performed, meaning an alert/error message was to be provided for the amount lesser the average stock price current market price to the investor in order to avoid such circumstances.

Use case 4 – The software was built without taking all the considerations of ease of App Learnability for the end-user.

Use case 5 – Frequent changes to the application even after UAT are performed in order to accommodate the product owner requirements.

All these and many more point towards the lack of extensive testing of the software and especially the continuous changes done to the software.

How can these be prevented :

Crowdsourced testing provides one of the effective solutions for preventing these defects:

1. The number of tests can be repeated across multiple browsers within a limited time frame.
2. The number of tests can be repeated across multiple devices, legacy and new, within a limited time frame.
3. Enables new pairs of hands and eyes every time the tests are run and are regressed.
4. Business-oriented testers may be a part of the crowd and hence business domain-centric tests can be executed efficiently.
5. Channel-based integration tests were accorded lower priority and hence missed out later, which could have been solved by using more testers from a crowd testing platform.
6. Extensive regression testing can be achieved by using a crowd testing platform for frequent software modifications and new feature enhancements and impact areas.

The bugs galore provide ample opportunity to crowd testers, but extensive testing prevents bugs from being rolled into production without adequate testing. Happy testing!