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 stay tuned for Part II of Michael’s blog on uTest tomorrow, 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

Community Challenge: Best Testing Tutorials Submitted to uTest University

The uTest Community recently uTest-University-300x95issued  a $250 challenge to testers: The top prize would be given to the tester with the best workflow and easiest-to-follow tutorial, as judged by our usability Test Team Lead, Inge.

Some of our top testers were certainly up for the challenge, submitting courses on that week’s topic: Screen recording on Android devices. This area is often a challenge for testers, and our aim was to look for Android experts who can share tools and workflows that make this task a breeze. For example, the tool making up the course should be easy to install, the workflow should be simple, and it should have the ability to export to non-native file formats.

Our expert Inge reviewed all of the submissions, and Gold-rated tester and uTest Forums Moderator Iwona Pekala came out on top with her course on ‘How to Set Up & Use Mobizen Screen Recording.’ Here are some of the recent courses as a result of this contest that we have published to uTest University, including Iwona’s prize-winning entry:

After you’ve checked out these tutorials on how to get started with these Android screen recording tools, be sure to also leave a review for fellow testers on what you liked — and didn’t like — about your experience, over at our Tool Reviews section of the site. And stay tuned for the next community course challenge, where the best tutorials will be published at uTest University!

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

Incorporating User Feedback in Development Leads to Better Software Releases

Note: The following is a guest submission to the uTest Blog from Sanjay Zalavadia.voice_of_user2

By considering the performance of in-development software from the perspective of the end user, QA teams can better address disruptive issues.

Software testing can often be an arduous and stressful process. Even in traditional waterfall production methods, quality assurance teams are typically faced with a months-long period colloquially known as the “death march” as developments near release. During these moments, QA management and teams hunker down and toil away, attempting to address as many remaining coding flaws as possible before the software goes into production. The proliferation of agile development principles has only escalated this trend as QA members are constantly working to identify areas of improvement during the entire course of development.

It’s understandable if QA objectives become a little shortsighted under these conditions and testers place all of their focus on finding bugs and coding errors. However, testing managers need to remain cognizant of the ultimate goal of any successful development process: optimizing the end user experience.

QA performance cannot be measured by the number of bug reports generated, but by the satisfaction of software users following a product’s release. To that end, it is advantageous to consider the viewpoint of the consumer and incorporate user feedback into the development process.

Usability critical to software performance

In a truly agile software development project, user feedback is a critical component of the production cycle, helping to guide tester and developer efforts to improve the performance of the application.

By considering how individuals engage with a piece of software and what problems may commonly occur or will be most disruptive to the user experience, developers and QA teams can better focus on addressing those issues. That fact is that despite the best efforts of software testers, coding flaws are essentially an inevitability. No software is 100 percent perfectly written, but the most successful programs are often those that perform at an optimal level with a bare minimum of usability issues.

In a Software Testing Help post, quality assurance expert Santhosh Kumar Ponnusamy outlined several of the traits characterizing a successful tester. In particular, he highlighted the openness to consider the end user viewpoint and the staunch commitment to improving consumer satisfaction.

Continue Reading

Latest Testing in the Pub Podcast: Views on Testing Communities

Testing in the PubThe latest Testing in the Pub podcast takes advantage of summer — really, the waning days of summer at this point — by having a pint in the beer garden and discussing testing with community leader and organizer of London Tester Gatherings Tony Bruce.

uTester and podcast host Steve Janaway sits down with Tony to discuss, amongst other things, an especially pertinent topic for anyone reading this blog right now as a uTester — the need for testing communities in software development and testing. We agree, Tony!

Be sure to check out the full podcast right here.

Happy Testers Day: How Will You Celebrate?

A sharp-eyed tester in our community has reminded me that it’s Testers Day. No, we didn’t make that up.ladybug-clipart-celebrate

Developers get a lot of the limelight, but it’s about time that testers get their day in the sun, and what better day than September 9 to celebrate that fact!

Wait, so what significance does September 9 have to testers, you say? Well, let’s say we just wouldn’t be using the term “bug” or “debugging” without this date or the influential woman associated with this date.

According to the Computer History Museum, on September 9, 1947, American computer scientist and United States Navy Rear admiral Grace Murray Hopper recorded the first computer bug in history while working on the Harvard Mark II computer. The problem was traced to a moth stuck between a relay in the machine, which Hopper logged in Mark II’s log book with the explanation: “First actual case of bug being found.”

So there you have it, folks. A momentous event deserves celebration and commemoration. How will you celebrate Testers Day? With a cake? By finding a bug in Grace Hopper’s honor? Be sure to let us know in the Comments below. In the meantime, be sure to give your colleague a high-five and wish them a Happy Testers Day.

ISO 29119 Draws the Ire of Testers in uTest Community

Earlier in the week, you may remember that 30-year IT vet James Christie posted his thoughts on why the ISO-Logonew testing standard released by ISO (International Organization for Standardization) is bad for the testing profession.

The post kind of blew up on Twitter, with testers from within uTest and the greater testing community immersed in a flurry of tweets and retweets to their followers. Michael Bolton even called it a “must-read.”

So why are so many people up in arms about this standard and tagging their Twitter posts with the harsh #Stop2919 hashtag? Well, you can be the judge and read the initial post from James to decide, but some of our testers took to the uTest Forums after the blog post went live to explain what ticked them off about it:

“Too bad we can’t impeach ISO 9000 [another standard from ISO]. I will not work for a company that requires ISO. I’m a process guy that loves to have a defined process that works for everything I’m doing. I don’t like process for the sake of process and that is what ISO feels like when implemented.”

“I left my last company because the industry they worked in was so heavily regulated — all we did was process, process, process. We never did any real work.”

“To say that you MUST test a certain way, no matter whether it is a tiny phone app or a massive mainframe control suite, is, well, really nothing short of insane.”

Testers in the outside world, we want to know: Is ISO 29119 a danger to the testing profession as a whole? What would be your reaction to someone that wants you to sign the petition to #STOP29119? Are standards (and certifications from organizations such as ISTQB) bad for testing in general, anyways?

If you’ve got strong feelings against (or for) 29119, we want to hear from you in the comments below.

ISO 29119: Why it is Dangerous to the Software Testing Community

stop-29119Two weeks ago, I gave a talk at CAST 2014 (the conference of the Association for Software Testing) in New York, titled “Standards: Promoting quality or restricting competition?”

It was mainly about the new ISO 29119 software testing standard (according to ISO, “an internationally agreed set of standards for software testing that can be used within any software development life cycle or organization”), though I also wove in arguments about ISTQB certification.

My argument was based on an economic analysis of how ISO (the International Organization for Standardization) has gone about developing and promoting the standard. ISO’s behavior is consistent with the economic concept of rent seeking. This is where factions use power and influence to acquire wealth by taking it from others — rigging the market — rather than by creating new wealth.

I argued that ISO has not achieved consensus, or has even attempted to gain consensus, from the whole testing profession. Those who disagree with the need for ISO 29119 and its underlying approach have been ignored. The opponents have been defined as irrelevant.

If ISO 29119 were expanding the market, and if it merely provided another alternative — a fresh option for testers, their employers and the buyers of testing services — then there could be little objection to it. However, it is being pushed as the responsible, professional way to test — it is an ISO standard, and therefore, by implication, the only responsible and professional way.

What is Wrong With ISO 29119?

Well, it embodies a dated, flawed and discredited approach to testing. It requires a commitment to heavy, advanced documentation. In practice, this documentation effort is largely wasted and serves as a distraction from useful preparation for testing.

Such an approach blithely ignores developments in both testing and management thinking over the last couple of decades. ISO 29119 attempts to update a mid-20th century worldview by smothering it in a veneer of 21st century terminology. It pays lip service to iteration, context and Agile, but the beast beneath is unchanged.

The danger is that buyers and lawyers will insist on compliance as a contractual requirement. Companies that would otherwise have ignored the standard will feel compelled to comply in order to win business. If the contract requires compliance, then the whole development process could be shaped by a damaging testing standard. ISO 29119 could affect anyone involved in software development, and not just testers.

Continue Reading

Three Things Testers Can Learn From Wine Experts

When I’m not testing, one of my favorite hobbies is alcohol. Wait…that didn’t come out right. What I meant was my hobby is learning about winSommelier_e_Tastevine, beer and sprits. Yeah, that sounds better.

While I do love a cold beer in the summer, a single-malt scotch when I’m feeling sophisticated, or an 1855 classified Bordeaux on special occasions, I think I spend more time studying booze than I do drinking it. I really enjoy learning about the various Appellation d’origine contrôlée (AOCs) in France, and the differences between a Pinot Noir from California and one from Burgundy. I sound pretty smart, huh?

As any cultured, refined wine connoisseur such as myself knows, the true masters of the bottle are called sommeliers. These fine folks are highly trained adult beverage experts who often work in fancy, fine-dining restaurants, setting the wine list, caring for the cellar and working with customers to help them select the perfect wine.

So what could a tester possibly learn from a someone obsessed with booze? Good question! I have three answers.

Be passionate

I have yet to find people who are more passionate about what they do than Master Sommeliers. Need proof? Watch the movie Somm (available on Netflix). The tremendous amount of dedication and effort these people pour (wink, wink) into their work is simply astounding.

A sommelier must be constantly learning and exploring. Each year, a new vintage of every wine is created. That means thousands of new wines are added to the multitude that already exist…and a sommelier is expected to be familiar with with all of them. And you thought the IT world was constantly changing!

There will always be a new product to test, a new approach to learn, a new idea to debate. Testers who are passionate about testing are excited about these new developments as they are opportunities to grow and improve.

Continue Reading