Skip to main content

Crowdsource testing


Crowdsource testing, also identified as crowd-testing, is the exercise of sending out prototype software and app products to wide-ranging groups of people for testing rather than having testing performed internally by core QA team. It has been used to describe the process of requesting a crowd to perform a task rather than hiring consultants or contractors.

It allows more entities to participate, often at a reduced cost and with enhanced testing quality. Testers may be developers or interested members of the general public, as in beta testing and they get a reward for finding software bugs.

Crowdsourced product testing makes it imaginable for a larger variety of people to try a product in a superior range of conditions than what is possible in-house, often leading to glitches being found that might otherwise only be revealed by consumers.


It's practically impossible to test the vast number of devices, OS and various configurations of software that applications can run on today. What if the software is meant to be run anywhere and you have a key obstacle to traditional test methods? How can the code be tested efficiently in every geographical region? The best substitute would be for people that are native to the country, people that are most likely the end-users, to test and assess the software.

This process had clear advantages, such as reaching a wider range of testers and a potentially higher ROI for the testing process. However, there are definitely disadvantages as well, such as difficulties in confidentiality and communication between all parties involved.

Advantages
  • Wide range of testers provides diversity in their experiences
  • Allows testing with all kinds of different parameters like different browsers, connection speeds, devices and OS to which the in-house testing team may not have access
  • As there is larger group involved, it is more likely to find reproducible bugs than a handful of testers.
  • As there are large number of testers testing a software concurrently, testing can be done speedily, giving more time to market
  • Testers performing this form of testing are unbiased towards the internal concerns of the company
  • It’s very economical: the company only pays for bugs which are found instead of salaried rate which professional testers would receive
As with all things, there are disadvantages:
  • As we have to deal with large group of people here, we have to manage a large scale of workers, which is a waste of our time for management instead of resolution
  • Instant and prompt communication with a group of crowdsource testers can be difficult due to time or language barriers. It will again result in increased need for management oversight
  • Confidentiality is the biggest challenge here and must be managed properly.
  • Rigorous analysis of the feedback is essential as the feedback is both from rookie and experts
  • Well-timed and prompt feedback is an immense challenge in this type of testing
  • Most imp, there’s no agreement in most cases. So testers can run anytime they want and your prototype might be reused in anytime.
 There are companies that prefer to use crowdsourcing in addition to or support of their own in-house testing teams. This provides a much more in-depth testing process, but can sometimes lead professional testers to feel that their skills are being undervalued and outsourced to those who are less qualified.

Few Companies that provide crowdsourcing testing solutions are:





Comments

Popular posts from this blog

How to Unzip files in Selenium (Java)?

1) Using Java (Lengthy way) : Create a utility and use it:>> import java.io.BufferedOutputStream; import org.openqa.selenium.io.Zip; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.IOException; import java.util.zip.ZipEntry; import java.util.zip.ZipInputStream;   public class UnzipUtil {     private static final int BUFFER_SIZE = 4096;     public void unzip (String zipFilePath, String destDirectory) throws IOException {         File destDir = new File(destDirectory);         if (!destDir.exists()) {             destDir.mkdir();         }         ZipInputStream zipIn = new ZipInputStream(new FileInputStream(zipFilePath));         ZipEntry entry = zipIn.getNextEntry();         // to iterates over entries in the zip folder         while (entry != null) {             String filePath = destDirectory + File.separator + entry.getName();             if (!entry.isDirectory()) {                 extractFile (zipIn, filePath);            

Encode/Decode the variable/response using Postman itself

We get a lot of use cases where we may have to implement Base64 encoding and/or decoding while building our APIs. And, if you are wondering if it is possible to encode/decode the variable/response using Postman itself or how to encode/decode the token or password in postman and save it in a variable? To Base64 encode/decode, the quickest way is to use JavaScript methods btoa, atob: atob - It turns base64-encoded ASCII data back to binary. btoa - It turns binary data to base64-encoded ASCII. Sample code : var responseBody = pm.response.json(); var parsedPwd = JSON.parse(atob(responseBody.password)); // presuming password is in the payload pm.collectionVariables.set("password", parsedPwd);

The use of Verbose attribute in testNG or POM.xml (maven-surefire-plugin)

At times, we see some weird behavior in your testNG execution and feel that the information displayed is insufficient and would like to see more details. At other times, the output on the console is too verbose and we may want to only see the errors. This is where a verbose attribute can help you- it is used to define the amount of logging to be performed on the console. The verbosity level is 0 to 10, where 10 is most detailed. Once you set it to 10, you'll see that console output will contain information regarding the tests, methods, and listeners, etc. <suite name="Suite" thread-count="5" verbose="10"> Note* You can specify -1 and this will put TestNG in debug mode. The default level is 0. Alternatively, you can set the verbose level through attribute in "maven-surefire-plugin" in pom.xml, as shown in the image. #testNG #automationTesting #verbose # #testAutomation