Testing the Limits With Testing ‘Rock Star’ Michael Larsen — Part I

Michael Larsen is a software tester based out of San Francisco. Including a picture-87071-1360261260decade at Cisco in testing, he’s also has an extremely varied rock star career (quite literally…more on that later) touching upon several industries and technologies including virtual machine software and video game development.

Michael is a member of the Board of Directors for the Association for Software Testing and a founding member of the “Americas” Chapter of “Weekend Testing.” He also blogs at TESTHEAD and can be reached on Twitter at @mkltesthead.

In Part I of our two-part Testing the Limits interview, we talk with Michael on the most rewarding parts of his career, and how most testers are unaware of a major “movement” around them.

uTest: This is your first time on Testing the Limits. Could you tell our testers a little bit about your path into testing?

Michael Larsen: My path to testing was pure serendipity. I initially had plans to become a rock star in my younger years. I sang with several San Francisco Bay Area bands during the mid-to-late 80s and early 90s. Not the most financially stable life, to say the least. While I was trying to keep my head above water, I went to a temp agency and asked if they could help me get a more stable “day job.” They sent me to Cisco Systems in 1991, right at the time that they were gearing up to launch for the stratosphere.

I was assigned to the Release Engineering group to help them with whatever I could, and in the process, I learned how to burn EEPROMs, run network cables, wire up and configure machines, and I became a lab administrator for the group. Since I had developed a god rapport with the team, I was hired full-time and worked as their lab administrator. I came to realize that Release Engineering was the software test team for Cisco, and over the next couple of years, they encouraged me to join their testing team. The rest, as they say, is history.

Continue Reading

Dynamic Testing According to ISO 29119 the Subject of Software Testing Book Excerpt

As testers, you know that software testing is a critical aspect of the software development process. A new book aims to offer a practi804Hasscal understanding of all the most critical software testing topics and their relationships and interdependencies.

The Guide to Advanced Software Testing (second edition) by Anne Mette Hass, published by Artech House, offers a clear overview of software testing, from the definition of testing and the value and purpose of testing, through the complete testing process with all its activities, techniques and documentation, to the softer aspects of people and teams working with testing.

Practitioners will find numerous examples and exercises presented in each chapter to help ensure a complete understanding of the material. The book supports the ISTQB certification and provides a bridge from this to the ISO 29119 software testing standard in terms of extensive mappings between the two.

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

Don’t Say That: Five of the Most Disliked Software Testing Terms

When you say that, you just sound like a jerk.YOU_DONT_SAY

Or maybe at least don’t sound like you completely know what you’re talking about. There are many words and phrases used within the software testing realm that have caused much anguish amongst testers, either because the terms are so vastly overused or are grossly inaccurate in how they are used.

In the past on the uTest Blog, we’ve covered software testing buzzwords, but a tester in our community recently took it a step further in our Forums, coming up with terminology that has caused such unrest beyond the normal annoyances of buzzwords. Here are some of the highlights from the discussion, in the words of our testers:

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

A Separation of Testing and Product: Should Testers ‘Care’?

As a developer, it’s easy to care about that new app you’ve just created. Your new “baby” is taking off, being downloaded by millions of users all over hero_test_102011the world — and it’s your brainchild, one that you’ve poured your blood, sweat and tears into.

But for those testing that app — they may want to do a good job in ensuring the app is successful, but do they actually have an emotional stake in the product itself? The answer to that isn’t as clear, and it’s something that was recently discussed in a great uTest Forums discussion.

According to one of our testers, in one experience at their job, it was pretty easy not to care about the product — it was out of necessity:

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