Tag: crowdsourcing

5 Traits of successful uTesters – Part 1

Originally posted at: https://www.utest.com/articles/5-traits-of-successful-utesters—part-1

The Ability to Cope with constant Change

There are many traits that testers must have in order to be successful. A quick Google search for “traits of a successful tester” will produce several articles on the subject. However in this article series, I wanted to focus on the traits that are of particular importance to uTesters.

At Applause (uTest) our approach to testing is quite unique. Testers who had success at a typical testing shop are not guaranteed to have success here. Conversely, people with no prior testing or even IT experience, often become highly respected and sought after uTesters… providing that have these particular qualities.

This will be a 5-part series and in this Part 1, we are going to discuss the importance of the ability to cope with constant change.

Probably one of the most unique aspects of being a uTester is that we test an incredibly large and ever-changing set of products. Instead of working for one company and testing the same product(s) over and over, uTesters test hundreds of different products for hundreds of customers every day. Some of the top uTesters have literally tested over a thousand different products.

The top uTesters work on several products at any given time. In order to be successful, they need to be constantly analyzing the context that they’re working in. Which product am I testing? What is the state of the product? What is the goal of this cycle? If a uTester fails to test within the correct context, they’ll find that their work provides little or no value.

Just as every product is different, so too are the needs and expectations of every customer. One customer may have extremely specific reporting standards. They require bug titles to follow a detailed format, they have attachment requirements and expect several pieces of additional data. However, the next customer may not have any requirements and is just happy to be receiving bug reports at all.

uTesters need to be able to quickly switch from context to context and from one set of customer expectations to another, often several times per day. This is no simple task, but it’s the first trait all the best uTesters share.

uTest’s Testers of the Quarter (2014 Q3)

Back in August 2014, uTest launched a brand-new community-wide recognition initiative badgeTesterOfQuartercalled Tester of the Quarter“. The goal of this quarterly program is to recognize and award the rock stars of our global community. The program is based on nominations and votes from members of the community.

Here are the categories:

  • Outstanding Forums Contributors
  • Outstanding Bloggers
  • Outstanding uTest University Instructors
  • Outstanding Tool Reviewers
  • Outstanding Project Managers of the Quarter
  • Outstanding Test Team Leads, Tester’s Choice
  • Outstanding Testers, Test Team Leads’ Choice
  • Outstanding Up-and-Comers, Test Team Leads’ Choice

Here’s the announcement for the winners for 2014 Q4:

Yours truly won the award for:

In addition to the quarterly awards, uTest also created a Hall of Fame to honor the top testers in our community…past and present.

Some Thoughts on Functional Testing

I wrote this as a Guest Blogger for the uTest blog.

There is an age-old expression that says “You only have one chance to make a first impression.” This is a hard truth in today’s world of instant gratification. If your product fails to deliver the first time, your customers will simply move on to the next thing. In-the-wild functional testing, as provided at uTest, is similar to a dress rehearsal for your application. Your application is exposed to a group of people who accurately represent your potential user base. They can identify and report the issues (that would have negatively impacted your customer’s first impression) before your customer ever has the chance to see them.

A functional tester has the ability to evaluate individual features of an application. They are familiar with typical application behavior and have the skills needed  to look objectively at a feature and see what’s wrong.

Perhaps even more valuable is a functional tester who is able to analyze individual pieces of an application within the context of the entire application. A functional tester looks at a particular item, identifies integration points between that item and other parts of the application, and then formulates a plan of how to inspect those touch points. Applications are usually weakest in places where different parts come together. A strong functional tester knows this and knows how to exploit those weaknesses to identify any lurking bugs.

Functional testing will only be successful if an organization’s underlying quality fundamentals are solid and everyone clearly understands how testing helps achieve the goals of the business. Functional testing is only one of many activities that collectively comprise a comprehensive testing strategy. Depending on the needs and expectations of your company, different testing activities such as performance, load, and security testing should be considered. Functional testing differs from other types of testing in that it most closely reflects the experience of the users. While performance affects the experience and security issues add risk to the experience – how the application functions IS the experience.

Is uTest a Scam?

There are some reviews out there from testers claiming uTest is a scam and that you can’t make any money. I’ve also seen a few uTest customers complain about the quality of the testing and uTest’s sales/negotiating practices. These concerns are valid and I can understand why some people have the impression that uTest is not what it claims to be. In order to address these perceptions, we need to look at them from two points of view; The view of the customer, and the view of the tester.

The uTest customer

Complaint #1: The quality of the testing was lower than expected

I have no problem saying that there are a lot of bad testers at uTest. It’s true, there is no point in denying it. These testers only report low-value bugs, they don’t follow instructions, and generally disrupt the test cycle. Sometimes it is because they’re inexperienced testers, sometimes they’re just plain bad. Unfortunately this is one of the downsides of crowdsourcing. To uTest’s credit, they do realize this and are continuously working to improve the skills and abilities of uTesters. They also identify and remove problem testers.

On the other hand there are some absolutely awesome testers at uTest. These top testers consistently provide the customer with excellent service and high-value bugs. uTest does a pretty good job of identifying the strong testers and ensuring that they are the ones working on your projects. Keep in mind that there are literally hundreds of projects, dozens of Project Managers and thousands of testers from all over the world, so every test cycle is going to be different.

So what’s a customer to do? First you need to manage your expectations. Understand the limitations and benefits of uTest and make sure they align with your testing needs. Second, you need to be involved. Yes, uTest is a service, but the quality and success of your project is a direct result of your participation and influence.

Here is an excellent article from Elena Houser on how customers can get the most from their uTest (or any crowdsourced) testing service. It is a MUST read for any potential uTest customer: http://trancecyberiantester.blogspot.com/2012/10/crowdsourced-testing-lessons-learned.html

Complaint #2: The uTest sales process is shady

In full disclosure, I’m not a uTest customer so I’ve never gone through this process myself. However, I am a uTest TTL (Team Test Lead) and so I have worked with many different customers. I’ve seen customers who are extremely satisfied and those constantly complain. It doesn’t take long before you start to see a pattern.

I really could just do a copy/paste from above. Again, this comes down to having correct expectations and being involved. Customers who follow Elena’s advice will find that uTest’s services are well worth the money and effort. Those who don’t will be disappointed with their results.

Another point worth mentioning is that uTest is a start-up company. They have only been around a few years yet they are growing and changing incredibly fast. In just the last year I’ve seen some impressive improvements. I have no doubt that as the company matures and customer needs and expectations are better understood, the sales experience will improve and mature as well.

The uTest tester

Complaint #1: uTest is a scam

As I mentioned above, uTest is a start-up. The company grew faster than many people expected and as a result it went through some obvious growing pains. Everything about the company was (and still is) evolving. The payment process was still being worked out, bug reporting and evaluation was confusing, and in general the tester experience gave some the impression that uTest was either a scam or just unprofessional.

Admittedly, the first tester interface was terrible. It was slow, buggy, and difficult to use, which is quite ironic for a software testing company. This problem has now been addressed. uTest recently launched their new tester platform and it is so much better (read more here). Their are now several reliable ways for testers to receive payment, and there is an entire team of employees solely dedicated to the welfare of the testers. These are just a few examples of how uTest is working to improve its image and show testers that uTest is a legitimate company and a great place to work.

Complaint #2: You can’t make any money

I recently read a review from a uTester that he had reported 87 bugs but he only was paid for 16 of them. The other 71 bugs were rejected. He felt that bugs were intentionally rejected in order to avoid paying the testers. He’s not the only one to complain that testers are not adequately compensated for their efforts. Fortunately it is because of a few misconceptions.

Testers need to understand the uTest bug payment model. Customers pay uTest a set price for an agreed upon amount of work. It is up to the customer to accept or reject the bugs reported by the testers. uTest then pays the testers for the bugs (and other work) the customer accepted. Since the customer pays a flat fee no matter how many bugs are reported or accepted, they have no financial incentive to reject individual bugs. Bugs are rejected for valid reasons, not to avoid paying for them.

The other important point is testers are not paid for their efforts (there are some exceptions), they are paid primarily for the value they provide. Testers who provide the customer with high-value bugs make a lot of money. Testers who report low-value or “junk” bugs make very little money.

The bottom line is good testers can make good money working at uTest. Poor testers will be frustrated.

Conclusion

uTest is not a scam. It is a legitimate company and an amazing one at that. While uTest is not perfect, most criticisms can be answered if you look at the entire situation objectively.

uTest Review From a New uTester

Back in March of 2012, I was listening to a podcast from SoftwareTestPro.com and they were talking about this thing called uTest. I decided to check it out.

What is uTest?

My first impression was “oh great, this is just another rent-a-tester website”, but as I looked a little closer I realized that this this company was much more powerful then I thought. uTest takes advantage of crowdsourcing (or in-the-wild testing as they call it) by distributing the work across people all over the world. In a matter of hours a website or app can be tested by dozens of different device configurations by real world users as well as professional testers.

Companies who have something they need tested hire uTest and their army of testers to perform the testing tasks. Testers are paid per bug found and per test case wrote or executed. The more valuable the customer finds the bug or test case, the more money the tester is paid.

This provides tremendous value for both companies and testers:

Companies get their products tested much quicker and cheaper then they could with in-house testers. They can have 100 testers working for one week vs. having 5 tester test for 20 weeks. Plus, they only pay for work they find valuable.

Testers get the opportunity to work on many different types of testing tasks, projects, environments and basically get exposed to things not available in their daily job. Getting paid is nice too.

Obviously there are downsides to this testing approach. For example, uTest testers don’t know or have time to learn your business or all of the intricacies of your product, so uTest shouldn’t be used when a deep level of understanding is needed. However, there are many projects where just having a hundred different eyes on on the product is exactly what is needed.

My First Test Cycle

The first project (called a test cycle) I worked on was an unpaid “interview” sandbox test cycle. This is an opportunity to try out to become a uTest tester. The task was to test NBA.com. There really wasn’t much in the way of requirements or instruction, except that you could only report 4 bugs and they had to be within the NBA.com domain. We would be evaluated on the value of our bugs and our ability to follow directions.

Since this was an audition, and I was limited to only 4 bugs I knew that each bug was very important for my evaluation. It’s hard to judge someone’s ability based on just 4 bugs so I needed to make their job easier. uTest rates bugs on a value scale: somewhat, very, and exceptionally. I wanted to be the top ranked tester in the cycle so in order to do that I thought about the assignment, the constraints, and the customer and came up with a plan.

My plan was to find different types of bugs in different locations within the site that would show my technical knowledge and testing expertise. Solid communication skills are a must in an online-based work environment so I’d need to make sure my bug reports where clear and descriptive.

Through my testing, I found dozens of bugs and I could have easily just logged the first 4 I found and been done with it. But I was very careful to make sure that I only reported those that fit into my strategy and represented my abilities as accurately as possible.

My value as a tester can be found in my strategy; how I went about finding and reporting bugs to accomplish my goal. All testing should be driven by a mission or it serves no purpose. In this case my mission was to be the highest rated tester so all my testing was done with that in mind. The actual work I did was really just “operational effectiveness” and should be expected for any good tester.

Results

  • I received the highest rating out of all 107 testers in the cycle.
  • I was the only tester who had all 4 bugs bug reports rated higher then ‘somewhat valuable’ ( I had the lone ‘exceptionally valuable’ bug report)
  • My overall uTest rank was higher then 33% of the 55,000 uTesters (Not too bad for only having 4 bug reports submitted)
Overall, I’d say my strategy worked out nicely. I don’t point this out to brag (well, not entirely), but to show the importance of a mission and a formulating a strategy to accomplish it.

Lessons Learned

From a customer’s point of view the power of crowdsourcing is amazing. The shear volume of bugs we uncovered in just a few days shocked me, especially considering how heavily trafficked that site is.

For testers, the opportunity to see the work of 100 other testers is priceless. There were several very solid testers in the cycle who had fantastic bug reports. I was able to glean some useful knowledge and techniques from reading through their reports.

The tester talent pool is sadly shallow. It surprised me just how clueless the majority of the testers were. Of the 219 bugs that were reported, 71 were rejected because the tester didn’t follow the simple instructions. It was obvious that the majority were clicking around aimlessly and reporting anything they could find.

The gap between a good tester and a bad tester is wider then I thought. Thankfully uTest takes this into account. Only testers ranked in the top 30% of the sandbox test cycle are allowed to join a paid test cycle. This allows uTest to filter out the majority of the poor testers. Also, lower ranked paid testers are limited in the amount and complexity of projects they can participate in while highly ranked testers are offered many more test cycles. This helps ensure projects have the best possible testers, keeps poor testers out, and gives new testers the opportunity to prove themselves.

I’m a now a raving fan of this company and crowd sourcing (or team sourcing as uTest calls it)!

Learn more about uTest at utest.com.
You can also check out my uTest profile here.