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!
Tag: Testing
Webinar – Three more uTest Panel webinars
It’s been a busy past few weeks. In addition to picking up two new enterprise customer accounts (uTest TTL work) I was a panelist for three more uTest webinars.
Maximizing Your Benefit From The uTest Forums
http://forums.utest.com/viewtopic.php?f=55&t=4985
Maximizing Exploratory Testing Methods
http://forums.utest.com/viewtopic.php?f=55&t=4984
How to be a Quiet Tester That Customers Shout About
http://forums.utest.com/viewtopic.php?f=55&t=4986
Testing with the Microsoft Surface RT
About the Device
The Microsoft Surface RT is a interesting device to test with. It has the new Windows 8 interface, but it also still has the traditional desktop interface because not all things can be accomplished on the Windows 8 side. This can make things a little confusing, especially if you are just starting to test with this device. So, here are some instructions to help you get ready to set up and back to testing in no time.
Installing Apps
When we are testing apps that are in development, they are not available in the Windows Store so we will need to manually install them. Usually, you will be given a zip file that contains all the files you need.
- Download the zip file
- Go to your Desktop and locate the zip file (Should be in your Downloads folder)
- You can’t install directly from a zip file so you need to extract the files
- Long tap/release (or right-click if you have a mouse) to open the context menu
- Tap on ‘Extract All…”
- Select the location where you want the files saved to and tap ‘Extract’
- The extracted folder will open
- Locate the Windows Powershell Script (should have a Notepad icon)
- Long tap/release (or right-click if you have a mouse) to open the context menu
- Tap ‘Run with PowerShell’
- You’ll see a series of prompts, accept all of them
- If this is the first time you’ve installed an app, you’ll be required to sign up for a development license. It’s free and it has just a few simple steps
- After the application is installed, the PowerShell windows will just close. There is no indication that it was installed, but when you go back to your home screen, you should see the app on the far right
Uninstalling apps
- On the home screen, drag the app icon down just a bit until a check mark shows up just above the icon
- Release the app and the action menu will open from the bottom of the screen
- Tap ‘Uninstall’ to remove the app
Error logs
The Surface RT essentially is a PC, so application errors and crashes will be logged in the Event Viewer just as they are on a regular Windows desktop or lap top.
How you access the Event Viewer on the Surface RT is more complicated than on a regular PC since there is no Start button or search function. Here is how you can add a link to the Event Viewer to your desktop:
- From the Home screen, tap on ‘Desktop’
- Long tap/release (or right-click if you have a mouse) to open the context menu
- Select Personalize
- In the ‘Search Control Panel’, search for Event Viewer
- Tap on Administrative Tools(or Navigate to Control Panel > System And Security > Administrative Tools)
- Long tap/release (or right-click if you have a mouse) on Event Viewer to open the context menu
- Tap Send To > Desktop (create Shortcut)
Now that you have the event viewer open, you can view error messages and save the error files to attach to your bug reports.
- On the left pane, tap on Windows Logs >> Application
- On the right pane, tap on ‘Filter Current Log…’
- Select ‘Error’ and tap ‘OK’
- Select the error log(s) you want and on the right pane, tap ‘Save Selected Events’
- Save the events wherever you like and you can attach them to your bug reports
Taking Screenshots
Screenshots are pretty easy to take. You need to press the home button (Windows icon on the front of the Surface) and the down volume button (left side of the Surface) at the same time.
The file will be stored in your Photos > Pictures library > Screenshots folder
Taking Video
A well-created external video is usually the best way to go as I’ve done in all the above videos. Check out this post for some tips to improve your external videos.
I haven’t found a way to create mirrored videos yet, but I’ll update this if I do.
Webinar – Finding bugs in mobile devices
I was able to join Kayla Cox and Todd Smith for a uTest webinar to talk about testing mobile devices and how to find high-value bugs.
Since my microphone was terrible (and I might have been mumbling a little ) here is a summary of the points I made in our discussion.
Crashes
Understand that not all crashes are valuable.
Out of memory crash may be due to other apps using up 90% of your memory and the app you are testing just pushed you over the limit. The best way to know for sure, is to have a clean test bed. Restart your phone after you install a new app, and make sure no other apps are running in the background.
When you do get a memory related crash, use a memory management app to help you see where your memory usage spikes. Being able to identify a reproducible memory crash is usually a high-value bug
Connection Issues
- Kill your connection while data is being transferred
- Unplug your wi-fi router/modem
- Turn on airplane mode
- Turn of wi-fi on your device
- Turn off cellular data on your device
- Find places near you that have low or no signal and test there
Interaction with native and popular apps
- Share something via email with no email set up
- Log in using Facebook account with/without the Facebook app installed
- Interrupt testing with phone calls, text messages, FaceTime calls etc
- If the app changes the phone settings, make sure it does it correctly. Change it back manually in settings and see how the app responds
Investigation and Documentation
There are many topics on how to write good bug reports but there are a few points worth reiterating
- Provide exact reproduction steps
- Do root cause analysis – don’t report symptoms. I once saw 3 testers reported 3 different symptoms of the same bug. On the surface they all looked like different bugs, but a little analysis showed they were all caused by the same step they all overlooked.
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.
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.
I’m uTest’s 2012 Mentor of the Year!
For the past 3 years, uTest recognizes uTesters who have consistently gone above and beyond their call of duty. uTest recently announced their selections for the 2012 testers of the year and I was selected as the 2012 Mentor of the Year!
Wow! What a thrill!
As I’ve mentioned many times, uTest provides us testers with many opportunities to grow and develop our testing skills. We are constantly exposed to new products, devices, and customers. The uTest forum always keeps us up to date on the latest testing trends and hot debate topics. But uTest offers us more than opportunities to learn; uTest also provides a platform for us to teach and mentor.
My greatest thrill comes when uTesters comment on how one of my posts helped or inspired them. It’s the motivation behind everything I write. It’s a privilege to be able to influence new uTesers as they evolve into highly-skilled and respected testers.
uTest has assembled a community of testers ready to learn, but that need must be met by those willing to teach. Every tester has knowledge they’ve gained through study and experience. No matter how simple it may seem, that information is valuable. If you’re brave enough to share what you have learned, you’ll experience the amazing feeling of knowing you are positively impacting your community and industry.
I am truly honored to receive this award and I want to extend my sincere thanks to the uTest team and the uTester community.
If you care to read any of my “uMentor” posts, they are all located here.
5 Ways to Improve Your Bug Titles
I originally posted on the uTest forum here.
Bug titles are one of the most important pieces of you bug report. They are the face of your bug, they show the its value and can help or hurt the overall efficiency of the test cycle. Far too often testers don’t give their bug titles the attention they deserve. This post will try to change that. Here are 5 tips to help you improve the titles of your bug reports.
Consider Your Audience
Like the bug report itself, the title is intended to convey information. The main difference is the title is more concise. A well written title will quickly and clearly summarize the bug and its value.
To communicate this information effectively, you need to consider your audience. Bug titles are read by different audiences who may use the title for different reasons. Testers have the difficult job of writing a title that satisfies the needs of two different audiences at the same time: The customer and your fellow testers.
Customer
When the customer or Test Team Lead (TTL) reviews the bug list, one of the first things they do is look at the title. As we talked about in Reporting High-Value Bugs – Part 2, part of reporting high-value bugs is “selling” it to the customer. The title of your bug is part of your sales pitch. Always keep the title short and to the point. You want to focus on the end result, not the actions. For example:
Use “User profile – Unable to link to Facebook” instead of “Clicking the ‘Link to Facebook’ button doesn’t do anything”
Also use words that action words that convey importance such as ‘prevented’, ‘does not’, ‘inconsistent’, ‘unexpected’ etc.
Fellow Testers
Your fellow testers use the title of your bug in a very different way. They use it to determine if the bug they found has already been reported. To help them, you need to include the key words they will be searching for.
Hopefully, before you report your bug, you search the bug list see if it has already been reported. Make a note of what you searched for because those are the words you should consider including in your title.
In Reporting High-Value Bugs – Part 2 we also talked about reporting the root cause of the bug. The same is true for the title. Your title should describe the underlying problem, not one of its many possible symptoms.
Follow the uTest Standard
uTest has a crash course dedicated to Bug Title standardization so I’m going to point you there first: http://help.utest.com/testers/crash-courses/general/bug-title-standardization
To summarize that post, every bug should be broken apart into two distinct parts. The “Area” and the “Description” The area is the place in the application where the bug occurs. The description is a brief summary of the bug. These two areas should be separated by a hyphen.
For example, in this bug title:
Homepage – The ‘Contact Us’ button is linking to the incorrect page
“Homepage” is the area and “The ‘Contact Us’ button is linking to the incorrect page” is the description
This can get a little tricky when the area is deep in the application. If there was a bug in the uTest platform on the payments screen in the Account & Settings section how should we identify that area?
In the link above, one of the authors suggests you write it like this:
Account & Settings – Payments – Total payout amount is incorrect
Personally I don’t like this suggestion. Testers who do this tend to put the navigation steps in the bug titles. That is not the place for that information. Plus having more than two sections makes the title difficult to read.
I prefer to list only the broad area of the application and include the more specific area in the description. Here is how I would write this title:
Account & Settings – The total payout amount on the Payments page is incorrect
Do Not Specify the Test Environment
Many testers include the device or environment they use to test in the title of their bugs:
[iPhone 5] User profile – Unable to link to Facebook
The landscape that we test against these days is so large that it’s no wonder that this has become more common recently. Testers feel that the device they found the bug on is an important piece of information. While that is true, the title of the bug is not the right place for it.
The main reason that this is a bad practice is because it gives false impression about the scope of the bug. Generally when testers start their bug title with the environment, they are simply stating the device that they found the bug in. But the customer may interpret that to mean that this bug is only present on that device listed in the title.
Unless you have tested against every other possible device/environment, don’t include this information in the title. It adds little value and can actually cause problems.
As with most rules, there are exceptions. Here are two:
Explicitly required
If the cycle specifically tells you to include environment information in your bug titles, you should follow the instructions.
For example, this is directly from a test cycle I recently was on
NOTE – If you find an iPad bug: Please add [iPad – iOS xx] at the beginning of you bug title.
In this situation it is perfectly fine (and even required) that you include the environment in your title.
However, you may see something like this in the instructions:
BUG TEMPLATE: Please include the following info in all your bugs: Mobile device model and OS version Description of bug Wi-Fi or 3G / 4G?
This does not mean that all this information should be in the title. It simply means that it should be specified in the body of the bug. Generally you should put this information in the ‘Specified Environments’ or ‘Additional Environment info’ fields. It is the “Bug” template, not the “Bug Title” template.
Environment specific bugs are allowed
Occasionally a cycle will allow the same bug to be reported for different environments. In this case, each one of these bugs is considered different by the customer. Since the only difference between the bugs is the environment, it is necessary to include the environment in the title. Otherwise you would have multiple bugs with the exact same title and your fellow testers would have to look at the contents of the bug to see which environments had already been reported.
Keep Consistent with Earlier Bugs
Sometimes a cycle will ask you to include some extra piece of information in the title. One example of this would be the build of the application that you tested. What I usually see happen in these situations is every tester comes up with their own way of including this information. The result is a messy bug list that looks something like this:
[b 123] Area – Description
build 123 => Area – Description
Area – Description {build 123 v.2.045.34}
123 Area – Description
This is difficult for the customer and TTL to read and makes it impossible for them to quickly scan through the list.
Assuming that the earlier bugs followed the uTest standard and everything we addressed above, you should follow the pattern established in the first few bugs. Don’t worry about being original or sticking to your own personal preference, the goal is consistency. This will make the customer’s and TTL’s jobs much easier. See how much easier this is to read?
[b 123] Area – Description
[b 123] Area – Description
[b 123] Area – Description
[b 123] Area – Description
Learn From Other Testers
You can learn quite a lot from reviewing the bug reports of your fellow testers. You can see different styles of reporting the reproduction steps, come up with new ideas of how to test, and see which types of devices are the most common.
The same can be said for the bug’s title. When you are reviewing bugs, don’t just skip over the title. Instead, take advantage of the opportunity to learn from the mistakes and successes of others.
First evaluate the title of the bug first on its own:
Does the title follow the standard? Does it include appropriate key words?
Then look at it in the context of the entire report:
Does the title accurately and efficiently summarize the bug? Does it “sell” the importance of the bug?
As you pay more attention to your own bug titles as well as the titles of other bugs, you will start to see the types of patterns we have just talked about. It will become apparent that the testers who do these types of things are the ones that are separated from the crowd. Bug titles are extremely important and should be treated that way. Keep these tips in mind and you will be one step closer to writing the perfect bug report.
I’d love to hear your thoughts on this topic. What other tips can you give your fellow testers?
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.
Reporting High-Value Bugs – Part 2
I originally posted on the uTest Forum.
In Part 1 of this series, we talked about the reasons why a uTester should focus on reporting high-value bugs. That led to some fantastic discussion and a spin-off thread about reporting every bug you find. Before you continue, you should go back and review those threads to get caught up on the topic.
In this Part 2, we are going to look at “HOW” you can find and report high-value bugs. This is a popular topic at uTest and there are many threads, webinars, and crash courses available (There are links to some of that material below). This post is intended to complement those resources and help us continue to improve our testing skills.
I’ve teamed up with fellow TTL and uMentor, Allyson Burk for a double dose of testing goodness 
We have some great ideas for you, so let’s get started!
Finding high-value Bugs
Focus on One cycle at a time (Allyson Burk)
I find there are two approaches to the workload at uTest: 1) accept every cycle, file a few bugs on each or 2) accept fewer cycles, file more bugs per cycle. Personally, I find the latter to be the best way to make more money, have more satisfaction in my work and increase my tester rating. Why? Because I can increase the quality of my work using this approach.
Giving myself more time on a product allows me to be methodical. I might use a few different approaches depending on the type of product.
– Deep, power user scenarios. I develop a goal in mind. A recent cycle I was on had a great example of this – you are a soccer mom and you need to equip your child for the upcoming season. This is going to yield the issues that are going to affect the target audience of the client. This approach can definitely yield high value bugs because you will be able to tell the client what is going to drive those target customers away.
– Break down the app into areas and dig deep. This is the approach I use when it is a newer, more unfamiliar application. I might spend a few hours in settings making sure each setting combination is functioning properly; or trying a variety of shopping cart, wishlist, checkout scenarios; or product customization. The key is not just spot checking to see if the area is functioning, but to really stretch the code and make sure all variables have been covered.
– Going down the rabbit hole. This is a less precise, more intuitive path where I just start investigating the parts of the application that I find interesting and following them as far as I can take them. If I really love the app or find it to be fun to use, this is the approach I will take. You have to be careful with this approach because you can “waste” a lot of time.
The key to all of these approaches is TIME. You cannot test in this deep manner if you do not have time and you cannot have time if you have 5-15 active cycles clamoring for your attention.
(Note from Lucas)
When you accept a new cycle, you are expected to thoroughly read the scope and instructions, read through the known bug list, review any other attached documents, and catch up on any chat posts. Then you have to set up your testing environment. You have to install the app, create an account, configure your proxy, etc. These start-up activities can be quite time consuming. Keeping your active cycles low allows you to spend less time getting ready to test, and more time testing.
Know the status of a project (Allyson Burk)
In general, clients are going to value bugs differently depending on the point in the development cycle they are on. It is important to pay attention to clues about where the client is in development when searching for high value bugs. This can be a moving target depending on the methodology used, agile vs. waterfall for example, but I think for this conversation we can think in terms of early, middle and late in the development cycle.
– Early in the development cycle, you can imagine that content related bugs are not going to carry huge value. The look and feel may still be in development, the final copy is likely not completed and images may not have been delivered. The client is rather going to be more focused on core functionality. They need to make sure the major functionality is there and working properly.
– Midway through the development cycle, functionality is still going to be the focus, but content starts to be more important. If ever there was a time to value spelling/grammar bugs, this would be it. Most copy has to get locked down for legal/translation/marketing/etc. so the client may be looking to make sure this is completely clean before shipping it off for various approvals.
– Late in the development cycle, stability and polish are key. Everything needs to be functioning at this time and the application needs to have a minimum of crashing/blocking issues. Many times in this last stretch before release of a product, the client might only be interested in High or Critical issues. The code will be fairly locked down at this point. The client will often not want to risk fixes that might break other functionality, so they are really going to be interested only in bugs that are of such severity to make the app unusable.
As uTesters, I think the trickiest aspect of this is knowing what phase of the development cycle the client is on. Logic might dictate that if you are on the first cycle for a new client that they would be early in the development cycle. I’d actually venture a guess and say that is actually almost never the case given my experience. I’d say we are usually brought in after the code is pretty stable and the content is beginning to be finished… somewhere in the mid stages.
But how can we know with more certainty?
Sometimes, this is as easy as reading the overview and paying attention to context clues. The PM might explicitly state, this is the first testable build of this product (early) or this is the release candidate (late). There may be things excluded from the scope like images (early to mid). There may be a very long known issues list (mid to late) or no known issues at all (early or late – HA this is a tricky one! They may clear all known issues for the later builds in order to make sure there has been no code regression before shipping the product out).
In the end, we will have to rely on the information provided and forge ahead. There is also never any harm, if you feel that there is no clear focus provided, to ask the question: Is there anything in particular the client is wanting us to focus on at this time? You might be refreshed at what avenues of testing that will open up for you.
Writing High-Value Bug Reports
Report bugs, not symptoms (Lucas Dargis)
The other day I was the TTL of a cycle and one of the features in scope was an account creation screen. The user was required to enter several pieces of information including their Address. Two different testers report these two bugs:
Bug 1 – Address field allows “!!!!!!!!!!!!!!!!!”
Bug 2 – Address field allows “!@#$%^&*()_+”
I see this type of thing all the time, so I know some of you saying “What’s wrong with that?”. The problem is both of these testers reported different symptoms of the same bug. If they had taken some time to do further investigation into the Address field, they would have realized that they hadn’t found a specific input that made it past the validation. They would have learned that the real issue was the Address field wasn’t being validated at all. The user could have entered anything (or nothing) and the system would have accepted it.
Whenever I encounter a bug, I spend a significant amount of time testing all around it, trying different inputs and different sequences of events until I understand the root cause and all of its symptoms. This is where testers can show their worth. It’s easy to click on something and then report on the results, but it takes a much stronger skill set to be able to investigate potential bugs and then provide a valuable report of your findings. Customers can see this effort and they usually reward it.
Sell Your Bugs’s Prominence (Lucas Dargis)
If a bug is easy to find, it is usually more valuable then if it was an edge-case bug and it was unlikely that anyone would find it. Identifying your bug and reproduction steps is just the first step. The best testers know that how their bug report is written can affect how the customer views it’s prominence (how easy it is to find). The best testers keep their bug reports focused and their steps limited to the critical path. That means you should only list the specific actions needed to trigger the bug.
There is a problem with this approach. Often, bugs are hidden deep within the application and you might feel that you need to explain how you arrived at the bug. The way I get around this concern is to list “Prerequisite” steps at the top of the “Actions Performed” where I describe the starting state of the application.
Example:
Bug Title: Shopping Cart – Items added to the cart are not saved
Steps:
1. Go to the URL
2. Click on create new account
3. Enter a valid username
4. Enter and password
5. Click “Submit”
6. Log into the system with your account
7. Search for an item
8. Select the item
9. Add the item to my cart
10. View your shopping cart
The above report lists the steps from beginning to end, but it is fairly long and gives the impression that a user would have to do a series of very specific steps in order to find the bug. Instead, you should only list the steps that are directly related to the bug. Let’s see what that would look like.
Bug Title: Shopping Cart – Items added to the cart are not saved
Steps:
Starting state – User is logged into the application and viewing the details page for a product
1. Add the item to my cart
2. View the shopping cart
Explaining the starting state at the top of the report allows us to remove 8 steps. Now, because only the steps that specifically cause the bug are listed, this bug seems much more prominent and the report does a better job of highlighting the value of the bug. This is an oversimplified example but I hope you understand the point.
This is just one tip on how to sell your bug. This technique is called “Bug Advocacy” and is something ever tester should learn. To learn more about Bug Advocacy, here is a fantastic paper written by Cem Kaner:http://www.kaner.com/pdfs/bugadvoc.pdf
I want to thank Allyson for her contributions to this article. Please feel free to post questions, comments or challenges to anything we’ve written. Hopefully these ideas will prove useful to you in your quest for those high-value bugs.
Additional Resources
Be Creative: Bug-Hunting Tips from a Gold uTester (By Amit Kulkarni) – http://help.utest.com/testers/crash-cou … ld-uTester
How To Write the Perfect (uTest) Bug Report (by Rebecca Showerman and Nikki Sedgwick)- http://blog.utest.com/how-to-write-the- … t/2012/06/
How to Write a Good Bug Report (By Sunil Sidhwani) – http://forums.utest.com/viewtopic.php?f=55&t=3095
When a Bug is Not a Bug – Bugs vs Feedback (By Aaron Weintrob) – http://forums.utest.com/viewtopic.php?f=55&t=3179
Bug Reporting 101 (By Joseph Ours) – http://help.utest.com/testers/crash-cou … orting-101