Our featured uTest guest blogger this month is Elena Houser. Originally from Russia, Elena got her start in IT with UUNet Technologies. Eventually, she caught the testing bug and has been testing for the last 7 years.

She studied software testing under the guidance of James Bach (Satisfice) and Matt Heusser (Miagi-Do School of Testing). Shortly thereafter, she was named a winner of the 2010 uTest Bug Battle and achieved “Gold” status in the uTest community.

You can learn more about Elena by reading her blog, following her on Twitter or by checking out her uTest public profile.

In this post, Elena covers her recent fascination with mobile app testing. Enjoy!

****************

When I was growing up in Siberia I dreamed of becoming either a ballerina or a painter. I have always loved ballet and dancing and I also enjoyed painting Siberian landscapes in watercolors. For the longest time I thought that I was more of an artistic or right-brain type person. I am still not sure how I ended up working in the Information Technology field.  At some point, I found that I loved breaking websites (aka testing) and haven’t stopped since.  I catch myself testing my son’s electronic toys, neighbor’s coffee machine as well as countless smartphones…which brings me to my latest passion: mobile app testing. In fact, I’m writing this post on a break from a very intense work week, during which I tackled 7 uTest projects – with 5 of them being mobile projects!

Testing mobile apps is interesting, fascinating, challenging and frustrating. It has been an amazing and eye-opening experience for me. I am still very new to it and have more to learn. I tested my first mobile application during the uTest Bug Battle last November. Since then, I have participated in over 30 mobile test cycles through uTest and reviewed a variety of applications from games to browsers to enterprise resource planning (ERP) apps.

I want to know what kind of devices, applications and providers my friends and neighbors are using. I bombard them with questions on what they do and don’t like about their smartphones and providers, what kind of apps rock their world or make them want to throw their phones against the wall. Do they use mobile vs. native apps? How do they figure out navigation and flow, what do they think about a particular page layout, colors, sounds, portrait vs. landscape view, web-surfing and social media experience? Many of them check their bank statements and pay their bills, write memos, take snapshots, watch movies, use it as FiOS remote control, listen to the radio, play Angry Birds, Stupid Zombies and other games. I take notes. I try those apps myself. I install some of them on my Motorola Xoom even though many are still not optimized for it. It’s fun to launch an app and try to figure out how it works, what buttons to tap, and also picture the data moving behind it.

Just as with a web site the following three things matter the most for mobile apps – presentation and page layout, organization (flow and structure) and interaction (what happens in response to user actions). The difference is that a phone screen is very small and the capacity of a mobile device is not the same of a web site, which makes functional testing pretty challenging. Not to mention that some mobile applications may work on iPhones but then fail on either installation or launch on Android phones.

Being familiar with your bank or another web application certainly helps navigate through a mobile app. However, things like small screen size, and a lack of “physical structure” with familiar sights that you can use to orient yourself (this is true for the Internet in general), present a challenge in figuring out how mobile apps work. Well-designed applications will not only tell users what they can find within the app, but also where they can find it. If the app is organized well, then guessing where to look for additional functionality is easy. There are still many applications which have a great page layout, presentation and interaction features but they are not well-organized and thus confuse users which may result in the user un-installing the app and leaving unfavorable feedback. As a tester, I am trying to analyze and capture all the pros and cons and report them either as issues or feedback and also write a usability review.

I have recently added an iPad2 to a family of Android and Palm devices that we share in the family. I am now determined to learn how to test applications build for iOS. I don’t have any regrets that I did not become a ballerina. And when I feel like dancing I can swing by a local dance studio and dance my heart out. I did not make a Prima Ballerina but I can compete with Napoleon Dynamite. Or I can use my smartphone to watch the Swan Lake ballet on YouTube while waiting for my doctor’s appointment. The most important thing is that I am doing what I like most – testing and learning about different technologies and enjoying the unlimited potential of human creativity.

Editor’s note: If you would like to contribute to our Guest Blogger series, email your entries to me at mikeb@utest.com. Thanks for reading!

Earlier this week, we announced that uTest achieved more than 3X increase in year-over-year revenue. And as you can see, from the pictures to the left, we moved into some new office space in our Boston-area headquarters. And beyond all that growth, we found time to receive some rave reviews from the media and accept an award or two.

For those of you keeping score at home, here’s a recap of the recent goings-on at your favorite software testing company:

Customer, Community & Company Growth

• Signed 70+ new customer deals with innovative startups like Groupon and AirBnB; as well as with established category leaders like AOL, Virgin Airlines and Aetna
• Added 3,000+ testers to pad our lead as the world’s largest testing community — that brings us to 33,000+ professional testers from 172 countries
• Pitted the top specialty e-tailers against one another in another epic Bug Battle. During this competition, more than 600 testers from 28 countries discovered nearly 900 bugs in the web and mobile apps of eBay, Overstock.com and Zappos; check out one of the write-ups at Internet Retailer
• Added a bunch of new members to the uTest family, increasing our employee base by more than 20%.  And as you can see throughout this post, we also moved into some killer new office space

New Product Stuff

• Public Tester Profiles & Badges: With our new public profiles, testers can display their memberships and exemplary uTest ratings (bronze, silver or gold badges) for all the world to see. Testers can also now add their uTest badges to their personal site, blog, resume or email signature.
• Social Sharing: we launched a new social sharing feature that enables uTesters to share their profiles and testing accomplishments on Facebook, Twitter, or LinkedIn directly from their uTest accounts. For example, a tester can let the Twittersphere know that he just earned a silver badge or that he published his public profile.
• Accept/Decline a Test Project: Testers can now accept or decline a test project based upon their availability. This gives uTest much better visibility into each project so we can more precisely gauge whether or not more testers should be invited to meet each customer’s schedule and requirements.

Press Praise

• Venture Capital Journal in “Should You Join The Crowd?”
• ST&QA Magazine in “The Crowdsourcing Testing Model”
• And earlier this week, we were named to the Red Herring Global 100 list of hottest private companies

It was a big quarter for us, but we’re not getting cocky… we’ve got big plans for 2011.  And as always, we know that we never could’ve done it without our customers (who care more about their users & apps than any rational person should) and our testers (who share that passion for apps that make users smile).

Finding unique bugs in a software application is never easy. It’s even more difficult when you are working with dozens of other testers from around the world. In our latest guest post, uTester Amit Kulkarni – a recent Bug Battle winner – offers testers some advice for finding unique bugs when multiple issues have already been reported.

When working on test cycles in the uTest platform, it’s important to remember the model they follow. For instance, once the test cycle is open, it is made available to invited testers from all over the world, unless the customer has chosen specific criteria like geographical locatio, specialty, experience etc. And because there are different time zones, you may find yourself in a situation when you accept the invite for the test cycle and there are already a good number of bugs logged. So common, isn’t it?

Now here is the catch: Some testers wonder how do they go about it? There are already a lot of bugs logged, what should I do? How am I going to find a bug now? Well, first I would say calm down. Understand the application and what is expected from the test cycle. Once you are done with this, take a look at the bug reports already logged by other testers. This will give you an idea as to what part of the application has been tested so far, and what has yet to be tested.

I often feel quite lonely when there are no bugs logged when I accept an invite (a rare occurrence however). I would prefer to work with other testers as a team to make sure the outcome is what is expected by the customer before creating the test cycle, but that’s not always possible. That being the case, would you like to know how stand out from the other testers?

Here’s my advice:

Be Creative: In such situations you have to be creative with your test ideas. Think of scenarios that have not yet been tried. This is where you’ll save time by first understanding the duplicate bugs. It may sound hard, but it is time well spent in trying to understand the application and the scope for the test cycle. This creativity not only helps you for this particular test cycle, but will prove to be useful in other situations as well. So the point that you need to remember is this: Don’t just look for simple bugs.

Go through the other reports logged and try to reproduce the bug and see if you can dig deeper for serious bugs. It does help to generate quite a few new ideas if you take some time and spend in reading other tester reports.

Be Patient: This one of the key attributes for a tester – not only just for those working on uTest projects. Keep your cool, understand the application, and try to come up with test ideas that may yield some fresh insight. Because you are working with testers all across the globe,  it may possible that the test idea that you just thought of has been implemented by other tester, but that should not make you impatient.

Be an Explorer: Just don’t look out for the simple bugs that do not need much more exploration, although if you find them that is all well and good. Explore the application by targeting specific parts of the application. When you start exploring the application you will begin to distinguish the deeper issues, instead of bugs which are just on the surface.

While exploring the application makes sure that you are still very much in control of what are you trying to. At times exploration leads to the part of the application which is not yet suppose to test, so just be careful! Remember to read the scope of the test cycle before you do anything.

Be Agile: It is good to be agile, but it’s important not to lose your focus. Make sure that you are taking proper notes, taking screen shots or videos, or even using tools like Session Tester.

So, if you are ready to practice all the above then you are certainly going to have good time while working on the test cycles. Not to mention that it also helps you in planning/splitting your tasks as you move further along.

So, the next time if you accept an invite and see bugs logged, you got to know what to do, right?

• eBay placed first in every survey category and recorded the fewest bugs overall (220 bugs)
• Trailing eBay in the number of bugs was Overstock.com (314 bugs), closely followed by Zappos (354 bugs)
• Fraud protection, product search accuracy and overall usability were the most important factors when choosing an e-tailer
• Zappos came in second in the category of product search accuracy and ease-of-use, while Overstock.com came in second for fraud protection and low prices
• 65 percent of respondents trust eBay most for their holiday shopping

You may also check out the story on BostInnovation and Internet Retailer. All said and done, nearly $4,000 in prize money was distributed amongst 22 winners, covering Top Tester(s), Best Bugs (Web and Mobile), Best Usability Feedback, and finally Honorable Mentions. The complete list of winners is found here, and the noteworthy winners are again highlighted below for their outstanding accomplishments:

• Top Testers: Anna Danchenko, Nicola Sedgwick
• Best Bugs (Web): Aline Gazeau, Anna Danchenko, Gagan Talwar
• Best Bugs (Mobile): Thiago da Silva, Ryan Arnaudin, Zarina Mohammad
• Best Usability Feedback: Amit Kulkarni, Nicola Sedgwick, Anna Danchenko

Congratulations to all of the winners of the Q4 Bug Battle! If you missed out on the opportunity to participate this time, be sure to read the following blog posts from previous winners to gain insight prior to our next competition: Santhosh Tuppad and Anna Danchenko.

And while you’re at it, if you have any suggestions for our next quarterly testing competition, send them our way at marketing@utest.com.

Today, we are thrilled to announce a 300 percent increase in year-over-year revenues in the recently-ended Q3. During this time, uTest closed a $13 million C Round of financing (led by Scale Venture Partners) – one of the largest investments ever made in a crowdsourcing company. We also launched cool new features and functionality, such as social sign-in, dynamic reporting and integrations with more bug tracking systems.

In Q3 2010, uTest also:

• Signed 120+ new customers, including innovative category leaders The Associated Press, The BBC, The Container Store, Urbanspoon, Box.net
• Acquired 2,500 new software testers, growing the community to 30,000+ professional testers from 168 countries
• Added Scale Venture Partners Managing Director Sharon Wienbar to the Board Of Directors
• Conducted the “Clash of the Career Sites” – more than 500 testers from 22 countries discovered nearly 700 bugs in the web and mobile apps of Monster, CareerBuilder, SimplyHired and Indeed; see articles in TheNextWeb and TechTarget for details

And there’s so much more to come! I just want to take a quick moment to thank our fantastic global community of testers who exceed expectations and go above and beyond to meet the testing needs of hundreds of companies each day. Our third quarter results are a testament to the tester community’s commitment to excellence.

With just under five days remaining, we’ve already had more than 400 testers participate and well over 600 bugs reported. These are obviously great numbers, but it’s a little interesting to see that eBay trails the other two sites in terms of overall participants. (Hint, hint: if you want to increase your odds of winning some prize money, start testing eBay!). You didn’t hear it from me though.

Remember, the Bug Battle ends Monday, November 8th at noon ET, and there is nearly $4,000 in prize money up for grabs. It’s not too late to win the top prize, so log into your uTest account and get cracking. No more excuses!

For a primer on how to win the Bug Battle – especially the usability part of the competition that gets started next week – we highly recommend this post by Santhosh Tuppad, as well as this post by Anna Danchenko. You can also find tips in the uTest Forums.

Good luck the rest of the way!

As you probably know, the latest uTest Bug Battle is officially underway. This means that for the next week, testers from around the world will be competing to find bugs in three prominent e-tail sites. But there’s a lot more to the competition than just submitting some random bugs and hoping for the win. In our latest guest post, uTester Anna Danchenko (a former Bug Battle winner herself) offers some advice to testers on how they can best position themselves for Bug Battle success – and of course, some prize money for good measure.

*******

The Bug Battle is a software testing competition open to anyone on the uTest website. The essence of this quarterly competition is simple: You have about a week to find and report defects in the pre-selected websites or applications. The results will be judged on several criteria such as: the “clarity of the bug report”, the “innovativeness of the bug” and the “depth of understanding of the problem.” To put it simply, the more serious the bug found and the better its description, the greater your chances are of winning the battle. As a top tester in Q310 Bug Battle, I’m going to offer some advice on how to find the worst bugs and how to write the best bug descriptions.

I will start with an overview of the available materials that newcomers can use to get ready for the competition. After this, I will move to the main topics: how to find defects and how to write bug reports. Finally, I will write some recommendations on completing the final stage in the competition: feedback survey.

Available Materials
This section is a collection of the important links to be explored by uTest newcomers. I have divided it into 3 parts: “Registration”, “Bug Battle” and “Bug reporting in uTest”. To participate in the Bug Battle you need to be registered in uTest. In addition, I highly recommend that you become a member of uTest forum. This is an invaluable resource for learning about past Bug Battles, uTest and testing. In the “Bug Battle” section there are links to pages with the competition rules and advice from other participants on how to win. The last section on bug reporting contains the most important resources with uTest recommendations. I will comment on how to get the most out of these resources because a good bug report is one of the keys to getting the Best Bug award.

Registration
Join uTest
Join uTest forum

Bug Battle
Help section: “What’s a Bug Battle and how does it work?”
Forum thread “Is This Your First Bug Battle? Click Here To Get Started!”
Forum thread “How to win the Bug Battle”
Blog post “How I Won the uTest Bug Battle (and how you can too!)” by Santhosh Tuppad

Bug Reporting in uTest
Help section “How do I report a new bug?”
Help section  “Bug Title (Subject Line) Standardization”
Help section “How do I classify bug type (GUI, Functional, Technical)?”
Help section “How do I classify bug severity (Show stopper, High, Medium, Low)?”
Help section “How do I document and prove that a bug is real?”
Crash Course “Bug Reporting 101”
Crash Course “Bug Reporting 102”
Forum thread “The secrets of a good bug report”

At first glance there seems to be a lot of information on the bug reporting and it’s easy to get lost in the classifications and the guidelines. Fortunately, there is a simple way to get a clear understanding: repeated practice. Write down all the fields from the screen shots of the uTest bug tracker (see “How do I report a new bug?”) and fill in the fields with the real defect descriptions.

Some experienced testers might wonder why they need to practice with bug reports? The main reason is to get used to the uTest format which might be different from your reporting conventions. For example, there are less fields in the bug tracker than I used to have; report title can’t be more than 100 characters and there are only 3 types of defects. You might find even more surprises when writing a bug report in the uTest format. To uncover all of the differences, and have time to adapt your style to the expectations, you need to practice writing bug reports according to the uTest guidelines.

Bug Hunting
In this section I will do 2 things; firstly, share links to the well known “must-read” materials, and secondly, write about my own way of testing that has been highly influenced by these well known sources.

Must Read

•    Michael Hunter’s checklist “You Are Not Done Yet”;
•    Materials from “Rapid Software Testing” course by James Bach and Michael Bolton:  Slides and Appendices;
•    Materials of “Black Box Software Testing” course by Cem Kaner and James Bach;
•    Book “How to Break Software: A Practical Guide to Testing” by James A. Whittaker.

My Approach to Testing
I want to repeat that almost everything I will say later in this section is not new and has already been described in the materials in the “Must Read” section. In describing my approach, I will show how I apply some of these methods. In a moment you will see that the whole process is all about asking questions and looking for answers.

Start testing by defining your context and your mission. This is the “light” that will help you with finding the right direction later on in the testing. What is my mission in the Bug Battle? My mission is to find serious bugs or at least interesting bugs, so I’m not looking for simple broken links. What is the context? In general, the context is some alive and highly-used website or application without any requirements or experts available: only the help section and my own common sense. How to start testing? Start with the proper attitude: all software contains bugs. Do not be fooled by shiny welcoming screens. All software contains bugs and some of them are waiting just for you.

Where to start testing? With the proper attitude you can start from any place and this is time to remind yourself about the mission and the context. Do you expect to find serious bugs in a core feature used by thousands on a daily basis? If you were a test manager of an in-house test team for this website what would you choose as the most important features to test? Do you (now as yourself and not as a test manager) want to re-test these features? What might you (now as test manager and not yourself) forget or exclude from your plan? Are there more chances of finding issues if you look into new features? Are you sure that you know what features are available? Are you sure you know how the user will use the feature? How do you know that the result is correct? What are the typical data used by majority of users? Do you want to re-test with typical data? What other specific questions are important to ask? Do you need help with building other questions by yourself? If your answer is yes, then read the materials listed in the section “Must Read”. If your answer is no, then find the bug that is waiting for you and we’ll move to the “Bug Reporting” section.

Bug Reporting
Let’s say you’ve found a defect and you want to describe it. This simple reporting task becomes a challenge if you need to follow an unfamiliar format or if you have no experience with bug reporting. If you belong to the first group then consult with the resources from the section “Bug Reporting in uTest”. For the second group I would suggest reading “Painless Bug Tracking” by Joel Spolsky and only then moving on to the section “Bug Reporting in uTest”.

You might ask why I list all of these resources and insist on reading them again and again? The answer is because it’s how I started with bug reporting on uTest. Although I have about 10 years experience with describing found issues, I’ve studied each recommended page carefully to know the uTest rules and follow them. And to be honest, I was amazed by the number of Bug Battle participants who demonstrated little knowledge of uTest recommendations on the title format or the report content. It’s as if you found a “diamond” bug and then immersed it in the “mud” of a sloppy bug report. Great bugs need great descriptions, so read and apply the uTest guidelines, and your “diamond” bugs can be valued by everybody.

At this moment in time, I am assuming that you have practiced with bug reporting in the uTest format. My other assumption is that you have some questions and doubts about it. How do I know? Because I had questions and doubts too. Fortunately, all of my questions were answered and I will share some of those answers with you now.

My first question was: where is the “summary” field? Where I can put the complete bug description before writing 15 long steps to reproduce? Will any reader stay with me and read these steps without getting a general idea of the problem? What to do if I cannot describe a problem using only 100 characters of the bug title? The solution is to look again at the screen shots on the page “How do I report a new bug?”. In particular, find the picture “Action Details” and look at the first field “Action Performed” with an example of the content. This example fully answers my first question: if you do not have a separate field to write a summary then use the existing field “Action Performed” and split it into 2 parts: the first part “Overview” will contain the summary text and the second part “Steps to Reproduce” will contain a detailed description on how to reproduce an issue.

The second question concerns the steps to reproduce: How to write a single step? How detailed should it be? Should I write “click on button Save to save a note” or just “save a note”? Are there any examples of the “golden” bug description? When I asked these questions myself I didn’t find any guidelines from uTest and decided to keep using my own pattern.

Here is the pattern for a single step:

place + action + data + GUI + data values + result

Explanation:

1. Place – the place where the action should be performed. For example: On the page “Resume examples”;
2. Action + data – the action to perform and the data for this action. For example: sort the list of resumes by the date posted. Another example: log in as an administrator user;
3. GUI + data values – how to perform the action using GUI elements and the exact data value(s) used for the action. For example: click on the header “Date” in the table “Resumes”. Another example: in the field “Login” enter  “administrator”, in the field “Password” enter “123″; click on the button “Sign in”;
4. Result – the result of the action. Example: As a result, page “Resume examples” is refreshed and list rows in the table “Resumes” are sorted by date. Another example: As a result, the tab “Administration” is shown at the top of the page.

And now, an example of the complete step: “On the page “Resume examples” sort the list of resumes by the date posted: click on the header “Date” in the table “Resumes”. As a result, the page is refreshed and the resumes list in the table “Resumes” are sorted by date.”

Using this structure it’s easy to describe: the place, the action, the data values, the GUI elements and the expected result. This level of detail provides the reader with both a concept and a concrete way of performing the step. For a user who knows an application it will be enough to read the concept part. For a user who needs details you have precise names of all GUI elements along with the directions on how to use them. Both users can read the result description, so they know when the step is finished and they can proceed to the next step.

The last question I asked myself was about the quality of my bug reports: Are they good enough? How can I check that they are as good as they appear to me now? Fortunately, I found the solution in the middle of bug battle: I re-read my reports 2-3 days later and this simple exercise helped me to notice what could be improved. The secret is to feel like a “first-time” reader and not an author.

As a reader I have only the text of the bug report. I have no “vivid demo” in my head of how an application crashed 10 minutes ago, I’m just starting to build this “demo” and familiarize myself with the found problem. I’m not in a hurry to warn the world about the crash. I’m interested in small clear steps on how to “arrive” at the crash. And this is the moment when you start to notice some omissions in steps, unclear directions and other surprises from your own bug report.

So, invest your time in re-reading and you will see what can be improved. I know that it’s not very natural for testers to come back after 2-3 days and edit defect descriptions. On the other hand, bug battle is also something that doesn’t happen on a daily basis. The only outcome of the competition is your bug reports and one of the criteria they will be judged on is the “clarity of the bug report”. Remember about this and find some time to check the clarity by yourself. In fact, I was re-reading and editing each of my 12 reports about 4-5 times and I think that such an approach helps with getting the “top tester” award.

Feedback Writing

According to the Bug Battle rules: “Once the competition has ended, all contestants who submitted bugs will be sent a link to a feedback survey. …  Submissions for this portion are optional, however we strongly encourage those interested in Top Tester to complete the survey.” The feedback survey looks like a set of multiple-choice questions with predefined answers except in the final part. There you have to write the most important comments about each of the tested websites as if it would be read by the website development team.

My questions when I started to write were: What to write? How many sentences? Are there any examples? Well, now I know that there are some examples in the detailed report for each Bug Battle. Unfortunately, I can’t find any part of my feedback in that detailed report, so I cannot insert a link and finish this section. Instead, I will list the key points of my feedback:

1. Write the comments as if they are for a friend who developed a website and asked you for honest feedback. Obviously, the number of “waffle” pages you can produce is not important. What is important is to write honestly and give your friend a chance to improve the website. It’s also important to compliment good features and design decisions, so that they remain on the website.
2. Use a spellchecker.
3. It’s OK to write only 3-5 sentences.
4. The following questions might help you to generate some ideas for feedback:

• Do you want to stay on the website or do you prefer other similar ones? What are the reasons?
• Do you like the general site idea? Why? (if not – then it makes little sense to write about small improvements and it’s time to stop)
• What in the website makes the difference so that you like/hate it?
• Are you missing something? What? Why do you need this “something”?
• What features/design decisions do you love/hate? Why?
• Are you using the website in your usual (not battle) life? If the answer is yes, then how often and what are your typical use cases?
• Do you need any changes in the GUI, features, structure? What are these changes and why do you need them?
• Do you have any not-reported small issues? List them here.
• Do you want to say “thanks” to some particular team members like “technical writes”, “designers”, “programmers”, “product managers”, “testers”, “translators”, others? For what exactly do you want to thank them?

Conclusion

In this article, I have given you some advice on how to win the Bug Battle. I have started with the section for newcomers to list the “quick start” pages from the uTest website. Than I have written about the resources that helped me to become a better tester and tried to demo my approach to testing. After this, I have shared my initial questions on bug reporting along with the answers which I found later. Finally, I have listed the key points for writing a feedback survey. I have tried to describe everything that helped me to become a top tester in one of the bug battles, so you can read and benefit from my “winning secrets”. I hope that it will help you to win the Bug Battle and wish you good luck in the next competition. The most important secret to remember is this: there is always one bug waiting just for you.

About the Author:

“My IT career began 11 years ago in Ukraine. I’ve started by combining developing and testing. Luckily, the customers were very close, so since that time I know how does it feel if you did a great 2-hours job that saved them a week; or if you forgot to enable “that small button”. Later on, I moved to “pure” testing (it does not mean that I didn’t program). Luckily, developers were very close, so I know how does it feel if you submit a bug without steps to reproduce, or how 5-minutes talk with developer can help you to find 10+ serious issues. Afterward, I moved to test management. Luckily, testers were very close, so I know how does it feel if 1 misprint in your test platform matrix throws away 3 days of test team’s work; or if you entrust the first test project to your recent “test trainee” who learned testing from you. Three years ago I’ve moved to The Netherlands to work as a senior tester. I’m making mistakes from time to time, so do my colleagues. Luckily, I know how to deal with these mistakes, so we can be proud with what we achieved when it will be time to move to something new.”

So which of these three sites will have the most robust feature set? Which will have the most intuitive search and product comparison features? Which one will have the most user friendly mobile application? And most important of all, which one will have the most bugs?

That’s for our community to determine. Once the testing phase of the competition is over (on Monday, November 8 at noon) we’ll be sending surveys to all participating testers, where they will compare the usability and feature set of these three applications.

At this point, I shouldn’t have to tell you about the many reasons why you should participate, but I will anyway. For one, a strong performance in the uTest Bug Battle can help you get recognized by our project managers, which means you’ll be invited to more private test cycles. It’s also a great way to hone your testing skills. Oh – and did we mention that we’re giving away $4000 in prizes across a broad range of categories?

So here’s your chance. Log into your uTest account, scour these apps for defects and report them in a clear, concise manner. And if you do it better than your peers, you could be named the Q4 Bug Battle winner and earn some big prize money for your time.

Need some pointers? This uTest Forums thread will show you how to increase your odds of winning.

Have more questions? Learn more about the Bug Battle basics.

Good luck everyone!

With the holiday shopping season right around the corner, we simply couldn’t wait any longer to kick off our latest bug-hunting competition.

At this time last year, you may recall that the Bug Battle focused on the giants of online retail. This year, as a special twist, we’ve decided to focus on specialty e-tailers. With literally thousands to choose from, we ended up going with eBay, Overstock and Zappos - three of the most revolutionary companies in the auction, overstock and traditional e-shopping spaces.

The Bug Battle gets started this Friday, October 29 at noon (ET). Testers will be given ten days (until Monday, November 8 at noon) to search these applications for the most compelling bugs, and to report them through our online platform. We’ll be awarding nearly $4,000 in prize money for categories like Top Tester, Best Bug, Best Survey Feedback (survey runs November 8-10), Best Mobile Bug and more.

More details on this Bug Battle – as well as the rules, prizes and deadlines – can be found in the uTest Forums. Of course, we’ll be providing frequent updates via the uTest blog, as well as through Twitter and Facebook.

This competition is available ONLY to members of the uTest community. If you would like to become a member, sign up here.

Happy testing!

• Indeed had the least reported bugs (139), followed by Monster (169), CareerBuilder (171), and then SimplyHired (189).
• While Monster placed first and Indeed placed last in every survey category, CareerBuilder and SimplyHired were deadlocked in the survey portion of the contest, each receiving favorable rankings in three out of six categories.
• More than half of the testers (55%) chose ‘job search accuracy’ (ability to browse relevant jobs by job title, keyword, location, category, etc.) as the most important criteria when evaluating career applications.
• When asked if concerned about the privacy and safety of personal information stored on job websites, an overwhelming 82 percent of respondents answered “yes.”

Check out the story on TheNextWeb! The $4,000 in prize money was spread out across a total of 24 testers. Here are few of the notable recipients:

Top Tester: Anna Danchenko

Best Bug: Vadim Bobrenok, Santhosh Tuppad, Anna Danchenko

Best Mobile Bug: Nicola Sedgwick, Amit Kulkarni, Zularbine Kamal

Best Feedback: Anna Danchenko, Apala Nair, Dhanshree Patil

Congratulations to all the winners of this quarter’s Bug Battle. If you missed out on the prize money, you should read this blog post by Santhosh Tuppad, were he discusses tips for Bug Battle success.

And while we’re at it, if you have any suggestions for our next quarterly testing competition, send them our way at marketing@utest.com.