Skip to content

uTest
Syndicate content
Updated: 4 hours 34 min ago

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

16 hours 51 min ago

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.

uTest: You also come from a varied tech career, working in areas including video game development and virtual machine software. Outside of testing, what has been the most rewarding “other” part of your career?

ML: I think having had the opportunity to work in a variety of industries and work on software teams that were wildly varied. I’ve had both positive and negative experiences that taught me a great deal about how to work with different segments of the software world. I’ve worn several hats over the years, including on-again, off-again stints doing technical support, training, systems and network administration, and even some programming projects I was responsible for delivering.

All of them were memorable, but if I had to pick the one unusual standout that will always bring a smile to my face, it was being asked to record the guide vocal for the Doobie Brothers song “China Grove,” which appeared on Karaoke Revolution, Volume 3 in 2004.

uTest: You are also a prolific blogger and podcast contributor. Why did you get into blogging and why is it an effective medium for getting across to testers?

ML: I started blogging before blogging was really a thing, depending on who you talk to. Back in the late 90s, as part of my personal website, I did a number of snowboard competition chronicles for several years called “The Geezer X Chronicles.” Each entry was a recap of the event, my take on my performance (or lack thereof) and interactions with a variety of the characters from the South Lake Tahoe area. Though I didn’t realize at the time, I was actively blogging for those years.

In 2010, I decided that I had reached a point where I felt like I was on autopilot. I didn’t feel like I was learning or progressing, and it was having an effect on my day-to-day work. I had many areas of my life that I was passionate about (being a musician, being a competitive snowboarder, being a Boy Scout leader), but being a software tester was just “the day job that I did so I could do all the other things I loved.”

I decided I wanted to have that same sense of passion about my testing career, and I figured if my writing about snowboarding had connected me with such an amazing community, maybe writing about software testing would help me do the same. It has indeed done that — much more than I ever imagined it would. It also rekindled a passion and a joy for software testing that I had not felt in several years.

uTest: And your own blog is called ‘TESTHEAD.’ That sounds like a very scary John Carpenter movie.

ML: I’m happy it’s memorable! The term “test head” was something we used when I was at Cisco. The main hardware device in the middle that we’d do all the damage to was called the test head. I’ve always liked the idea of trying to be adaptable and letting myself be open to as many experiences and methods of testing as possible, even if the process wasn’t always comfortable. Because of that, I decided that TESTHEAD would be the best name for the blog.

uTest: As you know, James Bach offers free “coaching” to testers over Skype. You’re a founding member of the Americas chapter of “Weekend Testing,” learning sessions for testers in the Western Hemisphere. Does Weekend Testing run off of a similar concept?

ML: Weekend Testing is a real-time chat session with a number of software testers, so it’s more of a group interaction. James’ Skype coaching is one-on-one. It has some similarities. We approach a testing challenge, set up a mission and charters, and then we review our testing efforts and things we learn along the way — but we emphasize a learning objective up front so that multiple people can participate. We also time-box the sessions to two hours, whereas James will go as long as he and the person he is working with has energy to continue.

uTest: In the video interview you gave with us, you mentioned a key problem in testing is the de-emphasis of critical thinking as a whole in the industry. Are endeavors such as Weekend Testing more of a hard sell than they should be because of testers’ unwillingness to “grow?”

ML: I think we have been fortunate in that those that want to find us (Weekend Testing) do find us and enjoy the interactions they have. Having said that, I do think that there are a lot of software testers currently working in the industry that don’t even realize that there is a movement that is looking to develop and encourage practitioners to become “sapient testers” (to borrow a phrase from James Bach).

When I talk with testers that do understand the value of critical thinking, and that are actively engaged in trying to become better at their respective craft, I reluctantly realize that the community that actively strives to learn and improve is a very small percentage of the total number of software testing practitioners. I would love to see those numbers increase, of course.

Stay tuned for Part II of Michael Larsen’s Testing the Limits interview next Monday on the uTest Blog. Amongst other discussion topics, Michael will share why he believes “silence” is powerful on testing teams.

Categories: Companies

Mad Scientists Welcome at the STARWEST 2014 Test Lab

Fri, 10/17/2014 - 19:30

Testing is dull, boring, and repetitive.

Ever heard anyone say that? Well at STARWEST 2014, the theme is Breaking Software (in the spirit of Breaking Bad), and this crowd is anything but dull! Creativity abounds at this conference, from the whimsical (yet impactful) session topics to the geek-chic booth themes (I do so love a good Star Wars parody!) to the on-site Test Lab run by what at first glance appears to be a crew of mad scientists. Boring or repetitive? I don’t think so!

Because the Test Lab was such a fun space, I interviewed one of the mad scientist/test lab rats, Paul Carvalho, to get the lowdown on what STARWEST 2014 attendees have been up to. Check out the video below for a tour of the STARWEST Test Lab, complete with singing computers, noisy chickens, talking clocks, and more!

You can learn more about Paul Carvalho – an IT industry veteran of more than 25 years – at STAQS.com (Software Testing and Quality) where he is the principal consultant. You can also find him on LinkedIn here.

So what do you think about the STARWEST Test Lab? What would you try to break first? Let us know in the Comments below, and check out all of our coverage from STARWEST 2014.

Categories: Companies

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

Fri, 10/17/2014 - 17:10

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.

Stephen’s STARWEST 2014 session was called “Building Quality In: Adopting the Tester’s Mindset.” If you weren’t able to attend, check out my interview with him below to hear what else he had to say!

You can also read more about Stephen Vance on his website and connect with him on LinkedIn here.

What are some ways you think testers can use a hypothesis-driven, investigative approach to inject greater value into the software development life cycle? Feel free to sound off in the Comments below.

Categories: Companies

Top Tweets from STARWEST 2014

Thu, 10/16/2014 - 23:34

If you haven’t stopped by and seen us at the ol’ uTest booth, now’s the time! CM’s own Sue Brown is at the show along with the Applause crew.

But if you’re not there, have no fear, as Sue will be reporting back with some video interviews with testers and her own thoughts on the show here on the uTest Blog. In the meantime, we have selected some of our favorite tweets from STARWEST as the tail-end of the show is in full swing:

OH at #StarWest: "How do we do automation?" People: automation—a tool—isn't something you DO; it's something you USE. #testing #agile

— Michael Bolton (@michaelbolton) October 16, 2014

If you're not free to think, or learn, and adapt while you test, it's not exploration. - @jbtestpilot #starwest

— Ben Simo (@QualityFrog) October 14, 2014

The chickens are getting restless in @TheTestLab as #starwest winds down in the final hours.. pic.twitter.com/8N37iQMzsk

— Paul Carvalho (@can_test) October 16, 2014

If your security testing is focused on the things that you secured, you’re going to miss all the things you didn’t think about. #starwest

— Kwality Rules (@KwalityRules) October 16, 2014

#STARWEST keynote @cheekytester asked the audience "who struggles with Test environments?" Almost every hand up. We need to fix this.

— Paul Carvalho (@can_test) October 15, 2014

Room set for #starwest Going to be huge audience. 3 screens needed ! pic.twitter.com/8HM0rAvWGY

— Alison Wade (@awadesqe) October 15, 2014

"Test the software with the minimum number of tests"… hmmm let's ignore that request and start testing #starwest

— Andy Glover (@cartoontester) October 14, 2014

Fedoras, beers, #APIs, #SoftwareTesting, you name it. #STARWEST always impresses, and this year is no different. pic.twitter.com/t5Y5Vuw5OP

— Ready! API (@ready_api) October 16, 2014

Computer System Innovation crew likes glasses and mustaches #STARWEST #stachecam pic.twitter.com/fGIGy1eLbT

— Yvonne Johns (@yvjohns) October 16, 2014

#starwest Ben Simo's presentation on http://t.co/6APgwb9wvC: part tester, part hacker, all awesome

— Daniel Hill (@RenjyaaDan) October 16, 2014

If your ex can answer the security question- it's a bad question @QualityFrog #healthcare #userexperience #starwest

— StickyMinds (@StickyMinds) October 16, 2014

Agile is about the commitment of the full team, not individual teams by @bobgalen #StarWest #HPsoftwarealm

— silvia siqueira (@silvia_ITM) October 16, 2014

#agile «@jefferyepayne Attack of the killer flip charts. Help! I only asked for 1 but they are swarming #starwest pic.twitter.com/aTLGVBFfd7»

— erik petersen (@erik_petersen) October 14, 2014

http://t.co/a6leVIE4U4 empower All developers to Test for success, test early test continuously #StarWest #HPsoftwarealm #blizzard

— silvia siqueira (@silvia_ITM) October 16, 2014

Never substitute tools for communication. @Jeanne_Schmidt #starwest

— Kwality Rules (@KwalityRules) October 15, 2014

If you are not having fun testing something is wrong @cheekytester #starwest

— Gitte Ottosen (@Godtesen) October 15, 2014

 

To see what other events are upcoming in the software testing world, make sure to check out our brand-spankin’ new Events Calendar.

Categories: Companies

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

Wed, 10/15/2014 - 19:00

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.

The full version of the book is available for £75 (USD $119) from Artech House, but testers will be able to receive an exclusive 20% discount off that list price, plus free shipping, by using promo code EUROSTAR14 at checkout, valid through December 31, 2014.

In the meantime, you can check out our exclusive chapter excerpt right here. This specific sample provided by Artech House clocks in at a generous 30 pages, and its subject matter should be quite familiar to many testers, covering the recent, controversial ISO 29119 testing standard and its associated dynamic testing process.

Categories: Companies

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

Wed, 10/15/2014 - 15:30

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.”

Test Data

This information can already be provided in the steps taken to reproduce, but test data you need to reproduce the bug may be more complex, so it makes sense to provide this information in a separate section. Provide SQL dumps, scripts or the exact data you entered in the input fields.

  • Bad: “No information”
  • Good: “Find the attached SQL script to put the database in the defined state” or “Enter ‘Mobile Testing’ into the search input field.”

Severity

Every bug you find needs a severity level. Either your defect management tool will offer you some categories or you have to define them with your team. It is important to give a bug a severity level as it will allow the team to prioritize their bug fixing time so that critical and high priority bugs will be fixed first. If this information is not provided, it takes much more time to find the right bugs that need to be fixed before the release. The default severities are: Critical, High, Medium and Low.

  • Bad: “No information”
  • Good: “Critical” or “Medium”

Bug Category

Besides the severity level, the bug category is also a very useful piece of information. The product owner or the developer can filter by category to get an overview of the current status of bugs per category. For example, if there are lots of UX bugs, this may be an indicator of poor UI and UX or a missing design expert in the team, meaning that the app needs design improvements.

  • Bad: “No information”
  • Good: “Functionality” or “UX” or “Performance”

Screenshot or Video

Whenever you find a bug, try to create screenshots or a video to provide the developer with more information. When providing a screenshot, use an image editing tool to mark the bug in the screenshot (Jing, for instance). A video is also a great way to describe a bug you’ve come across. It is also very useful to give the screenshot or the video a good name or description.

  • Bad: “No screenshots or videos attached” or “Screenshot1.png”
  • Good: “01_InsertSearchTerm.png, 02_SearchResultPageWithError.png”

Log Files

If your app crashes or freezes, connect the device to your computer and read out the log files. In most cases, a stack trace will be shown with a description of the error. This kind of information is extremely useful for developers as they know right away in which class the bug or the error has occurred.

  • Bad: “No information provided when the app crashed.”
  • Good: “Provide the full stack trace in the bug report” or “Attached the log file to the report.”

Tester Who Found the Bug

Write down your name or the name of the tester who found the bug. Developers or product owners may have some questions about the reported bug and they would of course like to directly get in touch with the tester who found the issue. In most cases, this is automatically done by the defect management system where each user has his or her own account. If not, make sure you add your e-mail address and/or phone number.

  • Bad: “No information”
  • Good: “Daniel Knott, daniel@adventuresinqa.com”

Other Things to Remember When Writing Bug Reports

As you have seen, there is a lot of information that should be included in a bug report. There are three other points you should keep in mind when writing them.

Don’t get personal. When filing a bug report, describe the software misbehavior rather than the developer’s mindset or the quality of his or her work. Don’t use offensive or emotionally charged words as those kinds of bugs will be ignored by the developer…and you’ll end up with bad blood within the team.

It’s not you. It’s not your fault that the bug occurred. It is the software that’s broken and you and your colleagues need to fix it.

Keep it simple. Try to write your bug report in such a way that someone with no idea about the project or the app is able to understand the problem. If the bug report is that easy, every developer within the team will be able to fix it and non-technical colleagues can understand the problem and will value your work.

If you want to read more about mobile testing, my book Hands-On Mobile App Testing covers this in depth.

Daniel Knott has been in software development and testing since 2008, working for companies including IBM, Accenture, XING and AOE. He is currently Daniel Knotta Software Test Manager at AOE GmbH where he is responsible for test management and automation in mobile and Web projects. He is also a frequent speaker at various Agile conferences, and has just released his book, Hands-On Mobile App Testing. You can find him over at his blog or on Twitter @dnlkntt.

Categories: Companies

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

Tue, 10/14/2014 - 19:05

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.

Bug ID

A bug must have an unique identifier like a number or a combination of characters or numbers. If you’re using a defect management tool, the tool will handle the bug IDs for you. If not, think about a unique ID system for your project.

  • Bad: 123 is a unique ID, but you might have several projects where the ID is the same.
  • Good: AppXYZ-123 is good because you’re combining an ID with a project abbreviation and a number.

Description

Create a short but meaningful description in order to provide the developer with a quick overview of what went wrong without going into detail. You should, for example, include error codes or the part of the application where the bug occurred.

  • Bad: “The app crashed,” “White page,” “Saw an error,” “Bug”
  • Good: “Error Code 542 on detail message view,” “Timeout, when sending a search request.”

Steps to Reproduce

This is one of the most important points. Provide the exact steps together with the input data on how to reproduce the bug. If you are able to provide this kind of information, the bug will be very easy to fix in most cases.

  • Bad: “I tried to execute a search.”
  • Good: “Start the app and enter ‘Mobile Testing’ into the search input field. Press the search button and you’ll see the error code 783 on the search result page header.”

Expected Result

In this section, you should describe what you expected to happen when the bug occurred.

  • Bad: “It should work,” “I didn’t expect it to crash.”
  • Good: “I expected to see a search results page with a scrollable list of 20 entries.”

Actual Result

What happened when the bug occurred? Write down the actual result — what went wrong or the error that was returned.

  • Bad: “It just won’t work.”
  • Good: “The search results page was empty” or “I got the error code 567 on the search result page.”

Workaround

If you’ve found a way to continue using the app by avoiding the bug, explain your steps. Those steps are important to know since the workaround could cause other problems or indicate a way in which the app should not be used. On the other hand, a workaround can be very useful for the customer support team in order to help customers solve the current problem until the bug gets fixed.

  • Bad: “I found a workaround.”
  • Good: “If you put the device into landscape mode, the search button is enabled and the user can search again.”

Reproducible

If you found a reproducible bug, that’s fine, but does it occur every time? If it happens every time, that’s great, as this should be an easy fix for the developer. But if the bug only occurs 20 percent of the time for instance, it is much harder to find a solution for that. Make sure you provide this information, however, as it is very useful for the developer and will prevent the bug from being closed with the comment “can’t be reproduced.”

  • Bad: “Sometimes”
  • Good: “The bug occurs 2 out of 10 times.”

Operating System, Mobile Platform and Mobile Device

The same applies to the operating system, the mobile platform and the mobile device. Write down the operating system, mobile platform and device on which the bug occurred.

  • Bad: “On Android” or “On iOS”
  • Good: “Android, Version 4.1.2 Google Nexus 4″ or “iOS, Version 6.1 iPhone 4S”

Mobile Device-Specific Information

Mobile devices have lots of interfaces and sensors that could have an impact on your app. The battery could also affect the app you’re testing. Write down all of this information in your bug report.

  • Bad: “No information”
  • Good: “GPS sensor activated, changed the orientation from landscape to portrait mode” or “Used the device in a sunny place” or “Battery state was 15%” or “Battery state was 100%.”

Browser Version

If your app is a mobile web app and you found an issue, it’s very important to note down the browser version where you found the bug, as it may only occur in certain versions.

  • Bad: “Google Chrome” or “Mozilla Firefox”
  • Good: “Google Chrome Version 45.35626″ or “Mozilla Firefox 27.6.”

Software Build Version

Another really useful piece of information is the current build version of the app where the bug occurred. Maybe you found the issue in version 1.2, but there is already a newer version available where the bug has been fixed. This will prevent the developer from wasting time by trying to reproduce a bug that’s already been fixed.

  • Bad: “No information”
  • Good: “App build version 1.2.3″

Check out Part II of this article right here.

Daniel Knott has been in software development and testing since 2008, working for companies including IBM, Accenture, XING and AOE. He is currently Daniel Knotta Software Test Manager at AOE GmbH where he is responsible for test management and automation in mobile and Web projects. He is also a frequent speaker at various Agile conferences, and has just released his book, Hands-On Mobile App Testing. You can find him over at his blog or on Twitter @dnlkntt.

Categories: Companies

My Weekend with the Goat Simulator App

Mon, 10/13/2014 - 21:18

We often talk about the newest and hottest mobile apps at the uTest Community Management desk. Recently, I was curious if I was missing out on any top apps that I didn’t already have on my Samsung Galaxy S4. I am surrounded by a sea of iPhone users so I am used to not getting in on the latest apps until (much, much) later. Of course, I have the requisite social media, weather, and news apps installed but what is really hot for the Android app market these days? I checked out the top paid apps in the Google Play store and, to my surprise, the one odd app that stuck out is the Goat Simulator at #9 on the Top 10 list. Screenshot_2014-10-10-19-10-05

Per the app’s description: “Gameplay-wise, Goat Simulator is all about causing as much destruction as you possibly can as a goat. It has been compared to an old-school skating game, except instead of being a skater, you’re a goat, and instead of doing tricks, you wreck stuff. When it comes to goats, not even the sky is the limit, as you can probably just bug through it and crash the game. Disclaimer: Goat Simulator is a completely stupid game and, to be honest, you should probably spend your money on something else, such as a hula hoop, a pile of bricks, or maybe pool your money together with your friends and buy a real goat.”

I appreciate the developer’s humor, especially since they list the top key feature as “you can be a goat.” I can’t say I’ve always dreamed of being a goat, but here was my shot. Ryan, our beloved blog and forums guru, practically ordered me to buy the app (cost: $4.99), play it over the weekend, and report back on Monday. A check of the app on Applause Analytics showed a satisfaction score of 77 and noted that it is the app’s strongest attribute. Okay, game on. Goat-sim-screenshot

The Goat Simulator app played as expected. You are a first person goat whose job is to run people down, kick objects across long distances, and generally be a menace to society. (If we’ve ever met, then you know I am capable of such things – no app needed.) I was waiting to encounter the supposed millions of bugs that the developer mentions but, sadly, I did not. I stopped playing the game on Saturday when I realized I had given one too many hours of my life to being a virtual goat and that it was time to take a shower and rejoin civilization.

However, I was still wondering: What odd, strange, or unique apps do you have installed on your phone? And what’s the oddest app that you’ve paid for? Let’s chat about it in the forums.

Happy goating!

Categories: Companies

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

Mon, 10/13/2014 - 15:30

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.

What testing teams are doing with this extra budget is a whole other story, however, so it remains to be seen whether more budget for testing teams is a good thing, and will provide a much-needed boost to teams strapped by a lack of time and misdirected efforts.

Do these trends look familiar within your own organization? We’d love to hear from you in the Comments below.

Categories: Companies

uTest to Provide Coverage Next Week from STARWEST in Anaheim

Fri, 10/10/2014 - 20:05

star_west_logo-150x150Headed to STARWEST in Anaheim, CA, next week? uTest will be there for the final three days of the nearly week-long esteemed testing event of the Fall. We’ll also be live tweeting and interviewing conference attendees all week.

In a clever spin on the hit TV show Breaking Bad, the 2014 theme is Breaking Software. The conference is billed as the premier event for software testers and quality assurance professionals—covering all your testing needs with 100+ learning and networking opportunities including: keynotes featuring recognized thought-leaders, in-depth half- and full-day tutorials, and conference sessions covering major testing issues and solutions.

Some of this year’s keynotes include The Power of an Individual Tester: The HealthCare.gov Experience, by Ben Simo of eBay. If you weren’t there for Ben Simo’s similar session at CAST 2014 in NYC in August, you’re in for a treat — this was a cant-miss keynote.

So if you’re wandering the halls of STARWEST next week in between all of these great keynotes and sessions, be sure to stop by and see us at the Applause booth (#5) on Wednesday and Thursday, as representatives from both uTest and Applause will be in attendance! You may even get some nice uTest and/or Applause goodies, too.

For those unable to make it in person, have no fear, as we will be video interviewing attendees on the spot here on the uTest Blog, and you’ll be able to follow along @uTest on Twitter for all of the coverage live from Cali.

Categories: Companies

‘Tis the Season for uTest Community Contests

Thu, 10/09/2014 - 22:18

If you haven’t noticed, we’ve gone a little crazy over tester recognition at uTest lately. We closed out the summer by crowning the victors of our epic Bug Battle and Ideal Tool contests.  Then we made a nice new home for our Testers of the Quarter and our uTesters of the Year in our Hall of Famelight-bulbs

To keep the excitement going, we thought we’d bring some cash and prizes to help highlight two other areas of software testing: your testing workspace and your favorite testing tools. We have two contests running in the uTest Forums right now:

Your Testing Workspace

What does your sanctuary of testing bliss say about you? This month’s uTest Community contest asks you to take a step back and examine this question – and take a picture of this testing workspace in the process!

uTesters will be able to submit their best photos in one of two categories: Best Testing Workspace or Best Desktop Trinket. For the first category, maybe your workspace has a wickedly cool setup or there’s just something unique about it. For your best desktop trinket, perhaps there’s one item that was a gift from a dev that will just make everyone laugh. Whatever these images are, we wanna see ‘em! One tester will also be selected at random out of all entrants for a uTest t-shirt as well, so don’t be shy about participating!

For more information, read the forums thread (login required). 

Chrome/Firefox Testing Add-on Tutorial

Browser add-ons are handy tools to use when testing, but it’s not always clear as to the best ways to set them up for testing. We are running a quick contest with a $200 cash prize for the best workflow and easiest-to-follow tutorial for your favorite browser add-on. Check out our Tool Reviews library for Chrome tools and for Firefox tools, but you are not limited to just these specific examples.

For more information, read the forums thread (login required).

So what are you waiting for? Sign up for a uTest account (if you don’t already have one) and get those ideas flowing for your submissions.

Categories: Companies

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

Thu, 10/09/2014 - 20:15

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:

  • Manual testing: It’s one of the most hated terms in the industry. A manual tester, manual project manager and a manual network admin walk into a bar…
  • Glitch: A bug is not a glitch. A glitch is something transient, undefinable and suddenly appears. I search for bugs — repeatable faults in the code that can be triggered following a certain set of actions.
  • Manual testing vs. Automated testing: As soon as this term is raised, it becomes a kind of a war. This is a never-ending debate.
  • Validate vs. Verify: I will sometimes say verify when I should say validate just to annoy testers. I think the value of these terms does not outweigh the pain and suffering I get trying to get people to use the right term, so I quit worrying about it.
  • Test vs. Check: Honestly, does anyone outside the test community care? Testers are constantly getting into discussions about how these terms should be used. That’s a waste of my time. Every engineering person I’ve ever talked to immediately knows what regression testing is. No real need to explain it.

What would you add to the list? We’d love to hear in the Comments.

Categories: Companies

iOS Log Capture Tool Showdown: iPhone Configuration Utility vs. iTools

Wed, 10/08/2014 - 20:07

When capturing system information critical for bug reports and reproducing bugs in action, iPhone Configuration Utility is often used as the default tool for capturing iOS logs. But is the standaiTools_logo_Realrd the best option out there for testers? VSiphone_config_real1

In this week’s Testing Tool Showdown, we’ve pitted the iPhone Configuration Utility against iTools to see which has garnered more support. The former is by far the standard testers within the uTest Community use for log capture, and has earned a five-star average review in our Tool Reviews. Here’s some of what our users have to say:

  • IPCU is handy for installing apps that iTunes has issues with. The console log alone is also a quick and easy way to got the logs you need.
  • I have used this tool many times when needing to grab a console log and overall I have found it works well
  • Lightweight and useful. Hard to beat.

On the other side of the ring in this showdown is iTools. This one has the distinction of being used primarily by our testers for screen recording and screenshots, but there are log capture capabilities that are too part of its arsenal. According to our testers both in our Forums and in the Tool Reviews:

  • What makes me use this tool? When I updated my iPad Mini 2 to iOS 8, I just could not see logs on iPhone Configuration Utility anymore. Very good and useful tool.
  • I use this mainly for recording desktop, but also to get the logs, which are not always synchronized with iTunes!

So while you’ll see most documentation out there referring to iPhone Configuration Utility as the de facto log capture tool for iPhone (heck, we even have a course on the tool at uTest University), there are alternatives such as iTools that are also useful in log capture.

Who would win in this testing tool showdown? Are there other swiss-army/catch-all tools you prefer to use versus Config Utility that get the job done along with many other vital testing functions? Let us know in the comments below.

 

Categories: Companies

A Bittersweet Transition from the uTest Community

Tue, 10/07/2014 - 19:10

It’s with a heavy heart that I announce that after 5.5+ years of dedication to the uTest Community, I will be transitioning to a different role within the comPeter-Shihpany.

This move comes as an opportunistic one, as I now will be tasked with ways to help prospective customers understand the value that the uTest Community brings to their software lifecycle. And if I succeed in this new role, greater opportunities will be unlocked for you.

So what does this mean for you? Quite frankly, not much, besides the fact that I will miss the frequent interactions with many of our top testers. The CM Team is still the same CM Team that you love and is there to help you succeed. Additionally, the vision that we’ve set out for the uTest brand will live on and continue to expand, which includes launching new programs that push learning and mentoring, empowering our top testers to influence the greater community, and working with our engineering team to deliver platform features that enable you to succeed on paid projects.

Finally, since I won’t be going anywhere new, I’ll still be indirectly involved with the CM team and ongoing programs. I will also be poking my head in to the uTest Forums from time to time and look forward to hearing about major milestones and achievements from our most influential testers!

Categories: Companies

Tickets for UK’s TestBash 2015 Now on Sale

Mon, 10/06/2014 - 19:57

3-TestBash-Banners-2015-10Tickets for one of the biggest testing events of the year in the United Kingdom, TestBash, are now on sale for the 2015 edition.

According to host of the event Ministry of Testing, “TestBash is the leading software testing conference within the UK. We invite testers who we believe are the best and most interesting people to talk  all sorts of crazy things related to software testing. Our mission is to inspire a generation of testers to learn more about their craft and create professional friendships that create a long lasting support network.

Some of the sessions for TestBash 2015, taking place March 26-27, include:

  • Why I Lost My Job As a Test Manager and What I Learnt As a Result – Stephen Janaway
  • The Rapid Software Testing Guide to What You Meant To Say – Michael Bolton
  • What’s In a Name? Experimenting With Testing Job Titles – Martin Hynie
  • Automation in Testing – Richard Bradshaw
  • The Art of Asking Questions – Karen Johnson
  • Bug Detection – Iain McCowatt

2015 is also the first to feature a workshop day before the day of speakers including nine hands-on sessions ranging from 2-4 hours a piece. You can purchase tickets for the UK event now, and find a complete list of currently confirmed sessions, right here. With a conference name like that and a who’s who of testing personalities, the 2015 edition is bound to be a great and worthwhile time!

Be sure to also check out all of the software testing events on tap for the months ahead at our uTest Events Calendar.

Categories: Companies

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

Fri, 10/03/2014 - 17:30

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.

Part I of the two-part podcast is available right here for download and streaming, and is also available on YouTube and iTunes. Be sure to check out the entire back catalog of the series as well, and Stephen’s recent interview with uTest.

Categories: Companies

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

Thu, 10/02/2014 - 20:40

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:

At the company I worked for, only 2 or 3 people actually knew we were working for Apple. All we knew and cared about was our assigned tasks. We didn’t know about the underlying product and it was important that we didn’t care. If we cared enough, we could probably investigate, ask questions, do research and figure out who the customer was. It would be terrible for our company if our customer’s identity was exposed so we were INSTRUCTED to not care about the customer. All we needed to do was ensure our product matched our customer’s specifications.

Another tester drew a parallel to illustrate how easy it is to separate feelings from doing your job — how you don’t need passion for the “subject” to be successful:

Do you think that surgeons are empathetic with their patients? Most of the top-notch surgeons have something that is called compassion fatigue, they are simply overloaded with patients that need care and most of them simply stop creating any emotional attachment to the patient. Yet they do a very good job saving lives, don’t they?

But don’t testers still have some ultimate stake in the success of the product, therefore making it tough to not have some sort of emotional attachment to the creative or development process?:

A surgeon may not emotionally care that the person they are operating on doesn’t make it. They will care if everyone they operate on doesn’t make it. They would be out of a job if they weren’t successful. They care about what other surgeons think of their skill. That example would be more geared toward the developer role. Testers don’t actually create. The guy who monitors the surgeon’s performance would probably care and would be closer to the tester role. It would reflect negatively on the monitor if their surgeon was not doing a good job.

It certainly would make sense that testers wouldn’t have an emotional attachment to the product given that it is not their “baby.” It could also be one of the reasons behind the pervasive industry problem that there aren’t enough testers willing to challenge themselves as thinkers, or the status quo. For example, why would a tester care enough to grow in their craft if they’re working on someone else’s creation versus creating themselves?

But this is all speculation designed to spark worthy discussion, as with our original Forums discussion. We leave it to you, the testing audience – should testers care about the product that they are testing? Should they have an emotional stake in something that isn’t theirs? We’d love to hear your thoughts in the Comments below.

Categories: Companies

uTest Announces the Grand Prize Winner of the Ideal Tool Contest

Wed, 10/01/2014 - 16:59

we-have-a-winnerLast month, we asked the uTest Community to submit their ideas for the ideal testing tool – one with a unique feature or that combines some favorite features and functions into one tool. The Ideal Tool Contest was a competition for testers to design a testing tool targeted at the manual functional tester. We also offered one of the largest prize packages in recent history, with over $1,000 in prize money as well as uTest t-shirts.

Voting for the Ideal Tool Contest just wrapped up yesterday and we are happy to announce the Grand Prize winner and the four runners-up. Be sure to leave a comment to congratulate these folks! You can also take a moment to click through and read each of the winning entries.

Grand Prize Winner

The 30-second Recorder by Amir Horesh

A testing tool helping the tester to reproduce a recent defect found by recording his activities in the last 30 seconds, and producing his activities in an activity log as well. This tool will save all of the user’s activities (clicks on screen, typing, etc.) in a log file and will record the screen itself and the user’s activities for the last 30 seconds (always keeps 30 secs of recording), helping the tester to provide clear steps to reproduce the defect for the developer. Read the complete entry (PDF).

Runners-up

The Swiss Knife QA Tool by Anand Reddy Pesaladinne

A one-stop solution for any cross-mobile OS like Android, iOS, and Windows Phone devices. Swiss Knife QA tool is a mobile application analyzer tool which helps you to connect Android, iOS, and Windows Phone device’s using USB cable to a Windows or Mac machine and helps you to capture log files, take screenshots, and record a screencast of the screen. Read the complete entry (PDF).

The Complete Mobile Bug Report by Georgios Boletis

A complete mobile bug report (GUI, functional, or technical) for both environments (iOS and Android) that contains screenshots (preferably with markups), videos, logs, and crash reports. In order to get all this info, currently you need several separate apps for each environment and, of course before that, the installation of the testing app is needed. This ideal testing tool would combine all these features into one. Read the complete entry (PDF).

The Bug Recommender and Custom Template Tool by Ronny Sugianto

Single desktop app with support by mobile and web add-ons – all completely synchronized with one another. The Bug Recommender System automatically scans for each basic function of the product (e.g. find broken links, broken image, unplayable video, basic issue for form validation, etc.). For each issue found, the system directly captures a screenshot with annotation where is the location of issue and converts it to a custom template report that ready to submit alongside with all the attachments. Read the complete entry (PDF).

The Website Analyzer by Vanessa Yaginuma

A tool that analyzes a website, based on a configurable criteria, and provides a visual report like a heat map of the application. The goal of the tool is to provide additional information for manual testing execution by highlighting areas of the page where the tester can focus first. Read the complete entry (PDF).

 

Again, congratulations to all the winners. uTesters, be sure to keep an eye out for future uTest contests. We have some fun competitions in store for our community!

Categories: Companies

Six Ways Testers Can Get in Touch with Their Inner Programmer

Tue, 09/30/2014 - 15:40

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!

When in Rome, Do What Your Programmers Do

It’s not mandatory that we learn the same languages and use the same languages our programmers and engineers are using, but there are a number of benefits if we do. First, we have expertise that we can call on if we find ourselves stuck with questions. We can utilize work that has already been done and is stored in shared libraries. We can leverage existing infrastructure and take advantage of unit and integration tests that already exist to help inform additional tests that may be needed. All of this comes as a side benefit when we learn the languages our team actively uses.

There is a down side to this, too. If our testing infrastructure uses libraries from the development code to create our tests, we might get false positives, or we may have tests pass that really shouldn’t, because bugs in the underlying code mask errors. If you are just starting out, or are part of a small team, using the development infrastructure as a basis for your programming efforts makes sense. If you need to have a completely independent and isolated code base for testing purposes, then yes, having a different language and technology stack for testing might be a smart move.

Look For and Try to Solve Authentic Problems

Programming courses and books are optimized to teach syntax. They are not written to solve our unique problems. This is why simple examples in book often do not help us when we try to apply them to our own issues and circumstances.  To this end I say, “Make every problem about you.” Ask yourself “how can I take this statement or idea and apply it to what I am working on right now?” Try to think about what you are learning and apply it immediately in your everyday work.

If you have an output file that has a bunch of date and time stamps that you want to remove, start working with some ideas in your programming language of choice (or go old school and use sed or awk with regular expressions), but see what it takes to physically remove them reliably and get the output you want to keep. Not only will this be more applicable and usable, I’ll dare say it will make the learning process more enjoyable, too.

Carve Out Time Every Day for Consistent Practice

Most of us “less-than-expert” programmers can point to one reason; we have not put the time in on a consistent basis for it to become a regular habit. When I lift weights, I often stop training once I meet a goal, or began the activity I was training for. Much of the time, during long periods of down time, I would lose the gains I made. But I didn’t worry too much, because I could bring myself back to where I was quickly once I resumed my workouts. That phenomenon is caused by “muscle memory,” and to have muscle memory be a factor, you first have to build some muscle.

Likewise, many languages I’ve used for various reasons over the years for programming (C, C++, Java, Tcl/Tk, Perl, Ruby, etc.) have a similar issue. If I do a bunch of work with one for a while, and then don’t touch it again for a few months, it’s almost like starting back at ground zero. But after a little time, I see the connections and my programming equivalent of “muscle memory” comes back.

Find a Partner and Work Together Where You Can

Donald Fagen of Steely Dan fame once said that “Walter [Becker, his songwriting partner] can’t start a song, and I can’t finish one. Therefore, we work great together!” I have a similar problem. I’m very much like Walter Becker when it comes to writing code. I can offer ideas and make additions to stuff that’s already underway, but put me in front of a blank text editor and say, “OK, write something” and we will be in for a struggle.

Therefore, I try to take advantage of opportunities when I can work with people who can balance out my own abilities, or get some ideas so I can go in different directions based on where they have started. Two sets of eyes considering the same problem is always helpful. The debates and questions spawned from those interactions open up avenues neither of us alone would have considered. Also, this model allows both parties to swap the roles of programmer and tester, and communicate to both “mindsets.”

For Added Fun, Make It “Do or Die”

I believe that situations that really put you in a pressure cooker, where failure is not an option, can be powerful drivers to making programming much more interesting. I had this experience recently by taking on the role of the build master and release owner for a week. When it was my turn, I came into work to find the build was red. The answer? Fix it! Even if I couldn’t do so myself, I was responsible to make sure that I found someone who could, whoever that person could be.

I had to get acquainted (and fast) with what was being checked in, which branches were being committed, were there any conflicts, why did tests fail, what could I isolate, and how could I get as specific as possible so I could either get the programmer most likely to be able to fix it, or do the work myself.

Sounds scary, huh? It was. It was also FUN! Knowing that I couldn’t slink into the shadows and hope someone else would take care of it, and that it was “do or die” time, I had to figure it out, communicate with the other programmers, and make the build green so we could push. It was an awesome experience. It showed how much I could learn in a short time, and how I could help the build and release process with the programming skills I already have.

To use a snowboarding metaphor, I was standing on the lip of a twenty-foot cornice, deciding if I should drop in or not. In this situation, I was pushed off the lip. I had two choices… crash and burn, or stick the landing. I decided I was going to stick the landing.

My point with these articles is to tell anyone out there who feels on the fence about their programming skills that you are not alone. I want to make sure you understand the foundation that you may already have in place. Most of us already program, we just don’t consider what we do, or how we do it, on par with what we consider “real programming.” If you are one who thinks that way, I’m asking you to stop it. Seriously. Learning how to program, and doing it in a meaningful way that will enhance your career immensely, has never been easier. No matter the language, platform, or problem, you will have to work at it…and regularly. The good news is, if you do, you will have a skill that can take you in may different directions—as a software tester and beyond.

Michael Larsen is a software tester based out of San Francisco, California. Michael started his pursuit of software testing full-time at Cisco Systems in 1992. After a picture-87071-1360261260decade at Cisco, he’s worked with a broad array of technologies and in industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications.

Michael is a member of the Board of Directors for the Association for Software Testing, the producer of and a regular commentator for the SoftwareTestPro.com podcast “This Week in Software Testing,” and a founding member of the “Americas” Chapter of “Weekend Testing.” Michael also blogs at TESTHEAD and can be reached on Twitter at @mkltesthead.

Categories: Companies

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

Mon, 09/29/2014 - 21:28

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.”

I’ve used that as an excuse for years. I said to myself, “Well, it’s OK…I’m a tester. A grouper. I think differently. I don’t particularly like to code, so that’s OK, I’ll just be awesome elsewhere.” I’ve since come to realize that I was wrong. I’d been looking at this whole coding thing the wrong way, and not being completely honest with myself. The truth is, I was afraid. I was not quick with writing new code, I couldn’t solve the real problems that I had, and I was impatient, not willing to put in the real time necessary to get good at it. More to the point, it just wasn’t all that much fun to do. I’ve since changed my mind on many of those points.

So, what in the world do I think I am doing writing an article to other software testers, telling them they shouldn’t fear code? Because we shouldn’t. It isn’t magic. It is systems thinking—science and logic—mixed with some rules that dictate where things go and when. In fact, I’m willing to bet that, if I were to sit down with a “non-coding” software tester, I’d be able to show them that they write code all the time.

Every Tester Programs

If you have ever taken multiple commands and created a macro, or a shell script, and grouped commands into a single file and made it executable, you are programming. Yes, I realize that it doesn’t fit the common image we have when we talk about programming. We are not writing applications. We are not using some spiffy compiler and elaborate language. Still, if you are grouping commands together in one place to execute them, adding a variable here and there so that you can extend a shell script and make it a little more dynamic, or parsing the output of test logs to make a report, you are indeed programming.

Even with software testing tools that are advertised as “no programming required…if you are modifying files, changing values, switching the order, pointing different places…yes, you are indeed programming. All that’s different is the order of magnitude and the level of sophistication.

Programming Need Not be a Barrier

One of the bigger issues that I have come across as I’ve talked to software testers who lament their “inability to program” is the fact that they are mixing up their intentions. When a software tester says, “I am not a programmer,” what they are most likely saying is “I am someone who has not invested the time and energy into learning a variety of programming languages and techniques with the goal of making software for other people to use.”

That’s a fair statement, and yes, when put in that light, there are a lot of us software testers who are not “production-grade shipping software level master programmers.”

That may seem a bit heavy, but work with me here. If I ride a snowboard, am I only allowed to call myself a snowboarder if I enter slopestyle events or halfpipe competitions? No, of course not. Then why should I feel like I have no right to call myself a “programmer” just because I haven’t shipped an application to market, or written some elaborate framework?

The more difficult issue is that, for many of us, programming is a smaller part of what we do. I much prefer exploration and open engagement with my own eyes to writing automated scripts, but the fact is, I can use my eyes a lot more frequently and effectively if I can identify the repetitive work that can be automated via programming. Often, it’s not that we can’t do the work, but that the work feels burdensome, onerous, or just plain irritating. When programming is boring and painful, we will not do it unless we absolutely have to. Therefore, I want to suggest that we try to find ways to make it less onerous, and make it, well, fun.

Michael Larsen is a software tester based out of San Francisco, California. Michael started his pursuit of software testing full-time at Cisco Systems in 1992. After a picture-87071-1360261260decade at Cisco, he’s worked with a broad array of technologies and in industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications.

Michael is a member of the Board of Directors for the Association for Software Testing, the producer of and a regular commentator for the SoftwareTestPro.com podcast “This Week in Software Testing,” and a founding member of the “Americas” Chapter of “Weekend Testing.” Michael also blogs at TESTHEAD and can be reached on Twitter at @mkltesthead.

Categories: Companies