The power of the mobile User Army

?

Artur Gu?a is an advanced tester who has extensive experience in many industries and methodologies. He is interested in user acceptance testing and acceptance test -driven development methodologies and has participated and managed several crowdsourcing projects, primarily mobile applications. He has a personal passion for different sports activities. If you want to discuss crowdsourcing concepts or share your experiences, please feel free to write to: [email protected]

?

? The legendary speech, which begins with the "We, the People," is still vivid, highlighting the strength of the people who have gathered together. Many years later, one person created the word "crowdsourcing", from which the idea began to flourish, and of course included in software testing.　　
? In this article, I'm going to use some of the strengths and weaknesses of the people in the mobile testing world based on my experience of using the standard and crowdsourcing approach to project.
?

the biggest challenge in mobile testing
Anyone who has ever been involved in the quality of mobile apps knows the challenges and problems that this process is facing, But allow me to introduce some of them here:
? Select device groups and their systems and versions  
? Test under different network conditions (type of network, strength, etc.)  
? Test   with GPS receivers in the mobile and different locations,
? Verify the behavior of the object being tested in conjunction with other installed applications and different customizations  
? Usability testing-it's very important. , the tester must, without any prejudice and preliminary knowledge of SUT, try to play the role of the end user.  
There are actually more challenges and problems, but I'm only focusing on those mentioned in the following paragraphs. I will compare the standard test methods (tests or outsourced tests performed in an internal test lab) and the "closed test" process, which means that, under the support and control of a professional test manager, carefully selected end users are tested in their own environment.  
?

which configuration is correct?
Let's start with the most basic question--which platform should we test our system on? Sometimes you can find that information in the requirements specification (usually a custom application), but in most cases you only know it is "the most popular Android device and system version" or something like that. The
recommended solution is to use a single column with the most popular devices (and their market share), with a coverage matrix of different operating system versions (and their market coverage).  
on the intersection of rows and columns, you will find the most matching configuration. This is a theory, but you not only need to find this configuration, but also make these devices available in your lab. That's an important question--huge expenses, especially if it's your first mobile project. There is another important aspect-the statistical coverage data provides a total of some delays, and it cannot be divided into sub-countries or even regions. This means that all your efforts provide an outdated configuration for international users, which does not meet the user target group. One way to solve this problem is to outsource and outsource a specialized laboratory to provide you with testing services. You don't have to take the time to study the market, but instead you definitely have to spend some extra money (the cost of the equipment is included in the service price in some way).  
when there seems to be no way, a new possibility arises--the power of man! Please note that when you plan to organize your beta tests, the problem of choosing the right device disappears. First, you don't have to search for current trends and market coverage, because end-user devices will only match it. Then don't think about the extra cost of buying the equipment-they've been purchased by testers. This is not all-you can still invite a limited group of testers to choose the platform you want to run your tests on (for example, according to SRS requirements).  
?

about the network
Once we've dealt with the first challenge, another new one has emerged-choosing the right network. There are an unlimited number of combinations, including types (3G, 4G, LTE, etc.) and suppliers (Orange,t–mobile and others). You need to verify your system with strong signals and very faint signals. Finally, it is important to simulate a situation where a network will automatically change (for example, from Wi-Fi to 3G). All this adds a lot of testing and preparation for you to do.
There are two solutions --Buy as many different prepaid starters as possible and go to distant places to test for various signal intensities, or let someone else do it for you. Again, when you organize a beta test, everything happens automatically.  
People just have different internet providers who live in the city center or village, and they use high-speed LTE or outdated UMTS. All you have to do is choose the configuration you need. It seems simple and effective, believe me, indeed.  
?

get out of the lab!
Most recent mobile applications use GPS receivers for certain navigational-related features. Testing with GPS is closely related to the problems described in the previous paragraphs. In addition to selecting devices, you often need to constantly move to validate your system in a real-world environment. If you can move between areas with different signal ranges, including where there is no signal, then perfect.
based on this start, you can think of localization system testing as another, but necessary, part of your plan. Once again, there's no better solution than getting your current and potential customers involved in this activity. Nowadays, people are constantly moving. With a structured infrastructure and easy access to cheap flights, it's not uncommon to be hundreds of miles a day. So, why not take advantage of this natural potential advantage? Don't use complex and expensive tools to mimic mobile and GPS positioning in a test lab. Just let your beta testers run the application, then collect their location data and send it to your server for further processing. You will certainly get enough data to evaluate and validate.  
?

　What's your favorite gadget?
There are thousands of apps available on the online store today. Everyone has their own favorites, which means that no two devices are identical. When you run some tests in the lab or use outsourced services, your tests are done on a clear device using the default (factory) settings, or, worse, you can use a platform that was previously installed with a lot of stubs and drivers for system development. This way, you will not have the opportunity to detect configuration issues involving popular applications and gadget interactions. In addition to the typical configuration errors, you should also know interoperability issues, such as inter-application, import and export business between the data transfer, I believe you know the solution to these problems-crowdsourcing. Don't guess what apps you need to use to exchange information, ask your customers directly, what they want to use with your system, and then they can tell you if it works. Of course, you have to ask the right questions and make sure that you can finally get valuable feedback.
?

Copyright notice: This article from SPASVO Software Testing network: http://www.spasvo.com/news/html/2014513142820.html

Original works, reproduced when you must be in the form of hyperlinks to the original source, author information and this statement, or will be held liable.

?