Category: Opinion

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 blog post – Certified and Proud?

I recently wrote a post for the uTest blog about my certification story. It was well received earning a good number of comments and social shares.

http://blog.utest.com/2014/08/04/certified-and-proud-a-testers-journey-part-i/
http://blog.utest.com/2014/08/05/certified-and-proud-a-testers-journey-part-ii/

 

A Gold-rated tester and Enterprise Test Team Lead (TTL) at uTest, Lucas Dargis has been an invaluable fixture in the uTest Community for 2 1/2 years, mentoring hundreds of testers and championing them to become better testers. As a software consultant, Lucas has also led the testing efforts of mission-critical and flagship projects for several global companies.

Here, 2013 uTester of the Year Lucas Dargis here shares his journey on becoming ISTQB-certified, and also tackles some of the controversy surrounding certifications.

In case you missed it, testing certification is somewhat of a polarizing topic. Sorry for stating the obvious, but I needed a good hook and that’s the best I could come up with. What follows is the story of my journey to ISTQB certification, and how and why I pursued it in the first place. My reasons and what I learned might surprise you, so read on and be amazed!

Certifications are evil

Early in my testing career, I was a sponge for information. I indiscriminately absorbed every piece of testing knowledge I could get my hands on. I guess that makes sense for a new tester — I didn’t know much, so I didn’t know what to believe and what to be suspicious of. I also didn’t have much foundational knowledge with which to form my own opinions.

As you might expect, one of the first things I did was look into training and certifications. I quickly found that the pervasive opinion towards certifications (at least the opinion of thought leaders I was learning from) was that they were at best a waste of time, and at worst, a dangerous detriment to the testing industry.

In typical ignoramus (It’s a word, I looked it up) fashion, I embraced the views of my industry leaders as my own, even though I didn’t really understand them. Anytime someone would have something positive to say about certification, I’d recite all the anti-certification talking points I’d learned as if I was an expert on the topic. “You’re an idiot” and “I’d never hire a certified tester” were phrases I uttered more than once.

A moment of clarity

Then one fine day, I was having a heated political debate with one of my friends (I should clarify…ex-friend). We had conflicting views on the topic of hula hoop subsidies. He could repeat the points the talking heads on TV made, but when I challenged him, asking prodding questions trying to get him to express his own unique ideas, he just went around in circles (see what I did there?).

Like so many other seemingly politically savvy people, his views and opinions were formed for him by his party leaders. He had no experience or expertise in the area we were debating, but he sure acted like the ultimate authority. Suddenly, it dawned on me that despite my obviously superior hip-swiveling knowledge, I wasn’t that much different from him. My views on certifications and the reasons behind those views came from someone else.

As a tester, I pride myself on my ability to question everything, and to look at situations objectively in order to come to a useful and informative conclusion. But when it came to certifications, I was adopting the opinions of others and acting like I was an expert in an area I knew nothing about. After that brief moment of clarity, I realized how foolish I’d been, and felt quite embarrassed. I needed to find the truth about certifications myself.

Now let me pause here for a second to clarify that I’m not saying everyone should go take a certification test so they can have first-hand experience. I think we all agree that it’s prudent to learn from the experience of others. For example, not all of us have put our hand in a fire, but we all know that if you do, it will get burned.

It’s perfectly fine to let other people influence your opinions as long as you are honest about the source of those opinions. For example, say:

Testers I respect have said that testing certificates are potentially dangerous and a waste of time. Their views make sense to me, so it’s my opinion that testers should look for other ways to improve and demonstrate their testing abilities.

However, if you’re going to act like an expert who has all the answers, you should probably be an expert who has all the answers.

Studying for the exam

I took my preparation pretty seriously. Most of my studying material came from this book which I read several times. I spent a lot of time reading the syllabus, taking practice exams and downloading a few study apps on my phone. I also looked through all the information on the ISTQB site, learning all I could about the organization and the exam.

Since I knew all the anti-certification rhetoric about how this test simply measures your ability to memorize, I memorized all the key points from the syllabus (such as the 7 testing principles). But I also took my studying further, making sure I understood the concepts so I could answer the K3 and K4 (apply and analyze) questions.

Headed into the test, I felt quite confident that I was going to ace it.

Be sure check out the second part of Lucas’ story at the uTest Blog.

————————————————————————————————-

his is the second part of tester and uTest Enterprise Test Team Lead Lucas Dargis’ journey on becoming ISTQB-certified. Be sure to check out Part One from
yesterday.

The test

After about 3 minutes, I realized just how ridiculous the test was. Some of the questions were so obvious it was insulting, some were so irrelevant they were infuriating, and others were so ambiguous all you could do was guess.

Interestingly, testers with experience in context-driven testing will actually be at a disadvantage on this test. When you understand that the context of a question influences the answer, you realize that many of the questions couldn’t possibly have only one correct answer, because no context was specified.

You are allotted 60 minutes to complete the test, but I was done and out of the building in 27 minutes. That I finished quickly wasn’t because I knew all the answers — it was rather the exact opposite. Most of the questions were so silly, that all I could do was select answers randomly. Here are two examples:

“Who should lead a walkthrough review?” – Really? I was expected to memorize all the participants of all the different types of meetings, most of which I’ve never seen any team actually utilize?

“Test cases are designed during which testing phase?” – Umm…new tests and test cases should be identified and designed at all phases of the project as things change and your understanding develops.

According to the syllabus, there are “right” answers to all the questions, but most thinking testers, those not bound by the rigidness of “best practices,” will struggle because you know there is no right answer.

Despite guessing on many questions, I ended up passing the exam, but that really wasn’t a surprise. The test only requires a 65% to pass, so  a person could probably pass with minimal preparation, simply making educated guesses. I left the test in a pretty grumpy mood.

 

The aftermath

For the next few days, I was annoyed. I felt like I had completely wasted my time. But then I started thinking about why I took the test in the first place, and what that certification really meant. As a tester striving to become an expert, I wanted to know for myself what certifications were about. Well — now I have first-hand experience with the process. I’m able to talk about certifications more intelligently because my opinions and views about them are my own, not borrowed from others.

Former tennis great Arthur Ashe once said, “Success is a journey, not a destination. The doing is often more important than the outcome.” I think this sums up certifications well. For me, there was no value in the destination (passing the exam). I’m not proud of it, and I don’t think it adds to or detracts from my value as a tester. However, I felt there was value in the journey.

Through my studying, I actually did learn a thing our two about testing. I was able to build some structure around the basic testing concepts. I learned some new testing terms that I have used to help explain concepts such as tester independence. Studying gave me practice analyzing and questioning the “instructional” writing of others (some of which I found inaccurate, misleading or simply worthless). The whole process gave me insight into what is being taught, which helps me better understand why some testers and test managers believe and behave the way they do.

But more importantly, I became aware of the way I formulate opinions and of how susceptible I am to the teachings of confident and powerful people.

The lessons I learned from testing leaders early in my career freed me from the constraints of the traditional ways of thinking about testing, but in return, I took on the binds associated with more modern testing thinking. Ultimately, I came to a conclusion similar to that of many wise testers before me, but I did so on my terms, in a way that I’m satisfied with.

One day, I hope to have a conversation with some of the more boisterous certification opponents and say, “I decided to get certified, in part, because you were so adamantly against it. I don’t do it out of defiance, but rather out of a quest for deeper understanding.”

If you made it this far, I thank you for sharing this journey with me. Make a mention that you finished the story in the Comments below, and I’ll send you a pony.

A Tester’s Haiku

From time to time uTest puts on fun contests for the community. This month the objective was to come up with the best testing-related haiku. Over 90 testers participated, coming up with some great poems ranging from serious to silly to clever.

There was one haiku that got more attention than most so I felt it warranted some further discussion. It was one of the first submissions and it was well-written so the uTest CM team used it to promote the contest. It was mentioned it on the forums and posted it on Twitter. It was nominated as one of the 10 finalists and went on to win the contest, earning the vote of 21 other testers. Here is the poem in question:

Gifted are testers
Fixing a world of errors
Coded by others

It follows haiku syllable structure and has a nice flow, but I feel it’s misleading and potentially damaging. I’ll quickly address each line.

Gifted are testers
Can’t argue with that 🙂

Fixing a world of errors
This shouldn’t be a  great revelation, but in general, testers do not fix errors; We provide information and dispel misconceptions. One of the way’s we do this is by identifying errors. Some might try to make an argument that part of resolving a problem is finding it, but testers who understand what we do to provide value, realize the importance of making the distinction between finding an fixing a bug. These are two different actions that required two different skillsets.

Coded by others
This line really bothers me because it promotes an us vs. them mentality. Even though someone else (the developer) did write the code, it doesn’t help to point the finger at them. It’s a testers job to identify mistakes in other people’s work and that puts us in a delicate situation. It needs to be handled without judgment or condemnation. Bugs are an inevitable part of software development and since quality is the responsibility of the entire team, we need to work together, take responsibility together and avoid blaming each other.

Now, I’m not trying to say the author of this haiku meant to say that testers literally write the code to fix bugs or that developers and testers are enemies and I don’t mean to pick on him/her, but the fact that so many other testers thought this haiku was a good representation of testing troubled me. I’m sure this can be partially attributed to uTest’s endorsement and also because of language issues, but these are two themes that I see often and wanted to briefly address them.

My Entry
In case you were wondering, I did write a haiku. While I was a finalist, I didn’t make it into the top 3. Here’s my entry:

found and reported
a customer enlightened
value provided

Webinar – Should testers report every bug they find?

In December of 2012, Ryan Lamontagne and I got into a good discussion on the uTest forms about whether testers should report every bug they find. We decided to kick it up a notch and debate it live in a webinar!

http://forums.utest.com/viewtopic.php?f=13&t=4430

Checking vs. Testing – The Problem with Requirement Documents

The prevalent idea that testers are dependent on a requirements document to do their job is a dangerous one. Requirements are not always needed to test. In fact, in many situations, they may actually reduce a tester’s effectiveness.

The process of deriving tests directly from the requirements has several names. The ISTQB uses the term “specification-based testing”, sometimes it’s referred to as “Happy Path” testing, but I think the most appropriate name is “checking”. Michael Bolton wrote a well-known post about this topic (http://www.developsense.com/blog/2009/08/testing-vs-checking/). Checking is confirming that what we believe is actually true. Products are built in accordance with the requirements, so the requirements are what we believe to be true. When we verify that our product meets the requirements, we are “checking” the product. When a tester relies on a requirement document to test, he isn’t testing, he’s checking.

When we test, we are exploring, investigating and learning. Our actions are influenced by new questions and ideas that haven’t yet been explored. The use of requirement documents while testing can cause problems because it can give a false sense of test completeness, it can steer testers in the wrong direction, and it can reduce the independent thinking of the tester.

Gives a false sense of test completeness

If we have verified that our product meets all of the requirements, does that mean that the product has been well tested? True, you have verified that the product behaves the way we expect it to (in specific situations) but you still don’t know how the product will behave in situations not specified in the requirements.

“That wasn’t in the requirements” I’ve heard testers use this excuse many times and it drives me crazy. As a tester it is your job to investigate the product to learn about areas and behaviors outside of the requirements. A product is much more than its conformance to the requirements. It’s up to you to cover that gap between what is expected of a product and what actually is.

Checking that a product meets the requirements is necessary of course, but checking alone does not indicate test completeness.

Steers testers in the wrong direction

When you first start testing a new product or feature, what should be the first thing you test? Some might say you should verify the requirements. I challenge that view. I think the requirements should be one of the last things you test. In my opinion, a developer who writes code that didn’t meet the requirements failed to do his job. Before the test team sees the product, the developer has already spent hours working and verifying that his work is correct. Although possible, a strong developer rarely produces work that doesn’t meet the requirements. With that in mind, there is little value in retesting his work, especially when you consider the other aspects of the product that haven’t been tested yet.

Requirement documents can stifle the creativity of exploratory testing. When testers have a requirements document in front of them, they may be more likely to verify the requirements first and focus on areas where the likelihood of learning new information is the lowest. Instead, they should focus their efforts on new tests and unexplored areas where the opportunity for learning is the highest. When testing without requirements, you eliminate its influence on your testing decisions; you have to rely on your own abilities, your knowledge, and your curiosity. You test.

All testers have heard the old saying “Trust but verify”. I’m not saying that we shouldn’t verify developer’s work, only that there’s more value in performing a test for the first time, then performing the same test multiple times. Focus on the activities that produce the most value first.

Reduces independence

The idea of “independence” (See ISTQB Foundation) refers to how close a person is to a product. A developer who wrote the code would have the least amount of independence, while a person in a different company who has never seen the product would have the most independence. Independence can often be a great quality for testers. Testers with no preconceived notions of how the product is supposed to work are able to view the product with more objectivity.

Consider the common situation where a product was built according to incorrect requirements. The tester was able to verify that the product met the requirements, so was there an issue? In this case the requirements served as a false crutch to the tester. Just because the product met the requirements doesn’t mean it was working correctly. A tester with no knowledge of the requirements would have been better positioned to identify any errors because he wouldn’t have been comparing it to an incorrect “truth”.

We have now seen some reasons why testers should avoid relying on requirement documents. While they may be a necessity for different “checking” activities, testers who wish to provide value thorough “testing” must understand that their value is best realized when they test without requirements.

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.

Testing buzz words that annoy me

Maybe I’m just too sensitive (I have been watching a lot of romantic comedies lately), but there are certain “testing” words that really bother me. Either they are way overused or they are used incorrectly or whatever. I just felt I needed to vent :)

So, here are my top 5 testing words (phrases) that annoy the heck out of me:

It depends -When does it ever NOT depend? how is this helpful? Would you just take a stance for crying out loud?

QA -This is used way to often and it is usually used incorrectly. QA stands for Quality Assurance. Quality Assurance is process oriented and focuses on defect prevention. It is a term typically used in manufacturing. We are in the defect identification and information providing business. We are not QA people, we don’t do QA. We are testers, we test!

Sapient – Yeah, I get it. You used a smart sounding word to describe testing activities so that testers sound smart. Good one. Go away….

Heuristics – I’m still recovering from how impressed I was by sapient.

Craft – I really don’t know why this one bothers me so much but I absolutely CRINGE anytime I read or hear it. Nails on a chalkboard for me.

So, what testing buzz words annoy you?

Disclaimer:
This is intended to be a fun rant. If you use these words and I’ve offended you, my reaction would depend on several factors. Maybe you should QA this post relying on your sapient abilities. Following a heuristic, take the opportunity to hone your craft. AHHHHGGGG!!!

Reporting High-Value Bugs – Part 1

I originally posted this on the uTest Forum.

Why Even Bother?

It’s no secret that a strategy to make a lot of money at uTest is to start testing the second a cycle opens, log as many bugs as fast as you can, then hope that some of them will be approved. There is little or no regard for quality or value for the customer. The cycle is viewed as a competition and it’s every tester for him or herself. You can make some good money with that strategy.

If you are a tester who uses the strategy above, and sadly I’ve seen many testers who are, this series probably won’t appeal to you. But if you are a tester who takes pride in your work and wants what is best for the customer, uTest and yourself, then you should stick around because we are going to explore some fun ideas.

Disclaimer:
Please understand that I’m not attacking new testers or testers who have a limited skillset. I’m trying to show that there is pride an honor in what we do and there can be substantial benefits to those who understand that.

In Part 1 of this series, we are going to discuss WHY testers should strive to report high-value bugs. In Part 2 we’ll talk about HOW. When I say “high-value” I’m talking about bugs that the customer approves as Very or Exceptionally valuable. I have three points to make so let’s get to it!

1. Align with uTest’s values

uTest consistently stresses the importance of quality over quantity and how we need to always consider our customers. Recently, uTest has done their part to promote this in two ways.

Rating Impact
uTest restructured the rating algorithm to make the quality of bugs have a much higher impact than the quantity of bugs. If you are interested in your rating at all, this is now the single most important factor. One high-value bug will easily offset a few rejections.

That means stop disputing low-value rejected GUI bugs. You are better off accepting a valid rejection and learning from it then you are disputing, “winning”, and not learning. It’s a hard thing to do, but I force myself to accept valid rejections even if I think I could get it approved. That sting helps me remember my mistake so I won’t make it again.

Increased Payouts
Perhaps an even more impactful change was the drastic payout increases for Very and Exceptionally valuable bugs. 1 high-value bug can sometimes pay 5 times more than a low-value bug.

uTest is constantly adjusting the system to ensure customers are getting the value they need, testers are fairly compensated, and primitive “testing” is discouraged. As uTest evolves, you will see more recognition, influence and money shifted towards the strong testers. It’s in your best interest to learn how to test professionally now. Learn to test for the customer, not yourself, and you will find that you are amply rewarded.

2. Receive more cycle invites

Occasionally, new testers message me asking how to get more projects or how to succeed at uTest. I give them some unusual advise. I tell them to ignore low-value bugs; don’t even bother reporting them. This is a very strange idea that receives some interesting responses. “But then I won’t get my five dollars!”. Yes that’s true, but that’s only half the story.

The best way to get invited to test cycles is for the PMs to know that you are a strong tester.
Think of the customer. They are most happy when they receive high-value bugs. PMs remember (and invite) testers who make their customers happy. There are over 70,000 uTesters. Why would they remember you if you report the same low-value bugs that everyone else reports?

A while back I worked the first cycle for new customer. There were 155 bugs reported. I only reported 8, but 7 of them were approve as high-value. 6 months later I received a note from the PM. The customer had another cycle starting and they specifically asked for me to be added to it. WOW! After 6 months they remembered me!

It might sound like I’m bragging here, but that’s not the point. The point is, if you only report high-value bugs, you stand out from the crowd in a big way. As a TTL I often point out these testers to my PMs so we can be sure to invite them to future cycles.

3. Become a better tester

This should be pretty obvious but maybe it’s not. If you report spelling errors all day you will become great at finding spelling errors, but you probably won’t become a good tester. If you spend your time practicing being a good tester, you might wake up one day and find out you actually ARE a good tester. I realize this is a simple concept, but so many people just completely miss it.

So that wraps up Part 1. In Part 2 we’ll look at HOW we can find and report these high-value bugs”. I encourage you to take these ideas to heart and think about your motivation here at uTest. Please feel free to ask questions or challenge these points. Like any other advice you receive, always question it and make a decision for yourself.

See you in Part 2!

STPCon Fall 2012 – My Review

I recently was able to attend STPCon in Miami. It was my first conference and I really enjoyed it. Here are some of my highlights.

People I met

I finally got to meet a few members of the uTest staff. Jessica, Matt, Mike, and Chris were all there slinging swag and preaching the uTest gospel. It was nice to get some face time with those folks. Unfortunately we didn’t have a uTest meet up. Maybe next time.

I did get to meet a former uTester, Joseph Ours. I talked with him for a while about his experiences with uTest and how he has made the transition into management and consulting. Joe is a knowledgeable and well-spoken guy. I really enjoyed getting to know him. Too bad he’s not an active uTester anymore, I would love the chance to work with him.

Hands-on vs. Lecture format

There was a track of 7 classes that focused on hands-on practicals. It seemed like a cool idea to me, so I spent the first 3 sessions in hands-on classes. While they were interesting and it was fun to test with other testers, I didn’t really learn anything. It was more like “Here’s a program, lets think of ways to test it”. I do that every day when I test with uTest. I wasn’t there to test, I was there to learn how to become a better tester.

While I can see the value of the hands-on classes for people who don’t have the luxury of contently testing new things with new people, for me it wasn’t the best use of my limited and expensive time. (I was there on my own dime)

After I realized that, I switched over to the lecture/discussion sessions and really found a lot of value there. Most of those sessions weren’t lectures but more of someone sharing their experience or suggesting ideas on how to do things better. The dialog between the presenters and the audience was also great. There was lots of idea sharing and discussions.

Favorite Sessions

Mike Lyles of Lowes gave a two part talk about how Lowes created a Test Center of Excellence (TCoE). It was extremely useful for me to see what a mature testing organization looks like and how it functions. It helped me start to develop my long term vision for my testing organization.

I also enjoyed Joseph Ours’s talk about “Redefining the purpose of software testing”. Simply put, he was making the argument that testing teams should be looked at as information providers, not gate keepers or decision makers. I have been making this argument for a while now but had been looking at it the wrong way. I thought it just was the definition of what testers should do. His explanation showed me that it actually can be an effective way to explain the value that testing provides. Testing is a service. We provide information to make informed decisions.

One lady in the audience challenged Joe saying that she is the test lead as well as the gate keeper and that in her organization it works fine. Joe and her debated a bit but she wasn’t convinced. After the presentation Joe and I chatted about that point more and realized that we need to think of roles and people separately. A testers role is to discover and provide information. A decision makers role is to make decisions based, in part, on that information. Usually those role are divided between two different people (or groups of people) but in some cases, it may be the same person.

In her case, she led the testing team, but she also had additional business knowledge and the authority necessary to be able to decide when the product was fit for delivery.

Not so great

The Vendor showcase was disappointing. There were only 10 or so booths. I talked to most of them in under an hour and spent the rest of the time trolling around the uTest booth sharing my uTest testimony with anyone who would listen 🙂

Overall

I’m glad I was able to make it down to STPCon. I got to meet some great people, learn a few things, and get a better understanding of our industry in general. It was a valuable experience and am looking forward to attending next year. Maybe I’ll see you there.

uTest – My First 100 Cycles

So I’m a little late, I’m actually at 138 cycles, but I wanted to give an update on my uTest experience now that I’ve got 100 cycles under my belt.

Accomplishments

When I first signed up with uTest I set a few goals. I really had no idea how realistic they were, but you have to at least have something to shoot for right?

By the end of 2012 (9 months from when I started) I wanted to:

  1. Earn my gold badge in Functional testing
  2. Become a TTL (Test Team Lead)
  3. Develop a strong reputation within the uTest community

Gold badge

I got my functional badge within 30 days of my first test cycle. At first this was actually a disappointment. I was really looking forward to the challenge of having to work hard for that badge.

After the initial shock wore off I decided that it actually was an accomplishment to be proud of. I realized that uTest has created an efficient system that allows strong testers to bubble up to the top quickly which makes sense when you think about it. Why would they want to hold good testers back? You want your best testers out front setting an example and representing the company.

TTL

Three months in, I got the email I had been anxiously waiting for; I had been invited to be a TTL! A rite of passage to become a TTL is you have to manage a sandbox class. Working that cycle was the most difficult thing I’ve done at uTest so far. Working with and evaluating 100 rookie testers, triaging their 400+ bugs and test cases in just a week is grueling to say the least. But the sense of accomplishment at the end made it all worth it. Since then, it’s been a fantastic experience working closely with the PMs while helping guide the testers so they can develop and become successful.

Reputation

My approach to this goal was to focus on the uTest form. The forum is an amazing community full of talented testers from all over the world. Every day there is are several interesting conversations going on. We constantly learn new things while challenging and encouraging each other.

After a few months of active participation, I was asked to become a uMentor and a forum moderator. Basically my role is to spark discussions and debates as well as write educational “mentoring” posts.

Before I started working at uTest maybe 10 other people knew I was a tester (That includes my mother). Now literally hundreds of people read my posts and engage in awesome discussions with me every week. So far, the conversations I’ve started have generated over 13,000 views.

I’m not sure I’ve fully achieved this goal yet, but I’m on my way.

Testing Statistics

To quantify my time at uTest so far and to brag a little 🙂 here are my digits:

  • Products Tested: 70
  • Test Cycles: 138
  • Bugs Filed: 342
  • Bug Acceptance: 93.2%
  • High Value Bugs: 47%
  • Functional Rating: 99.3% – 99.7%

You can see my uTest profile here: https://my.utest.com/platform/profile/LucasDargis

uTest Perception

Without a doubt, joining uTest has been the biggest factor in the development of my career. I have grown more in the last 7 months then I ever expected. I was able to achieve all my goals and then some.

Here is a short list of the amazing opportunities uTest provides testers:

  • The opportunity to work for every type of company. You are able to see how testing is done from start-ups to big Fortune 100 companies. Every cycle adds to your experience and helps open your mind to the many different ways testing is approached.
  • The opportunity to work with and learn from people from all over the world. I’ve made friends in the UK, India, Romania, Brazil, etc. The global exposure is priceless.
  • The uTest forum is relatively new and the number of active contributors is still small, but since the uTest community is so large (60,000+ testers) the potential is huge.  There is an excellent opportunity for testers to get in on the ground floor and quickly establish themselves in a community that is evolving into an industry leader.
  • There are several leadership opportunities. You can become a TTL, a forum moderator, a uMentor, and a Gold-rated tester. Being active in discussions on the form or in your test cycle (providing help, answering questions) are informal ways to develop your leadership skills.

You may have noticed that I haven’t talked about money at all. That is because for me, getting paid at uTest is an extra bonus. I can always make money, but it’s these other aspects that provide the most value to me as a tester.

100 cycles down. Next stop, 1000 bugs!