You’ve mastered the technical skills, but why aren’t you advancing in your QA career? Joel Montvelisky, a tester, test manager and QA consultant with over 15 years of experience in the field of Quality Assurance, tackles this question in the following guest post.  You can read more about Montvelisky’s views on testing, agile, training and more on his blog – QA Intelligence.

******

While presenting at a recent training session to a group of testers, one of them asked me what were the most important skills I thought a tester should have in order to advance in his career.

As I had my “mentoring hat” on, I immediately asked the whole group what they thought the most important skills for testers were.  They started throwing out all sorts of ideas, like analytical thinking, the ability to “read” code, knowledge of web and mobile technologies, automation, an eye for detail, etc.

I guess I should have expected that. Working as we do around programmers and engineers, the testers focused only on the hard and technical skills.  And I don’t blame them either, since these skills are incredibly important. In fact, I even wrote a post about being a technical tester in my QA Blog.

But in a sense, this is also one of the biggest mistakes you can make as a tester; to focus solely on the technical skills and not develop the “softer” skills that are also vital to performing your work well.

If you look at the testers who are the most valued by your company, in addition to technical skills, they also possess a number of other skills that help them to contribute more and to distinguish themselves and their work.  These are also the testers with greater chances of advancing to higher managerial positions.

Wouldn’t you want to be one of those people and have those opportunities yourself?

Well, I can’t sell you a potion for that, but I can explain the softer skills that are helping these most valuable testers, and how can you develop them too.

There are many soft skills a tester can acquire or develop, but after interacting with a large number of testing teams and development organizations, I’ve identified three skills that I believe are the most important for a tester. These 3 skills are:

1. Communication skills
2. Political skills
3. Customer-facing skills

Communication skills

Communication skills are the single most important set of skills a tester should have – even more important than any technical skill you can think of.

By communication, I don’t mean only the ability to write a clear test case or an informative bug; it goes much further than that.

Communication starts with the ability to listen to what other people are saying and to translate that information into action.

In a QA Blog post I published in the past called, “Of Testers & Soldiers” I likened the role of testing to that of an intelligence officer’s in the army whose task is to seek information from multiple and scattered sources, and then piece it all together in order to map out a complete plan of risks and actions for his commanders or managers.  This can only be done if you are able to both listen and process the information quickly and effectively.

An additional aspect of communication is the ability to transmit your message clearly and in a way that will encourage your audience to listen to what you have to say.  As an old colleague of mine once told me, “We are all salespeople.  Some of us sell cars, others sell ideas.”

Read more…

The recent news stories surrounding the NSA programs that collect phone data and track overseas email have stirred up a lot of controversy. No matter what side of the issue you fall on, the take-away no one in the software application world should ignore is just how touchy people are about privacy and transparency. One of the main arguments being played out in the media about the NSA leak – and even mentioned by some top ranking officials – is that the public should have been given more information about the existence of these programs. Something can be confidential without being so secretive. This is the argument you, as an application developer, tester or brand owner, need to be paying attention to.

We’ve seen this issue come up time and again – users notice changes in privacy policies and start spreading the word about the “nefarious” practice. Petitions are created, people call for boycotting the offending application, rumors abound, false “security steps” are spread and users generally complain and call for a redaction of the change. This can be sparked by the smallest, most insignificant change. All it takes is a misunderstanding of the new policy or a “secret” change that users weren’t notified about. Catch users off guard or be vague and confusing and you’re asking for trouble.

Take January’s Instagram debacle for example. The service did notify users that a change was coming, but the updated policy was confusing and lead people to believe their photos could be used in advertisements without their knowledge or permission. Instagram scrambled to clear the air.

Earlier this week, we introduced a set of updates to our privacy policy and terms of service to help our users better understand our service. In the days since, it became clear that we failed to fulfill what I consider one of our most important responsibilities – to communicate our intentions clearly. I am sorry for that, and I am focused on making it right.

Even after that post, the policy left something to be desired in the “communicating clearly” category. When legal experts took a look at the policy, they were just as unsure about what it allowed the service to do – which doesn’t bode well for transparency. From The Washington Post:

But the updated language was not immediately available, leaving many users still skeptical about Instagram’s intentions. Legal experts said the “terms of use” document was remarkably expansive. Elements would apply to users as young as 13.

Privacy is still an evolving field and we’ll be creating new standards and best practices for years to come. But the one thing we can do now and continue doing as privacy standards change is work on transparency. If users are presented with changes and understandable terms of service and notified when an application is accessing or storing extra features or data they can make a more informed decision and are far less likely to feel blindsided and violated.

In a lot of situations, notifying users (in a clear, understandable way) about your privacy practices, what data is being tracked and how it’s being used is legally mandatory. The California Online Privacy Protection Act (which also applies to mobile apps) requires that “an operator of a commercial Web site or online service that collects personally identifiable information through the Internet about individual consumers residing in California who use or visit its commercial Web site or online service shall conspicuously post its privacy policy on its Web site, or in the case of an operator of an online service, make that policy available.” The policy has to notify users about “the categories of personally identifiable information that the operator collects … and the categories of third-party persons or entities with whom the operator may share that personally identifiable information.”

A lack of transparency (among other things) has landed Facebook in hot water more than once. In 2011 Facebook was forced by the FTC to adopt more transparent privacy practices – and to stick to them. From Macworld (emphasis mine):

Read more…

I always thought that those “Christmas in July” campaigns were bogus – that is, until I came into the world of software testing. While the holiday shopping season is probably the last thing on the minds of consumers, the same cannot be said of retailers and their respective dev and QA departments. For them, the holiday shopping season is well underway. And yes, I realize it’s not even July yet.

By this I mean to say that retailers (who, to be fair, never really have an off-season) are busy prepping and refining their applications so that they are ready to roll when the peak holiday shopping season comes around. For them, identifying and fixing bugs becomes a top priority during this time, as they do NOT want these types of issues appearing before users come November/December.

Why? It should be obvious to most, but a recent guest post on retail-digital.com frames the problem perfectly:

Approximately 70% of errors in software projects arise during the early analysis and design stages. Incomplete or inaccurate requirements and inadequate testing can lead to costly re-work, while Early Error Detection and correction can cut the resulting costs by up to 90%.

When software errors and system failures cause consumers to perceive a retail brand negatively, improving quality becomes a priority. However, hastily implemented quality programmes are not the answer. Quality-driven retailers have clear objectives and robust processes for gathering, analysing and taking action on information and feedback on a rolling basis.

Bottom line: Poor quality can cost retailers customers and money! To make sure this doesn’t happen, here are 4 tips for retailers when it comes to testing:

Read more…

Imagine you’re a software tester who just got a assigned to a project, and you’ve quickly discovered and reported tens, hundreds, thousands of bugs. This makes you an all-star, right?

Now look at it from the other side of things, from the perspective of the company or developer who is receiving those bugs. That mountain of bug reports probably feels like a lot of noise.

So, should testers report every bug they find? It’s a tough question, and one that has sparked an enticing debate within our community of 80,000 testers.

“No, It’s Too Much Noise”

Some testers say no, don’t report every bug you find. These testers claim it’s too much noise for the recipient, thus detracting from the high-priority issues. According to testing expert, Lucas Dargis, “I usually give [new testers] some unusual advice. I tell them to ignore low-value bugs; don’t even bother reporting them”. However, Dargis’ advice isn’t all that unusual.

It is quite common that the development team only wants the most relevant bugs reported. Dargis’ perspective comes from his own experience testing a buggy application and (regrettably) reporting all the bugs:

“I was working on a particularly buggy application. I took the approach of logging every bug I came across, even though I knew most of them were low-value. The bug list grew quickly. Soon I had over 100 bugs, but logging bugs takes time and so I had only been able to test about half the application.

It took our PM a week to weed through all those bugs and in the end, he decided that the majority of the bugs were not going to be fixed. Moreover, I had already used up my allotted testing time so we had to launch the product without full test coverage. As you might expect, our customers found several serious bugs in the app after it was in production.

So while technically I didn’t do the wrong thing (I reported bugs, that’s my job right?), I didn’t do the right thing. I should have focused on serious high-value bugs first and only after we were confident we had found enough of them, move on to the low-value bugs as time allowed. I could have saved myself and the PM countless hours of work, and we could have released a higher quality product.”

Low priority bugs can clutter and overwhelm the development team receiving and attempting to fix the issues. By only reporting bugs in-scope, that need the most immediate attention, dev teams can fix the big issues quickly. It makes a lot of sense.

“Yes, It’s My Duty As a Tester to Report All Defects”

But let’s look at it from the other side of things. A bug, no matter what the value, is a bug. According to testing expert, Ryan LaMontagne, as a tester it is your responsibility to identify and report software issues:

“…I believe it is our job and responsibility to file the defect(s). We as testers don’t know if this will be considered high value or low value, but it will deliver value the client expects.

I always tell my Team to never make an assumption. It’s better to file a defect than let it go. Let the client make the decision on the value unless specified.There is a cost involved with fixing defects later in the development cycle and I feel it’s our job to help the clients by reporting all defects, letting them decide on the value, and save them cost upfront.”

Read more…

In an ideal world, testing would be done within the comfy confines of a staging environment, where software bugs – no matter how big or small – had zero chance of making it in front of real users. In this environment, testers and developers would have ample amount of time (and practically no pressure) to identify and fix issues. They could then launch with no surprises and sing songs together while their bosses showered them with praise.

We don’t live in that world. Instead, we live in a world that sometimes requires us to test our applications in production, in front of real users. Sometimes, there’s simply no other option.

But what are some of those instances? When does it make sense to test in production vs. a staging environment? I don’t presume to know all of the times when this might be the case, but a recent article from the insurance industry (ironically enough) highlighted a few times when and why testing in production is necessary.

Here is their broad overview, followed by a few examples:

In fact, we test in production all the time. Even well-disciplined, well-managed application development teams must rely on a production release to fully vet and test their code. I am not talking about unit testing, or functionality testing, or integration testing, or system testing or even performance testing.

We still need to do all those things and if we do them correctly we won’t have any bugs or code defects when we go to production. But it is impossible to validate actual performance of a complex system in a lower life cycle. The key word here is test. You can test and retest, but all you are really doing is validating the performance and functionality of the application in a testing environment.

There are a few specific examples mentioned by the author – and they are some of the same reasons cited by TiP expert Seth Eliot when he was interviewed on our blog. The first of which involves data. The author writes:

Read more…

Just how fragmented is the world of real-life, still-in-use software? More fragmented than you’d like to think.

Not only are you contending with frequently released operating systems and versions, the back log of versions you need to support isn’t shrinking as quickly as most developers would probably like. Just how old is some of the software people are still clinging to? Let’s look at some numbers.

The old standby browser, Internet Explorer, is famous for having users who aren’t the quickest to update. Despite repeated rumors of its demise, IE6 is still kicking ever so slightly (with less than 1% of IE market share), according to stats from W3Schools. Internet Explorer’s market share is mostly spread across versions 8-10, though IE 10 hasn’t quite caught up to the others. So, if you want to cover the entire fragmentation of Internet Explorer, you need to test on five different versions.

In the mobile world things aren’t any better. We’re up to the seventh major version of the Android operating systems (with several sub-versions mixed in). If developers want to support all versions with a sizable market share, they need to account for Gingerbread, Ice Cream Sandwich and Jelly Bean – all of which have more than 25% of the Android distribution. While it pales in comparison to the big players, Froyo still accounts for nearly 4% and even Eclair has almost 2%. Total: 3 major versions that definitely need support and 2 older versions that should possibly be considered (location and popular device manufacturer of your target market will be a major deciding factor).

iOS is less forth coming with their distribution stats but David Smith took a look at the users of his Audiobook app to give people a general idea of what overall version distribution might look like.

On all mobile platforms (iPhone, iPad and iPod Touch) users are overwhelmingly using OS versions 6+ (more than 80% of users). Step down a major version and you reach another 10%. Anything lower than OS 5 is pretty nominal and developers like David have stopped supporting these versions (which each grab 1-2%).

Audiobooks no longer supports iOS versions prior to 4.3.0. The population below these limits was below 4% when support was dropped. Residual usage will occur at these OS versions but no new customers are being added.

Now for the kicker. Windows XP was released 12 years ago and is still in use … by a lot of people. From CNET:

Microsoft’s XP operating system is still used on more than a third of the installations out there, according to figures from Net Applications. Is it really still that popular? …

On Friday, figures from Net Applications showed XP with a robust 37.74 percent of all Windows and Mac OS installations worldwide, down only slightly from 38.31 percent in April.

It’d be difficult to support all past versions of software and the hope is that if enough developers stop supporting it eventually these holdouts will update. In the meantime it’s important to pay attention to the version distributions in your field (be it mobile, desktop or web) and support as many versions that have significant users.

As with all data, don’t take these stats blindly. Do a little digging to figure out which versions are most important to your user base and be sure to develop and test for those. If you’re having trouble achieving test coverage in this fragmented world, crowdsourced testing can give you access to a lot more hardware/software combinations than you could ever house yourself. If you’re going to support multiple versions, do it right, don’t skip testing.

Now before you go and actually spend 10,000 testing to answer that, let us first put the question into context.

There’s an idea floating around that in order to become an expert in a given field, one must spend roughly 10,000 hours honing those particular skills. Apparently, no one has taken credit for the 10k hour rule, but it’s believed to have been popularized by author Malcolm Gladwell in his book Outliers. So if you spend 10,000 hours on something and don’t become an expert, blame him. Or at least get your money back.

Anyway, for some professions, the 10k rule would seem to make perfect sense. But we’re not talking about some professions here, we’re talking about testing. And in my view, there’s a lot more that goes into becoming a testing expert than just time. There’s passion, intelligence  curiosity, work ethic and many other “nurture” traits that can never be substituted for time. Time certainly helps – don’t get me wrong – but it’s not everything.

To illustrate my point, take a look at this quote from a CNN.com article on the Secrets of Greatness:

For example: Simply hitting a bucket of balls is not deliberate practice, which is why most golfers don’t get better. Hitting an eight-iron 300 times with a goal of leaving the ball within 20 feet of the pin 80 percent of the time, continually observing results and making appropriate adjustments, and doing that for hours every day – that’s deliberate practice.

In other words, it’s not the amount of time you spend testing that will make you an expert, it’s how you spend that time. If you plan on spending 10,000 hours testing, make sure you spend it wisely! As James Bach once said in on our blog:

Read more…

Not just anyone can claim to be an exceptional software tester. Software testing requires a unique skill set, and the best software testers are the ones that continuously strive to expand their knowledge and hone their testing strategies. In short, good testers always want to get better.

So how can you become a better tester?

We recently posed this question to our community of 80,000 QA professionals in the uTest Forums. Here’s a look at the top 10 responses we got from the uTest community, and why these tips are so important:

1. Test for quality over quantity: “Here’s 10,000 bugs… good luck!” Testers, please don’t ever shoot for quantity. Identifying the most important bugs and glitches, and helping the company or developer make sense of the bugs is ten times more helpful then testing for mere volume.
2. Learn to prioritize: In line with “quality over quantity”, prioritizing what you test is extremely important. Testing the mission critical parts of an application before the minute details of an app will help you to identify the most valuable bugs first. This will also allow the development team to fix the most imperative parts of their application as quickly as possible.
3. Practice and improve your written communication skills: Everyone can right, write? (Ha!). Good testers must have excellent written communication skills in order to write good test cases, bug reports and so on. These testing artifacts are an essential part of QA and must be detailed and easy to consume.
   
4. Learn from your own mistakes – and from others too:  Everyone makes mistakes, but learning from others and from your own will make you better tester. How can you improve your bug report next time? How can you prioritize better during the next test cycle? How can you communicate better with the development team? These are questions you should constantly be asking yourself, and your fellow testers.
   
5. Be objective and professional: Every time you test, go at it with a fresh perspective. Look at the software you are testing without bias or past experience, and test with an open mind. Testers who think “Oh, I know this software” or “I’ve used this before” are at risk of overlooking important bugs. Objectivity is key.
   
6. Don’t be humble with software… think out of the box: Explore the software, ‘test to break’ and be willing to suggest improvements; these are all attributes that make up the attitude of a good software tester.
7. Question. Everything: Does this work as intended? Does it work on all devices? Does it work under every possible use-case, every time? Question. Everything.  
   
8. Think like the user: Remember; your job is to find bugs before the software reaches the hands of users. Pair your technical skills with an end-user’s mindset and you will find the best, most valuable bugs possible.
   
9. Increase the effectiveness of bug reports: Attaching screen shots and providing detailed bug reports will give the developer the information he or she needs to understand the bug and fix it. Where did it occur, when, how many times, on what devices, running what operating system and under what circumstances? Without the right details a bug is useless to a development team.
   
10. Be Passionate! To excel in any field, you need to be passionate for what you do. Read, seek new training opportunities, engage with your fellow testers, attend testing conference, classes – immerse yourself in all things QA.

What do you think it takes to become a better tester? Share your thoughts with us in the comments section, or join in on the discussion in the uTest Community Forums!

Focusing on your staff and production methods can help you meet the challenges of releasing a product quickly and on time. I’m not talking “we’re going to use the Agile method because it’s ‘better’ and faster.” I’m talking about looking at your teams – both as individual players and cohesive units – and understanding how they can work more efficiently.

Expert after expert has said that a methodology is only good if it works for you – you shouldn’t adhere strictly to a method simply for namesake. That same sentiment can be applied to maximizing the efficiency of your teams. Don’t throw work at a team simply so they’re always busy. Pay attention to the time they need to complete a task well and set the flow that way. Overloading a team will bog them down and force them to rush through work to keep up. Rushed work is poorly done work and can cost you down the line when you need to release a patch for an issue that made it through to production.

Derek Huether, of Leading Agile, says that like the original Ford Motor plants, it’s about maximizing the flow of work, not the amount of work.

Henry Ford did not have everyone working at 100% utilization.  If everyone worked at 100%, the result would have been congestion — bottlenecks within his (assembly) system and the production of excessive parts inventory.  Instead, one of the many things he did was focus on limiting lead times.  That’s the time something waits before an activity happens.  By understanding his system, he was able to have the right amount of people, working at the right pace, in the right sequence, in order to maximize flow (delivery through the system).

He recommends understanding four key factors to help maximize the flow:

• Understand Current and Potential Capability and Capacity
• Understand the Delivery System and Establish Goals
• Balance Capacity and Capability with delivery throughput
• Monitor Performance

You can read more about each point at Leading Agile.

The key here is figuring out what works for your teams. Don’t flood them for the sake of keeping them busy, but don’t let them have so much down time that they get bored and lose their focus.

Creating a truly efficient environment needs to spread beyond the QA department. Waiting until the end of the SDLC to address quality and testing is only going to slow down the process. Simple problems need to be addressed or avoided earlier in the process. Have QA professionals review the product’s purpose, features, early designs and any potential road maps – they may be able to spot problems before anything is coded.

Read more…

I would imagine that completing a software project ahead of schedule is like being told by your doctor that you’re too healthy, or having your accountant tell you that you have too much money, but apparently it does happen. The forums on Dice.com prove it.

So what should one do if they find themselves in this situation? Play Spider Solitaire? Chit chat with co-workers? Name all the South American countries on Sporcle.com? While those ideas are well and good, there are slightly more productive ways of spending your free time. Here are a few suggestions:

Make sure you’re really done! Of course, in the broader sense, there is no such thing as “done” when it comes to software development projects. Certain tasks might be done – iterations even – but there is always work to be completed. This especially true if you’re working in an Agile environment or adhere to continuous integration and testing. Here’s an excerpt from a recent Gartner report on agile development on the importance of properly defining “done”:

It is important that the definition of done be comprehensive. Because of agile’s focus on finding the simplest solution to the problem, there is a tendency to try to have no design, end user or operation documentation. This should be addressed by including the required documents in the definition of done. Done can include a review by stakeholders such as architects, database administrators and security/compliance officers.

Consider the corner cases. This one is specifically for testers. It can be tempting to complete a set of test cases and consider it a job well done. But as others have pointed out, many serious issues won’t be discovered this way. As Michael Bolton once wrote on our blog:

“Real testing, to me, should be based on investigating how the software allows people to deal with what we call ‘exceptions’ or ‘corner cases.’ That’s what we call them, but if we bothered to look, we’d find out that they were a lot more common than we realize; routine, even.”

Figure out what’s next. This is for the independent contractors out there. This very honest answer comes from the Dice.com thread mentioned earlier. Take a look (emphasis added):

All of my projects in the last two years have been completed on time, ahead of schedule or way ahead of schedule. As a consultant working for a client finishing a project early can end my gig early. Try looking within the company for the next project to manage or at least get involved in some existing project as a facilitator. The bottom line is you want to do the best possible job for your client, even if that means you’re looking for another engagement sooner than you had planned. If you just keep busy you hurt the client and yourself. Keep your mind fully engaged and active. Even if the client doesn’t mind paying to keep you on hold until another project comes along, unless you’re in your cubicle studying for a certification or earning PDUs, you’re going to disadvantage yourself in the end.

What do you do when a project is completed ahead of schedule? Let us know in the comments section below.