The only thing Testers should learn in 2013

How is your wish list of ‘things to learn’ in 2013? If I am not mistaken, it will be largely driven by new technologies and catching up with the new stuff. That is not bad, but as Testers many of these might prove distractions. Not convinced? Read on and you’ll get the idea.

The Agile Quartile as discussed in detail through Lisa Crispin and Janet Gregory’s excellent book ‘Agile Testing’ suggests that any tests that we run are either Technology Faced or Business Faced. The more inclined the tests are towards Technology, the more chances are that they will get automated. It is also suggested that programmers should participate more in writing Technology Faced tests.

agile-testing-quadrants

(Note: The original Agile Quartile was introduced by Brian Marick who is one of the signatories of the Agile Manifesto)

So if we’ll keep learning more and more technologies, we’ll come up with great Technology Facing tests and lose the ground on Business Facing tests. My bet is that if we spend more time learning the Business we are serving, that may prove a worthy investment and strike the balance where programmers write more and more Technology Facing tests and testers chipping in with Business Facing ones. Sounds like a plan?

If yes, I am suggesting following ways to equip us with more knowledge about the Business to run more Business Facing Tests:

–        Meet thy users

In many organizations, testers do interface directly with the Customers so make use of that facility. If that’s not the case, consider joining their forums, attending your user community conference, learn about your competitors and what they offer to the same user to solve their problems. Don’t leave this effort only for your Product Management / Business Analysis team as their findings could be flawed.

–        Take out your Business Analyst for a cup of coffee

And you’ll get the pay-off in first 15 minutes of the talk. Seriously, spending more time with Business Analyst (or any one in your team that translates business requirements into technical solutions) can give you a heave of information that you may never get from Programmers in your team.

–        Imagine yourself as User

Play this game with you where you perceive yourself as the actual User of the application and use it. Leave the test plans and any requirement specs on one side of the table, and just use the application in that mode. For example, if your application has two views one for the resources and other for Project Manager, try acting like a resource on Monday and become a Project Manager on Tuesday. Use the same application and these new ‘glasses’ over your eyes will give you an entirely new picture.

–        Ask this question: “Why my user would love my software?”

This is an extension to the above but constantly ask this question. Now you know some of the business requirements, and as you imagine yourself as user, think about stuff that delights you and falls you in love with the software. I shared some thoughts on this earlier here: Why we love some software more

What ways would you suggest for this game plan?

Tags: , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s