Are You a Software Tester? Don’t Do This

DZone 's Guide to

Are You a Software Tester? Don’t Do This

MVB Erik Dietrich offers some clear "do nots" on software testing.

· DevOps Zone ·
Free Resource

The following article is a guest post to Zephyr from Erik Dietrich.You can read his writing and find out more about him at http://www.daedtech.com/ and you can follow him on twitter @daedtech.

It would be easy to make this a link-bait article.  You were probably even expecting something like that, given the title, weren't you?  You'd open this up and be greeted by a list of 6 things that software testers should avoid, or perhaps, one weird trick to make you better at testing.  That’s a different article altogether, and it would do you a disservice.

While there certainly are plenty of pitfalls for anyone to avoid in any line of work, and software testers are no exception.  Don't forget to track the steps you took to generate a bug.  Don't let the developers pressure you into rescinding a defect report.  Don't be afraid to ask questions for clarification and understanding.  But, at the end of the day, there's one really crucial trap to avoid, and the essence of what it means to be an effective tester of software grows naturally out of avoiding it.

Don't Limit Yourself to the Test Script

If you are reading this and test software, then you are an intelligent human being with analytical and problem solving skills.  You deserve more out of a career than mindlessly executing instructions by rote, and your company deserves more from you than manual performance of a task that could be automated.  You're there to apply your intellect to finding problems with the software.

As someone responsible for putting the software through the paces, you are the ultimate power user of it.  You can do so much more than just verify that a dialog closes when you click "cancel."  Is the dialog confusing?  Does it appear in a strange location?  Does it obscure something that you know users want to see?  You won't see these things in a script, but they're important -- the software and the business need this feedback.  And you're in a unique position to offer it.

Use your position as an expert in the software to promote quality and ensure that the business is doing the right thing.  Unquestioningly executing a test plan is a surprisingly passive activity, and the business needs your expertise.  They need you in meetings with developers and project managers early on, discussing requirements and defining what tests need to pass in order for the software to be shippable and satisfactory to its users.  In the agile world, this is known as a "three amigos" meeting, and it underscores just how vital engaged and critically thinking testers are to having high quality software.

When you're eyeing the software critically and taking an active role in deciding how it should behave, you're going to have an important understanding of what should be happening when people are using your product.  You'll learn not to ignore your instincts because you'll have an excellent sense for when something fishy is happening.  By favoring exploratory tests directed by your understanding of the software's purpose, you'll move from finding bugs to finding important bugs, which is exponentially more valuable.  When it's time for the software to ship, would you rather have found that an error message was off center or that the site crashes when more than 10 people log in at the same time?  A test script will probably catch the former, whereas an intelligent and engaged tester is more likely to catch the latter.

If your job requires you to execute a test script, then, by all means, do it.  But advocate automating it and make a point to go above and beyond it as well.  Your time, experience and resourcefulness are too valuable to your company.  Don't limit yourself.

About the Author: Erik Dietrich, founder of DaedTech LLC, is a programmer, architect, development coach, writer, Pluralsight author, and technologist. 

simulation, test management, testing cycles

Published at DZone with permission of Erik Dietrich , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}