Four Reasons Software Testing Will Move Even Further Into the Wild by 2017

apple0132Ever since our inception, uTest and our colleagues within Applause have always been a huge proponent of what we like to call ‘In-the-Wild’ Testing.

Our community is made up of 150,000+ testers in 200 countries around the world, the largest of its kind, and our testers have already stretched the definition of what testing ‘in the wild’ can be, by testing countless customers’ apps on their own devices where they live, work and play.

That ‘play’ part of In-the-Wild testing is primed to take up a much larger slice of testers’ time. While we have already seen a taste of it with emerging technologies gradually being introduced into the mobile app mix, there are four major players primed to go mainstream in just a couple of short years. That means you can expect testers to be spending less time pushing buttons testing on mobile apps in their homes and offices…and more time ‘testing’ by jogging and buying socks. Here’s why.

Continue Reading

Latest Testing in the Pub Podcast: Part II of Software Testing Hiring and Careers

Testing in the PubThe latest Testing in the Pub podcast continues the discussion on what test managers need to look out for when recruiting testers, and what testers need to do when seeking out a new role in the testing industry.

There’s a lot of practical advice in this edition served over pints at the pub — from the perfect resume/CV length (one page is too short!) to a very candid discussion on questions that are pointless when gauging whether someone is the right fit for your testing team.

Continue Reading

STARWEST 2014 Interview: Mind Over Pixels — Quality Starts With the Right Attitude

How important is a tester’s mindset and attitude when it comes to testing?

I sat down with Stephen Vance, one of the STARWEST 2014 speakers, to chat about just that. As an Agile/Lean coach, Stephen is passionate about helping testers understand how to communicate with developers to better integrate into the software development process, and it all starts with the attitude you bring to the table.

Stephen teaches that investing in a “distinctly investigative, exploratory, hypothesis-driven mindset” is key to achieving process improvement at all levels of the software organization. He sees the value in the iterative approach that so well suits the skills testers bring to a collaboration, and encourages testers to be integral in more aspects of a project than just the black-and-white testing phases.

Continue Reading

The Ins and Outs of Writing an Effective Mobile Bug Report (Part II)

Be sure to check out Part I of Daniel Knott’s articleimages on effective mobile bug reports for further context before continuing on.

Here’s the rest of the information you should plan on including in every bug report.

Network Condition and Environment

When filing a mobile bug, it’s important to provide some information about the network condition and the environment in which the bug occurred. This will help to identify the problem more easily and will possibly show some side effects no one has thought of.

  • Bad: “No information” or “Happened on my way to work”
  • Good: “I was connected to a 3G network while I was walking through the city center.”

Language

If your app supports several languages, provide this information in your bug report.

  • Bad: “No information”
  • Good: “I was using the German language version of the app.”

Continue Reading

The Ins and Outs of Writing an Effective Mobile Bug Report (Part I)

If you find a bug within a mobile app, you need to report it in order to get it fixed. Filing mobile bug reports requires some additional information 250x250xbug_report1-250x250.png.pagespeed.ic_.H3eXAv82fDthat the developers need in order to reproduce and fix the bug.

But what is important when filing a mobile bug? What should a bug report look like? Before I answer those two questions, I want to raise another one: “Why even send a bug report?”

Bug reports are very important for the product owner, product manager and the developers. Firstly, a bug report tells the developers and the product owner about issues they were not aware of. Reports also help identify possible new features no one has thought of, and, last but not least, they provide useful information about how a customer may use the software. All of this information can be used to improve the software.

Whenever you find something strange or if something behaves differently or looks weird, don’t hesitate to file a bug report.

Now onto the question of what a bug should look like and what’s important when filing it. It should contain as much information as possible in order to identify, reproduce and fix the bug. Having said that, your report should only include information that’s important to handling the bug, so try to avoid adding any useless information. Additionally, only describe one error per bug. Don’t combine, group or create containers for bugs. It’s likely that not all of the bugs will be fixed at the same time, so refrain from combining or grouping them.

Here’s the information you should plan on including in every bug report.

Continue Reading

Software Testing Budgets on the Rise, Focused on the ‘New IT’

Software testing and QA budgets keep on going up, and shiny, new toys are all of their focus.3C8D67088BE44F318BC592671BC43

According to a ZDNet report based off of a new survey of 1,543 CIOs, conducted and published by Capgemini and HP, “for the first time, most IT testing and QA dollars are now being spent on new stuff, such as social, mobile, analytics, cloud and the Internet of Things, and less of it on simply modernizing and maintaining legacy systems and applications.”

In fact, this “new IT” is making up 52 percent of the testing budgets, up from 41 percent in 2012. And it’s just part of a trend of rising testing budgets in general, hopefully good news for testers — testing now represents 26 percent of total IT budgets on average, up from 18 percent in 2012, and projected to rise to 29 percent by 2017.

Continue Reading

Latest Testing in the Pub Podcast: Software Testing Hiring and Careers

Testing in the PubIf you weren’t aware, software testing and quality assurance engineers are perennially ranked amongst the happiest jobs, and this was no different in 2014.

It’s thus a good time to be in demand as a software tester with all of that love and happiness awaiting you in your next job. With that, uTest contributor Stephen Janaway’s latest Testing in the Pub podcast takes on the topic of hiring testers, and software testing recruitment. You’ll hear about what test managers need to look out for when recruiting testers, and what testers need to do when seeking out a new role in the testing industry.

Continue Reading

Six Ways Testers Can Get in Touch with Their Inner Programmer

This piece was originally posted by our good friends over at SmartBear Software. If you haven’t read it already for some context to this article, check out Part I in this B93X8G / Luminous Keyboardseries, “Don’t Fear the Code: How Basic Coding Can Boost Your Testing Career.”

Michael Larsen will also be joining us for our next Testing the Limits interview, so be sure to stay tuned to the uTest Blog.

Start Small, and Start Local

My first recommendation to anyone who wants to take a bigger step into programming is to “start with the shell.” If you use a PC, you have PowerShell. If you are using Mac or Linux, you have a number of shells to use (I do most of my shell scripting using bash).

The point is, get in and see how you interact with the files and the data on your system that can inform your testing. Accessing files, looking for text patterns, moving things around or performing search and replace operations are things that the shell does exceptionally well.

Learning how to use the various command line options, and “batching commands” together is important. From there, many of the variable, conditional, looping and branching options that more dedicated programming languages use are available in the shell. The biggest benefit to shell programming is that there are many avenues that can be explored, and that a user can do something by many different means. It’s kind of like a Choose Your Own Adventure book!

Continue Reading

Don’t Fear the Code: How Basic Coding Can Boost Your Testing Career

Testers-who-codeThis piece was originally posted by our good friends over at SmartBear Software. Be sure to also check out Part II of this blog, entitled, “Six Ways Testers Can Get In Touch With Their Inner Programmer.”

It’s vital to acknowledge from the outset that I am a reluctant programmer. I know how to program. I can piece together programs in a variety of languages, but it’s not something I consider myself accomplished at doing.

As a software tester, this is a common refrain that I have personally heard many times over the years. It’s so common that there is a stereotype that “people who can program, program. People who can’t program, test the code of programmers.” I disagree with that statement, but having compiled enough personal anecdotes over twenty years, I see why many people would have that view.

I see a traditional dividing line between a “programmer’s mindset” and a “tester’s mindset.” The easiest way that I can describe the difference is, to borrow from Ronald Gross’ book Peak Learning, a  “stringer’s” vs. a “grouper’s” approach to tasks and challenges.  If you are one who likes to work with small components, get them to work together, and “string” them into larger systems that interact, then you have a “programmer’s mindset.” If you look at things from different levels and “group” the items, see where there might be bad connections, and see if those bad connections can be exploited, then you exhibit a “tester’s mindset.” This is a gross oversimplification, but this idea helped me put into word why programming was a challenge for me. It was a “stringer” activity, and I was a “grouper.”

Continue Reading

How We Really Need to Stop ISO 29119

After some real consideration, I have decided to sign the Stop 29119 petition, and along the way also signed the Professional Tester’s Manifesto.stop-29119

The main reason that really resonates with me is that companies, who would normally not use the standard, would be compelled to comply with it just to win business. If there are even a few companies that conform to the standard which are successful, and it doesn’t have to be because they comply with the standard, others will try to follow their path.

At some point, almost every company complies with the standard, and no one knows the reason, only just that the paperwork is unbearable, there isn’t any room for actual testing, and they are afraid to step out of this vicious circle. I do not wish for the testing field to go through this, and that is why I have signed the petition.

But here is where it gets tricky: I think the people who started this opposition to stop the ISO should have thought more about their actions before jumping the gun. One of the few problems I have with this course of opposition is that it gives too much power to the body behind the standard. After some time, all this opposition will turn into just information. People searching for testing-related information may come across all these countless blogs against 29119, and the only thing they will do is research the standard and tell themselves that so many people wrote about it, they should try it, and maybe convince their companies to comply with it.

Even negative advertising is still advertising — it is always of some value to the product being advertised — and gives it some kind of power in the form of public awareness. The proof can be, for example, the ISTQB. As a new tester few years ago, I wanted to get certified (I didn’t) because everybody was talking about it. It was not in a good light, but I still thought it would help me land a good job. There weren’t any other options, so what should a new tester do in this case?

Continue Reading