A couple weeks ago, we rolled out v3.0.4 of our platform. And now, after a little extra time in the oven, we’ve launched another feature designed to make it quicker & easier to access your uTest account.

Social Sign-In
Let’s say you’re like millions of other people around the world and you have an account on Facebook, Twitter, or LinkedIn. And let’s also say you’re tired of keeping track of passwords, remembering to sign-in everyday to all the websites you like, and are yearning for something simpler. Starting today, we have a solution for you, at least when it comes to your uTest account (we can’t speak for anyone else). Now you can log in to the uTest platform using the credentials from your Facebook, Twitter or LinkedIn accounts.

Setting up this linkage is simple:

1. Get started by visiting our platform and clicking the button for your favorite social network(s).
2. Then sign in to your social network and confirm the connection.
3. And that’s pretty much it. The next time you visit the uTest platform, just click that same button and you’re in.

Enjoy!

If you’re in the market for a new mobile device (and these days, who isn’t?) one of the most important decisions you’ll have to make is whether to choose the physical keypad or the touchscreen.

As we learned from our most recent What Do uThink poll, most mobile users actually want both of them. In fact, 70% of respondents said they would prefer a device like the Motorola Droid or the Blackberry Torch, as opposed to the 20% who said they preferred the physical keypad only (e.g. Blackberry Curve, Blackberry Bold) and 10% for the virtual touchscreen (e.g. the iPad, iPhone, etc).

So, 70% of mobile users can”t be wrong, can they? Let’s take a look a few of the arguments (from the uTest Forums thread) in favor of each, then decide for yourself.

Physical Keypad
“I go with Physical keypad. The reason is I have experienced problems while using touchscreen keys. I love Physical keypad which allows me to type the message fast and call the number much quicker than a touchscreen. Also, my LG Android had gone for service because the touch screen was malfunctioning. For instance, when I pressed 3, it used to display 6.”

Hybrid
“I prefer a hybrid model as it gives me independence to use the phone as per my convenience. Also, it makes things much easier for me. If I have to chat or SMS I can use the keyboard feature, but if I have to punch in a phone number or username/password I can do it from touchscreen. Plus, different situations demand things differently so a hybrid model is a perfect one for me.”

Virtual Touchscreen:
Pros:

1. Does not take physical dimensions & weight, thus devices can be lighter & thiner, or can be larger with larger screens & additional physical buttons in return to that acclaimed space & weight.
2. Some physical keyboards can be used only on one orientation. Virtual keyboard will mostly work on both.
3. Easy keyboard layout navigation & usage – E.g. Input switch, Special chars (rather than hitting an Alt/Shift/Sym+Char), Smileys and other special inputs.
4. Languages support – As opposed to physical keyboard which can support 2 languages max, TouchScreen keyboards can support and unlimited amount of languages, so everyone can enjoy the languages keyboard of their choice.
5. Used device’s brightness setting thus can be visible at dimmed or low-light environments with no problems, as opposed to physical keyboards’ limited lighting.
6. Clarity & efficiency – Most touch keys use all sorts of key highlighting pressed button such as – Coloring, Magnify glass (e.g. iPhone), Vibration (E.g. Android)

So where you come down on this debate? Which type of device will you be leaning towards for your next purchase. In other words, What Do uThink? The comment section is all yours.

Pardon my American “gun-loving” nature while I start this blog post with an analogy about guns. Let’s say that I’m interested in learning how to shoot a gun, so I go visit my local shooting range for instruction. The people who run the shooting range (which is fully licensed and very reputable) give me extensive safety training before finally issuing me a gun with some ammunition. While standing in front of the target, I carefully load the gun, point the barrel at my foot, and pull the trigger.

So whose fault is it that I just shot myself in the foot? Is it the shooting range’s for not issuing me special bullet proof boots or for not training me even more thoroughly about the dangers of shooting my extremities? Or is it mine, for shooting myself in the foot?

A recent Windows “bug” has put Microsoft in the position of the shooting range. I put “bug” in quotes because it’s hardly the shooting range’s fault that I shot myself in the foot, but it’s still their problem in the end. Same with Microsoft who must now deal with an annoying flaw in their DLL loading behavior that isn’t their fault but has become their problem. Ars Technica explains the problem very well, but here’s a quick summary of the issue:

For the uninitiated, Windows applications may have their functionality spread across dozens or even hundreds of files called DLLs. When you tell your application to perform a task, the instructions for performing that task might be contained in a DLL file somewhere with the application or even as part of Windows itself.

Now there are two places an application can look for a DLL file. The first place is simple – wherever the developer explicitly says to look. That’s the way Microsoft says to do things (and has for 12 years), and it’s the safest approach to use. But Windows supports another approach which is to look for the DLL file wherever the application happens to be looking for other files. In other words, if your application is an MP3 player, and it’s loading an MP3 file from your media directory, then it can also look for necessary DLL files in that same directory.

This is legacy Windows behavior – a lot of old applications expect Windows to work this way. But it’s also incredibly dangerous. All I need to do to break your application is to put a hacked DLL file in the same location as another file I want to open. Microsoft realized this was a problem a long time ago, so way back when they released Windows XP SP1, they made it possible for a developer to turn off this behavior entirely within their software. So it was a huge surprise when security researchers recently announced that 40 different applications (including iTunes for Windows) were still vulnerable to DLL loading bugs because the app developers forgot to do disable the legacy DLL loading behavior.

This puts Microsoft in a bind. On one hand, they have to support a legacy behavior for older applications that a few people still use. On the other hand, developers are still writing buggy code that doesn’t take advantage of the security features that Microsoft has offered for years. This issue is plainly the fault of the developers, but in the end it has become Microsoft’s problem.

So what’s the solution? Microsoft has released a hotfix that lets you turn off the DLL loading behavior entirely, but you should be careful using this as it may break some poorly written applications. Then again, anything that doesn’t work after you install this is broken anyway, right?

In the long term, what should Microsoft do? They’ve long maintained a strategy of maximizing backwards compatibility, but sometimes it backfires with problems like this. Should developers be responsible for writing their code securely, just like they should avoid other bugs such as buffer overflows and race conditions? Or should Microsoft break support for some older applications to better safeguard new ones? Of course, breaking that support may require you to upgrade your software, or even buy entirely new software if the original developer is no longer in business.

What do you think?

In the third and final installment of our Testing the Limits interview with Ben Simo, we go back in time to the early 90s to find out how and why he entered the testing profession. We also rapid fire some questions on his browser of choice, his hardware preferences, hobbies and more. In case you missed them, here’s part I and part II.

*********

uTest: Let’s go back in time for a second: How did you get into the craft? What was the first application you tested? What was testing like back in the early 90s?

Simo: Providence. It was providence that got me into testing.

I was young, in love, and planning to get married.  I had been doing some part time database development work, but needed a full time job before the wedding.  I submitted letters and resumes to dozens of companies. I was willing to do almost anything that would pay the rent.  I lived in a city where the local job market was dominated by defense contractors. I quickly learned that many of them called nearly everyone who applied for anything in for an interview; so they could learn about people and add them to databases of potential hires for matching to work they did not yet have.  These companies would then present these people to the government as their available workforce when bidding on contracts. This made it frustrating for those of us looking for work. It often wasn’t clear, when going in for an interview, if it was for a real job or for a potential position that might come at some time in the future if that company were to be awarded a government contract.

I interviewed with the company for which my fiancé (now my wife of 19 years) Sophie worked. It appeared to be one of those information gathering interviews without an actual position to fill. I was asked a lot of questions but none seemed related to a specific opening.  At the end of the interview, the interviewer said he’d be calling me.  Time went by without any more contact. Nearly a month later, I got a call asking if I could start the next morning.

I was one of a handful of people hired to work as “data collectors”; to execute tests and collect results for an interoperability demonstration of digital imagery systems.  These systems, from a variety of different vendors, were used by the military for manipulating and exchanging digital photographs.  This test was the second phase of an effort to validate a new communications protocol standard. Our mission was to assess to what extent systems made by different companies could exchange information over a variety of communications systems. We were given a huge matrix of imagery systems and communications equipment (from encrypted telephones to push-to-talk radios) combinations to test. We quickly learned that this required we learn the communications systems, the imagery systems, and the protocol used to exchange data.  I enjoyed this challenge. By the end of the project, I found myself in the role of being the writer of the test report and numerous interface documents. I also learned that I enjoyed testing.

If I hadn’t received that call which led to becoming a tester, I would have likely taken a job as a pay telephone technician. We all know how cell phones have since killed the pay telephone business.

So, what was testing like in the early 90s?  For me, working for an independent fee-for-service testing organization, it was a great learning experience.  I learned that my role as a tester was to help our clients produce better products; not to just pass or fail their products.  I learned that every company followed different development and testing practices – regardless of what labels they gave them.  I learned to seek guidance from others who could mentor me. I learned that continual learning is essential in testing. I learned that testing is a better assessment tool than an assurance tool. I learned to plan and script testing only to the level of detail that made sense; understanding that some detail cannot be known up front.  I learned that testing is exploratory in nature.  I learned to communicate with stakeholders and developers. I learned that the real requirements aren’t necessarily the things documented in a technical requirements document.  I learned to create tools to help me accomplish tedious tasks and enable doing things I could not do manually. While I didn’t realize it at the time, I was becoming a context-driven tester.

After nearly a decade, I moved to working for commercial software development firms — with fear and trepidation.  I wasn’t sure that my skills would transfer to being an in-house tester. I soon discovered that they transferred well.  I spent a short time with some misguided “quality cop” thinking after I was given a “Quality Assurance” title before better understanding and returning to my context-driven roots.

Rapid Fire Q&A:

• Favorite movie of all time: My favorite movie of all time would have to be “Star Wars, Episode IV: A New Hope”. It is both one of my earliest and favorite childhood movie memories, and I still love it

• Favorite movie… that’s about testing or taught you something about testing: I don’t know about it being a favorite, but “Man of the Year” comes to mind. The movie was disappointing in that it wasn’t the comedy it was advertised to be; and the software “bug” on which the plot was based made little technical sense; however, it illustrates the potential risks of software not working as it should – either due to oversight or ill intent.

• Mac or PC: Commodore. I still do everything on my Commodore 64. Seriously, I’m a PC. I’ve not used a Mac in over 15 years.

• Browser of choice: I’ve recently come to like Chrome for most of my personal browsing. However, I prefer Firefox for testing. There are many cool add-in tools for Firefox.

• Brand of smartphone: Motorola Droid X. After seven years of using Windows Mobile devices, I just switched to Android.

• Favorite US president (no fair picking Millard Fillmore… he’s my fav): Teddy Roosevelt. I can’t help but love an adventurer.

• Top tech innovator of all-time (Edison, Gates, Jobs, Andreesen, et al): Apart from the modern computer, Thomas Edison has likely had a great impact on humanity.  So, if I had to pick only one, I’d say Edison. When it comes to computers, Charles Babbage and Steve Wozniak come to mind. The ideas of Charles Babbage led to the programmable computers we have today. And Steve Wozniak was essential in making computers personal and bringing them into our homes

• Best concert you’ve ever seen in person: I haven’t been to a real concert in over 20 years. However, I have fond memories of Barry McGuire sitting on the edge of a stage singing songs to the last couple hundred stragglers who remained.after someone else’s concert.

• Hobby that would surprise our readers: Since I recently quit my job and am looking for new work, I could say that software testing is now a hobby for me. It will hopefully be paying work again, real soon. I could call my obsession with old programming books a hobby. I collect and read old programming and testing books to better understand the history of software development.

Photography and exploring Colorado are two things I could also call hobbies; but those won’t surprise anyone who follows me on Twitter. Also, we’ve got a bit of a zoo at our house with cats, dogs, and fish. That too should not be a surprise.

What may be a surprise is that I’m a recovering collector of NASCAR die cast cars. Yes, I was once an addict with new cars regularly arriving in the mail.  I’ve now been clean, and not added any new cars to my collection, for well nearly two years.

uTest: If Al Gore had never invented the inter-web and software testing didn’t exist… what would you be doing for a living?

Simo: I’d likely be a starving photographer. When I was eighteen, I was considering pursuing a career in computer programming or photography.  My father advised me that he’d encountered more starving photographers than computer programmers. So, I pursued software over photography.

Editor’s note: We hope you enjoyed our Testing the Limits interview with Ben Simo. Who should be our next guest? You tell us.

In part II of our Testing the Limits interview with Ben Simo, we’ll discuss whether you should trust automated testing tools; the proliferation of testers on Twitter; the true meaning of “QA”; how testing evolves differently in each company; the long lost Bach brothers and much more. You can catch up on the conversation by reading part I. We’ll wrap things up tomorrow with part III.

********

uTest: Jon Bach mentioned that changing the meaning of “QA” to Quality Assistance would help outsiders (engineers, executives, et al) better understand the role of this discipline.  Agree or disagree?

Simo: I believe I first heard  “Quality Assistance”  from Cem Kaner.  I agree with Jon. When testers bear the title Quality Assurance, it often implies that they actually assure the quality of other people’s work. Testers are in a position to help assist quality; not assure it. Let’s not assist the setting of unrealistic expectations with inappropriate titles.

uTest: While we’re on the subject, are you anyway related to James and Jon Bach? The resemblance is uncanny.
Simo: I don’t think so. I’m available for adoption if the Bach family is interested.

uTest: You’ve said that you frequently use automated tools, but that you don’t trust them entirely (back to that whole defensive pessimist thing again). What advice do you have for testers and managers wanting to strike a healthy balance? And what’s currently in your arsenal of automated tools?

Simo: My mistrust in tools is based on the fact that tools can’t think for me. Automated checking can only process whatever decision rules someone thought to program when the checks were created. Automation will consistently do what it is programmed to do and consistently not do what it is not explicitly programmed to do. I find test automation to be useful. In fact, there are some things I’d not want to even try to do manually. I do, however, distrust the green bar. When automated checking passes, I ask myself what the automation does not tell me. I also try to keep aware that people who don’t understand what the automation does are likely to assume that it does more than it does.

Tools are much more than test automation. Tools are essential for testing. I don’t want to test without tools. I have some old programming books that promote testing in which a programmer manually executes code, step-by-step, with pencil and paper in order verify that the code works as expected. This is manual testing. This is a testing practice that came from a time when computer time was rare and cost more than people. We’d now laugh at someone proposing testing in this manner.

Today, whether we call it “manual” or “automated”, tools and automation are part of coding and testing software.
Programmers use fancy integrated development environments that do a great deal of the tedious work of managing and checking code. Programmers have unit testing tools that allow them to write tests as they write the code. We use tools to track and version source code. We have continuous integration tools that automatically run pre-defined tests and report results when programmers save code into shared code repositories. Today, programmers rely on interactive tools to do work that used to be done manually. These tools support people coding software rather than trying to replace them with batch processes.

Many of the tools built for testers seem to still be stuck in the world of batch processing. Rather than assist testers by helping with tedious tasks, they try to replace test execution. Some of this comes from the design-all-tests-up-front-in-procedurally-scripted-detail thinking that made sense when computer time cost more than people.

I worked as a tester for nine years before I encountered a record and playback type test automation tool. In those nine years, tools played an essential role in my testing. We built all our tools in-house. We wrote macros and scripts to do tedious data processing. We wrote code to verify data formats. We created test interfaces for databases. We created test management systems. We depended on tools but did not have a single test case that was fully automated. This automation made testers both more efficient and effective.

Rather than look at testing as something to be either manual or automated, I encourage people to look at individual tasks that are part of testing and try to identify ways that automation can help testers evaluate software. Rather than limit tools to automation of test execution, I look for ways that automation can assist testers – to turn them into powerful cyborgs.

These tools include automated test execution tools, data setup and teardown scripts, communication tools, test management tools, test logging and reporting tools, test data manipulation tools, and more. Along with test execution automation tools (take your pick), my most-used testing tools are Excel, Picasa (for screenshots), a screen recorder, and the GNU Unix utilities (also available for Windows).

uTest: Certain industries appear to be ahead of the curve when it comes to testing practices, while others remain in the proverbial stone age. Is this an accurate statement? Or have testing practices evolved at similar pace across all industries? As someone who has spent time in many sectors, we’re interested to hear your thoughts on this.

Simo: I’ve not noticed great distinctions in testing practices based on industry.

What I have noticed is that testing practices seem to evolve within individual companies and test groups. Rather than learn from what others have done, it often appears that each tester, each test organization, and each company starts in some stone age and evolves on its own – making the same mistakes that others did long before.  Lessons learned don’t seem to be shared much across companies.

I’ve also noticed that “quality assurance” groups in large commercial businesses, regardless of industry, tend to be dominated by factory school thinking. Instead of viewing testing as cognitively complex work that requires critical thinking, good communication, and continual learning: testing is thought to be predictable repeatable validation work that can be done by automation or cheap labor.  These companies tend to view quality and process as things to be scripted, controlled, and quantitatively measured. In doing so, I believe these companies dehumanize their people and their customers.  These companies tend to have what Jerry Weinberg called “overstructured management” in a paper written nearly 30 years ago; management which attempts to manage people like code: with sequential work models, binary either-or choices, and mechanical repetition. These things may be good for computers, but aren’t great for people.

While many companies are still recursively calling on the mistakes decades past, others are recognizing that people aren’t to be controlled like machines.  While they may not be familiar with either document, these companies exhibit the values expressed in the Agile Manifesto and practice the principles of the Context-Driven School. These companies value people over systems.

uTest: Who should testers be following on Twitter to stay current on the latest industry trends (I mean, besides you and us, of course)?

Simo: I’m not as interested in trends as much as I am in experience reports, and new ideas and challenges. Some of my favorites who are active on Twitter are Pradeep Soundararajan (@TesterTested), Shrini Kulkarni (@shrinik), Matt Heusser (@mheusser), Lanette Creamer (@lanettecream), Elisabeth Hendrickson (@TestObsessed), Michael Bolton (@MichaelBolton), Jon Bach (@jbtestpilot), and James Bach (@JamesMarcusBach). Beyond that, I suggest people see who these people, and I, follow and interact with on Twitter. Use Twitter’s search feature to find people tweeting about things that interest you. Don’t limit yourself to only testers or those people you like. We can learn a great deal from those outside our field or with whom we disagree.

Editor’s note: Read part III of the Ben Sim Testing the Limits trilogy.

Our Testing the Limits guest this month is Ben Simo. Known as the “Quality Frog” on Twitter, Ben is one of the most insightful and entertaining testers in the business. A proponent of the context-driven school, Ben has more than 19 years of experience testing software and developing testing tools. He currently lives in Colorado with his wife, two children, two dogs, five cats and fourteen – count ‘em – fourteen goldfish. For the full Ben Simo experience, go to his blog.

In part I of our interview, we get his thoughts on the Worst Bug Ever; his testing philosophy; what it means to be a defensive pessimist; testing certifications, the state of the industry and more. Be sure to check tomorrow for part II.

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

uTest: Your “Is There a Problem Here?” series has been a big hit in the testing community. What’s the absolute worst bug that’s ever been submitted? And what can testers and developers learn from these type of mistakes?

Simo: Many of the bugs on IsThereAProblemHere.com could be argued to not be bugs. The software works or catches and reports an error condition; but in a way that it unnecessarily frustrates users. My hope is that people involved in creating and testing software can learn from these examples. Rather than only look for the obvious technical bugs, we need to be asking ourselves “Is there a problem here?”

We build software for the benefit of people. Software fails when it does something other than solve human problems.  Although not the worst items submitted, two items come to mind.

The first occurred on Christmas Day last year.  Twitter was full of complaints by people who received Sony’s new electronic book Reader device as Christmas gifts. The device worked except that Sony was not prepared for the Christmas Day rush on their servers as people attempted to install software and purchase books.  By not sufficiently preparing for the Christmas rush on their servers, Sony turned joy into frustration for many new customers. As a performance tester, I take this as a warning to seriously consider what events may cause a surge of demand for the systems I test.

The second problem that comes to mind is one I’ve repeatedly encountered with Blogger’s auto-save feature. I like features that help prevent users from losing their data.  While auto-save features usually indicate that software designers value their customers’ data, Blogger provides a great example of how auto-save can make things worse.  The Ctrl-Z undo option in users’ web browsers goes away after an auto-save occurs.  If a user fat-fingers text in a way that deletes content just before an auto-save occurs, there is no going back. An accidental Ctrl-A instead of a Ctrl-Z or Ctrl-X followed by another keystroke can permanently delete a document in an instant.

uTest: Gotta ask about the “Quality Frog” handle on Twitter. What’s the origin of this moniker?

Simo: A few people have told me “Quality Frog” looks like two random words from a Facebook captcha.

I’d like to be able to say that I carefully selected the name and that it signifies that I care about quality and I’m amphibious like a frog. I’d like to say something along the lines that I started life as a tadpole in the waters of programming and later grew legs to live on land and be a tester.  I could even say that as a Quality Frog, I now eat bugs for breakfast and help keep the waters clear. While such thoughts may have come to mind, the truth is that I came up with Quality Frog while pairing a variety of words with Quality in search of an available domain name. Frog came to mind as something that ate bugs and the domain name was available. Since then, I’ve continued to use it as a handle.

uTest: You’re a self-described “defensive pessimist”, which seem like good qualities for a tester to have. What other attributes come in handy in this line of work?

Simo: The term “defensive pessimist” comes from Dr. Julie Norem, a psychology professor at Wellesley College.  In her book, “The Positive Power of Negative Thinking”, Dr Norem describes defensive pessimists as people who typically perform worse when pressured to look on the bright side and be optimistic about things that concern them.  Rather than trying to think happy thoughts and only look at the positive, defensive pessimists imagine the worst case scenario; not to get depressed and become immobilized, but to develop solutions for what might go wrong in order to be better prepared. Defensive pessimists can make great testers, and are likely to annoy many optimists.

The third guiding principle of the Association for Software Testing states “AST views software testing as a cognitively complex activity that requires critical thinking, effective communication, and rapid self-directed learning.”  I fully agree with this.  Therefore, I find it essential that testers be critical thinkers, effective communicators, and self-educators.  Any one of these three things without the others will make us less effective as testers.

This doesn’t mean that every tester must master all three of these on their own.  My ideal test team would be comprised of people with a diversity of aptitudes, skills, and experience. I don’t want a team of clones.

uTest: Much like our previous Testing the Limits’ guests, you’re a critic of testing certifications. Yet some still see certifications as the only way to stand out from the “unskilled labor” crowd. Tell us a bit about why you’re a skeptic/critic of certs – and how they could be improved and made more relevant/useful/predictive.

Simo: I am not against certifications per se. I am against bad certifications.  I am against certifications that are presented to be something other than what they are. I am against certification bodies and trainers that prey upon people’s desire to stand out and tell people they can improve and certify their competence as testers with few days of training and a multiple-false test. In his keynote at the Conference of the Association for Software Testing (CAST) this year, Cem Kaner stated that If one can become certified in their profession in three days, they are a commodity, and don’t deserve much more pay than unskilled labor. I agree with Dr. Kaner. Rather than educate and help people stand out from the unskilled labor crowd, such certifications trivialize testing and encourage wrong thinking that testing is unskilled labor.  I want testers to be more than a commodity.

Many IT certifications, including testing certifications, are more about marketing than education.  These certifications are not good measures of skill, competency, professionalism, quality, or any of the many things those on the receiving end (of the marketing) care about. In my experience interviewing job candidates, tester certifications have not been an indicator of applicants’ testing abilities.

Software testing is a rich and diverse field. It is also a young field. Rather than feign maturity and simplicity where there is none, let’s embrace the diversity and youth. Let’s continue to learn. Let’s not lock in a set of context-free definitions and practices and make them a standard. Such standards will hurt the quality of software, not improve it.

Rather than pursue a certification, I encourage testers to get involved in a professional community. Find colleagues that challenge you and help you learn.  Seek real education that comes through interaction and doing over memorizing information useful in passing a multiple-false test. The Association for Software Testing offers a series of online software testing courses that facilitate deeper learning that you are likely to find in training focused on helping you pass a certification exam.

Editor’s note: We hope enjoyed part I of our interview with Ben Simo. Here’s part II.

While there’s a lot of debate about what constitutes good testing and acceptable levels of quality assurance, can we all agree that your app should not cripple your testers and users?  Ok, good.

And if this does resemble your launch decisions a little too closely (seriously, I hope not), give us a call.  Happy weekend, everyone!

Our guest blogger this month is Atul Angra. A resident of India, Atul is one of our more accomplished testers (a Gold Tester in fact), with over six years of professional experience. He’s a photographer at heart, but a tester by trade, with domain expertise in healthcare and finance. He’s also a former Bug Battle winner, a guest judge, a Tester of the Year, a Forums junkie, a crash course author and he’s here today to discuss how interpersonal skills can make or break a tester’s career. Enjoy!

*******

Let’s take a scenario where a tester follows the rules and reports 100 bugs. Some of these bugs were traced to non-documented requirements that are implicit in nature, such as a drop-down list not populating alphabetically and things of that nature. These bugs are quite common and usually end up in conflict, as development teams reject them based on the argument that it’s not a defined requirement.

Here, both the developer and tester are not ready to close this issue – and they are both correct. The traditional way these issues are resolved is by involving someone from management to intervene and make a decision. The time spent in escalation and argument is much greater than what it would have taken to actually fix the issue.

At a high level, we could blame the team which collected requirement, but this may not be the case when it comes to implicit requirements. Many of these situations could be resolved if the tester demonstrates interpersonal skills.

Testers play a challenging and critical role in the organization. They dare their developer counterparts and are constantly challenged by release managers, as they pose significant risk in delaying the release. This may even stop the organization from achieving a financial target on time. In other words, testers play the role of Devil’s advocate when it comes to improving quality of a deliverable.

As such, good testing skills and good interpersonal skills make the KILLER COMBO that suits this role. Critics are rarely appreciated for their work, but coaches are. Yet coaches and critics do the same thing: they point out your mistakes and give you a chance to perform better the next time around.

The difference is in their approach. An ideal tester should become a coach instead of a critic. Developers turn defensive when testers approach them with a statement such as “This is not working as intended.”

With good interpersonal skills, these discussions can become more effective. A good tester will put forth a scenario that makes the developer consider the impact if the bug is not fixed.

A tester who reports the maximum number of critical bugs with a low rejection ratio is considered efficient. Other expectations from testers are to meet deadlines, ensure process compliance, and practice good documentation with complete functional testing. They ignore a very important attribute here:  interpersonal skills.

Conclusion:

A tester might have all the required technical skills, but may still fail because of his/her interpersonal skills. A bug that could have been amicably solved turns into a management issue with leads to a lot of wasted time.

Testers should spend time in enhancing their interpersonal skills. People always like to have colleagues who are a good listeners and who love to share knowledge. One who shares information and resources, and is helpful by bringing conflicts to the surface and getting them resolved in an ethical and professional manner.

Editor’s note: If you would like to write for our Guest Blogger series, send your posts and ideas to me at mikeb@utest.com

While Paul the psychic octopus was retired after the 2010 FIFA World Cup, a new and improved octopus – the Ika-tako Virus (which means Squid-Octopus in Japanese) – surfaced in Japan. According to PC World, the virus has infected between 20,000 and 50,000 computers and…

“disguises itself in music files, which users then download. Once the file is played, the malware runs through the computer’s hard drive, infecting anything from family photos to important OS files. The infected files are swapped with the squid, octopus or sea urchin pictures and removed, then supposedly sent to the hacker’s server.”

According to asahi.com, if the virus is left unchecked, all files in the computer’s hard disk become infected.

What’s worse is that the hacker, Masato Nakatsuji, told police the reason he did it was to “see how much [his] computer programming skills had improved since the last time [he] was arrested.”

There has to be a better way to LEGALLY gauge the development of your skills, right? There’s no known fix for the virus yet, so unfortunately this hacker has left quite the “ink” trail.

So, how do you test yourself to make sure your skills are developing and not remaining stale? (Legal stories only please.)

In the software testing business, GUI bugs (graphic user interface) are looked down upon – and rightly so. Nobody wants their users navigating through a visually defective application. Software should be clean, polished and aesthetically pleasing. You want your software to be George Clooney, not George Costanza.

But not everyone puts such a high premium on looks. Modern artists, in fact, are doing just the opposite.

Take “glitch art” for example. Defined by Wikipedia as “the aestheticization of digital or analog errors, such as artifacts and other ‘bugs’, by either corrupting digital code/data or by physically manipulating electronic devices,” the trend is attracting more and more mainstream attention.

Wired’s UK site recently posted a fascinating piece on glitch art. They teach us, among other things, that the term is somewhat in dispute. For some, the glitches must be genuine (i.e. unintentional) while others insist that glitch art can be deliberately created, mainly through a technique known as data bending:

Databending draws its name from the practice of circuit bending — a practice where childrens’ toys, cheap keyboards and effects pedals are deliberately short-circuited by bending the circuit board to generate spontaneous and unpredictable sounds.

Databending takes a similar approach to circuit bending, using software to intentionally disrupt the information contained within a file. There’s all kinds of different techniques, some involving deep hex editing of certain parts of a compression algorithm, but other methods are surprisingly simple.

I bring this to your attention for two reasons. One, it’s cool. Two, we’re about half way through our Bug of the Month contest on Facebook, where a bug of this variety would almost certainly give you enough “likes” to be in the running for the Grand prize (an iPod Touch). Just saying.

Anyway, be sure to keep this in mind the next time you’re submitting GUI bugs. What you consider trash could end up being the next modern day Mona Lisa.

Rumors of the mobile web’s death have been greatly exaggerated. Despite some compelling arguments in Wired’s latest series -  where experts assert that native apps have (or will soon) totally displace the web as a medium of choice – we’re not quite ready to pull the plug. Apparently, neither is the general public. Not just yet.

More on that in a second, but first, let’s examine why some are making this claim. It’s true that there’s been a meaningful shift towards native apps over the last few years, thanks mostly to the iPhone and its offspring (i.e. smartphones). What was once the Great Wide Open, the Internet has been parceled into what Wired calls “semiclosed platforms that use the Internet for transport but not the browser for display.”

In other words:

You wake up and check your email on your bedside iPad — that’s one app. During breakfast you browse Facebook, Twitter, and The New York Times — three more apps. On the way to the office, you listen to a podcast on your smartphone. Another app. At work, you scroll through RSS feeds in a reader and have Skype and IM conversations. More apps. At the end of the day, you come home, make dinner while listening to Pandora, play some games on Xbox Live, and watch a movie on Netflix’s streaming service….

You’ve spent the day on the Internet — but not on the Web. And you are not alone…

Quite true. But you are also NOT alone if you’re still using the mobile web. As part of our weekly “What Do uThink” poll question, we asked our community whether they prefer to get information via native apps or the mobile web. Here were the results:

- 57% of respondents said they prefer the mobile web (i.e. sites configured for mobile devices)

- 43% of respondents preferred native apps

Wrote one respondent: “My vote goes to Mobile Web as well. There are particular native apps that I use on a regular basis, mainly due to ease-of-use and simplicity. These include weather apps, travel planning apps (kayak.com), music apps (pandora). However, if I’m accessing news and searching for information, I use mobile sites that automatically render as mobile versions of their web sites (cnn.com, google.com)…

…I also foresee the future in which mobile web will be much easier to use, and displace most (not all) of the need for native apps. Instead of downloading the native app itself, there may be shortcuts on your mobile device for easy access. Think about the recent progression away from desktop apps and into purely web apps; mobile is simply a few years behind.”

So is the mobile web dead, dying or just sleeping soundly? Weigh in with your thoughts.

I recently came across this article, Personality Traits in Software Engineering, which conducted a research survey assessing the major personality traits of software testers and developers. Turns out — and I’m not at all surprised having met so many testers in our community — software testers rock! Here’s how the scores break down:

According to Anne-Marie Charrett in her blog, Maverick Tester, “On average we [testers] are an agreeable bunch of people, open to experience (see below) with a high cognitive capability. A hearty clap on the back fellow testers, we all knew we were pretty special.”

I couldn’t agree more! So, yes, this is simply a feel-good blog for all those testers out there with a case of the Mondays. Give yourselves a hand. And Happy Monday!

The Twitter bird has been seen a lot more than the Fail Whale in the past few month — a testament to the company’s investments in infrastructure. But now, a third species has jumped into the Twitter spotlight: the bug.

And while this particular bug has since been squashed by Twitter’s engineers, it’s still an interesting defect. As all of the major new media heavyweights noted, this Twitter bug briefly enabled the brevity-challenged among you to stretch your legs and break free from the shackles of 140 characters. To put it more plainly, let’s bring in Alexia Tsotsis (@alexia) from TechCrunch:

The Twitter bug which has left many befuddled is exploiting a length limit flaw in the new t.co URL shortener, allowing users to tweet out non-URL links of outrageously more than 140 characters

If you’d like to reproduce the effect, and it seems to be catching, you can visit http://twitter.com/share?text=&url=yourtext, add whatever you want in place of “yourtext,” copy and paste your new t.co URL to Twitter and long tweet away.

Update: Looks like the nimble engineers at Twitter have disabled the feature within the hour this post went up, much to everyone’s dismay. Scripting News’ Dave Winer went so far as to create a web app for the Fat Tweets.

For those of you who follow Twitter (sorry, couldn’t resist), check out the entire TechCrunch article, as well as Mashable’s take.

Today is Friday the 13th – a date that’s become widely known for superstition and mediocre horror movies. But while some remain paralyzed by friggatriskaidekaphobia (it’s a word, look it up), our tester community remains undeterred, as they continue to participate in the uTest Bug Battle and our ‘Bug of the Month’ contest. How are they going so far? Glad you asked. Here’s an update on both.

First, the Bug Battle: There are now less than three days left in the current bug-hunting competition, which is comparing four of the most popular job sites (Monster, CareerBuilder, Indeed and SimplyHired). The testing phase of the competition ends Monday, August 16 at Noon ET. So far, more than 350 testers have reported 500+ bugs, but there are still plenty of chances to log some bugs and capture your share of the $4,000 in prize money. Sign in and get started!

The ‘Bug of the Month’ contest is also off to a terrific start. A quick glance at our Facebook page shows that more than 20 people have submitted bugs, garnering 200+ “likes” in the process. As with the Bug Battle, you have nothing to lose (and you could win an iPod Touch!) so go ahead and submit your own ‘Bug of the Month’ candidates.

Good luck and have a great weekend.

As long as we’ve had the World Wide Web, we’ve needed software to browse it. Originally, that meant using a tool like Mosaic or Lynx. Today, we have a wide variety of browsers from which to choose, each with their own strengths and weaknesses.

So it was in this spirit that we polled our community of testers to find out which of the next-generation browsers they were most excited about as part of our weekly What Do uThink polls in our forums. The outcome was tight, with Firefox 4 and Chrome 6 together taking 86% of the votes (Firefox 4 had 46% of the votes and Chrome 6 had 40%). Internet Explorer 9 came in third and garnered the bulk of the remainder.

We posed the same question to users on Facebook, and the results were nearly the same. Firefox won with 50% of the votes, but Chrome was right behind with 33%.

So which do you prefer? Are you excited by Chrome’s astonishing performance improvements and built-in PDF reader? Or are you looking forward to Firefox’s Tab Candy interface? Of course, you don’t have to agree with our community. Internet Explorer 9 features some rocking speed improvements and support for HTML5, while Opera 10.60 now features some killer geolocation features. And don’t forget about Safari 5, which now supports extensions for easy modification.

The browser wars are hardly over, and I couldn’t be more excited. That’s probably why I use all of them! What do you think?

For the past several months, we’ve been knocking off some highly sought-after platform features, and v3.0.4 is no exception. And with this latest release, we’ve made it even easier to choose the perfect testers for your project and integrate with more of the top bug-tracking systems.

Easier Tester Selection

When our customers create a new test cycle, we want the process to be as simple as possible. But we also want to put the highest degree of power and precision in their hands when it comes to building their testing team. One of the more common feature requests we’ve heard is to make it even easier to select testers for private test cycles. Our product crew has heard your cries, and we’re pleased to introduce a dramatic overhaul of the tester selection process when creating a test cycle.

We realized that every customer has a different set of needs when it came to finding exactly the right set of testers for their product. So we made it easy to search within testers and handpick the best candidates. After a test cycle has launched, the tester selection will even tell you which invited testers have accepted your testing invitation. Need more testers in a certain region? Finding and adding more will be a snap. Check it out!

More Bug Tracker Integration
More and more companies are using bug tracking systems, and we’ve long made it easy to move bugs from uTest into several popular systems. Until recently, we’ve supported Bugzilla, Jira, and Rally. With this release, we’re adding support for Mantis. We’ve also added support for Jira Studio, and we’ve improved our support for Rally. Lastly, our engineers have even built integration with the bug tracking systems of some of our biggest customers.

Is your favorite bug tracking system not yet supported? Let us know, and we’ll add it to our list.

More Handsets for Tester Profiles
If there’s one thing that’s true in this world, it’s that gadget makers never stop making new gadgets, and that gadget lovers never stop buying them. We’ve added a whole bunch of new devices to our database, including the iPhone 4, the iPad, and more. If you are a tester who has the latest and greatest mobile phone or tablet, make sure you update your tester profile with that information so we can assign you projects.

All the Rest
That’s not all! We’ve also worked on a couple of other smaller, but still important features:

• Search for test cycles by their ID
• Misspelled words are now highlighted in text boxes
• Dozens of bug fixes and behind-the-scenes improvements

Have a great idea for our future product releases? uTest community members can join our tester forums and check out our Platform Feedback section. Customers can contact their project manager directly or drop us a line.

Whether you’re a crowdsourcing critic or devotee, it’s worth hearing all the angles from the experts and from those who have built crowdsourcing business models. Check out the Top 20 Crowdsourcing Tweeps (experts and companies) to follow on Twitter below (in no particular order). Also, here are a few recent articles to hopefully spark even more debate — The Huffington Post’s Does Crowdsourcing Threaten Your Job (or Offer New Opportunity)?, Entrepreneur Magazine’s Crowdsourcing: Opportunity or Time Suck?, and Network World’s Could designer bras be a natural fit for crowdsourcing?.

1. Jeff Howe, @crowdsourcing (coined term crowdsourcing, quiet this summer)
2. LiveOps, @liveops
3. Neil Robertson, @nielr1 (co: @Trada)
4. John Winsor, @jtwinsor (co: @VictorsnSpoils)
5. Ross Kimbarovsky, @rosskimbarovsky (co: @crowdspring)
6. Dwayne Spradlin, @InnoCentiveCEO (co: @innocentive)
7. Tim Thomas, @imstarboard (co: @localmotors)
8. Community Roundtable, @jimstorer & @rhappe (co: @TheCR)
9. 99 Designs, @99designs
10. CrowdFlower, @crowdflower
11. uTest, @uTest (shameless self plug )
12. Chokha, @chokha
13. Mike Martoccia, @mmartoccia
14. Top Coder, @TCJim (co: @_TopCoder_)
15. Threadless, @threadless
16. Chaordix, @chaordix
17. Peter Lamotte, @peterlamotte
18. Genius Rocket, @GeniusRocket
19. SmartSheet, @crowdwork & @mcolacurcio
20. Tongal, @tongal

Update! Apologies for those I may have missed. Here are more recommendations straight from the community: @crowdsourcecap, @ArticleOne, @crowdsourcerisk, @fergusdyersmith, @OpenRunway, @crowdsourcery…

More can be found on our actual Crowdsourcing Twitter list. So, who do you follow on Twitter to find the best crowdsourcing advice and breaking news? Did I miss anyone? Please let us know in the comments and I’ll add them to the list.

A quick update on the latest uTest Bug Battle. We’re five days into the competition, which is comparing four of the world’s top job sites: Monster, CareerBuilder, Indeed and SimplyHired.

With just under seven days remaining, we’ve already had more than 300 testers participate and well over 400 bugs reported. Although the quantity is impressive, we’re even happier with the quality of bugs being reported. These sites are very feature rich, so we expect more of the same as the competition progresses.

Remember, the Bug Battle ends Monday, August 16th at noon ET, and there is nearly $4,000 in prize money at stake. It’s not too late to win the top prize, so log into your uTest account and get cracking.

For a primer on how to win the Bug Battle – especially the usability part of the competition – we highly recommend Santhosh Tuppad’s latest blog post. You can also find tips in the uTest Forums.

Good luck the rest of the way!

By now, readers of our blog and newsletters are aware of our interest obsession with all species of software bugs. Whether it’s a funny error message, a fatal security flaw, or a glitch that prevents raw sewage from being treated, we’re always happy to hear about the “showstoppers” encountered by everyday users.

With that in mind, we’ve decided to launch a monthly contest titled….wait for it….Bug of the Month! Here are the basics:

• Start date: Mon, Aug 9th
• End date: Sun, Aug 29th
• Where: on uTest’s Facebook page
• Prize: a shiny new iPod Touch

And here’s how you play:

• Step One: “Like” uTest on Facebook
• Step Two: Find your favorite bug or error message (funny/scary/annoying) from any piece of software – websites, mobile apps, printers, etc.
• Step Three: Upload your screenshot or video to uTest’s Facebook wall
• Step Four: Tell your friends, family and colleagues to “Like” your bug

Whoever gets the most “Likes” by the end of the month wins the iPod touch. Easy enough?

Remember, this isn’t like the Bug Battle – you DO NOT have to report these bugs through the uTest platform, you DO NOT have to document the type/frequency/severity, and you DO NOT have to be the person who originally discovered the bug.  This is a public contest and the most popular bug wins!

So if you’ve seen a software bug that you feel is worthy of this honor, visit our Facebook page and get started.

The latest uTest Bug Battle is officially underway! As mentioned a few days back, the focus of this quarter’s competition will be on four of the world’s prominent career sites. So for the next 10 days, testers from around the world will be searching Monster, CareerBuilder, SimplyHired and Indeed for the most compelling bugs – and reporting in our online platform.

With the high unemployment numbers making headlines (and with Labor Day right around the corner) we were curious to find out which site would be the most helpful for those in search of work. In other words, which site has the best feature set? The easiest sign-up process? The most accurate search results?

That’s for our community to decide. Once the testing phase of the competition is over on August 16 at noon, we’ll be sending a survey to all participating testers to compare the usability and feature set of these four applications.

Why should you participate? Well, bragging rights, for one. But we’ll also be awarding nearly $4,000 in prize money to the testers who report the most interesting bugs and provide the most insightful survey feedback.

So what are you waiting for? 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 Q3 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!