Monday, July 22, 2013

Never Stop Learning: 99 Ways Workshop #3

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.


Suggestion #3: Never Stop Learning - Chris George

All right, this one is the epitome of "general and vague", so creating a true "workshop" around this one would go way beyond an actual blog post. Still, it's a very good piece of advice, so I'm going to put some personal spin on this, and make some suggestions for what has worked for me in this regard.

Workshop #3: Create Your Own "Perpetual Learning Program"

Software testing is a broad and varied discipline. Context reigns supreme, and each endeavor that deploys software (which covers just about every interest imaginable) requires testing and understanding of the customer domain and technical domain to be effective. That means that, if you want to learn everything there is to know about software testing... it's a never ending process. You actually can learn forever because every product and project is different. 

I like to think of software testing to fit into three different areas, and when I talk about software testing, I tend to think of these three areas:

- universal software testing skills
- context specific domains
- customer specific domains

I'm deliberately simplifying this because we could easily write books on each of these aspects.

Universal Software Testing Skills

If I had to make a suggestion for everyone, at the bare minimum, I think every tester should spend some time learning how to program the shell of their preferred/required system. Make that goal one.

For most of us, there are three systems that are in general everyday use. If you have a laptop computer, chances are it's a variation of three flavors: Windows, MacOS, or Linux. MacOS and Linux have very similar plumbing, and the shell they use (with variations for the particular flavor) all utilize a shell that interacts with system resources in a similar way. Windows uses Power Shell, which, while using a different syntax, does many of the same things. Thus, if I had to suggest any "universal testing skill" it would be to learn how to program, even at a rudimentary level, the shell of your operating system.

Programming knowledge can be very readily compared to the scripts created in the shell, and many languages use similar constructs. The reason I would suggest learning how to program the shell first, is that users can more readily, and more quickly, see how systems interact with one another. It's also helpful in the sense that managing data and the ability to transform data can give a tremendous boost when it comes to helping testers analyze and consider the data they generate with their tests.

Outside of shell programming, when we consider a skill that's universal, to me that means a skill that anyone can use and apply to any testing problem. Here's a small list:

- understanding the scientific method and how it applies to software testing
- asking questions and determining what we know and don't know
- testing assumptions with observable results
- understanding oracles and how they can help guide us to decisions 
- direct communication and effective bug reporting and triage
- test case design and how to express testing ideas to others
- monitoring for performance
- understanding the basics of user experience
- configuration and modification of system parameters

Each environment will have different ways that these things are implemented, and making a universal "you need to learn this to be effective" is tricky. The overview of each of these is, I feel, universal, so spend some energy learning the basics of all of these.

Context Specific Domains

If the application that you are working on has to deal with a particular subject domain, then it is a good idea to make part of your "continuing education" to learn about the actual focus of your business. If you want to be an effective tester at your business, one of the best recommendations I can make is "learn your business". 

- If you work on networking equipment, the more you know about routing and switching protocols, the more effective you will be.

- If you work on medical equipment, understanding the processes and the methods used for medical care will help you better test.

- If you are creating software that helps attorney's manage the legal process, then learn about those cases and sections of law that are relevant to your product. 

Note: software testers do not have to be experts in these subjects, and there's a lot of testing that can be done with just a little knowledge, but the more expertise you possess, the better you as a tester can address interesting issues that others may not be able to find.

Customer Specific Domains

This brings us back to suggestion #1, which is "Get to Know Your Customers". Products are used differently by different people, so learn what it is that they do and how they do it. Understand the contexts and different ways that a product can be used, and what issues matter to different audiences and how to address those issues and audiences. 

Bottom Line:

There's so much to learn, so much to focus on, and so many different avenues to explore, that the general statement "never stop learning" is easy to achieve. Read blogs. Watch courses on NetTutsPlus, Coursera and Khan Academy. Dig into SlideShare and other testers presentations over the years. Review the BBST materials available at testingeducation.org/BBST. Read about topics like philosophy, epistemology, systems thinking, User interface design, customer service, and other avenues that are not necessarily obvious. There's plenty to learn about software testing to keep us busy, but let's not forget that there are many other areas and disciplines that, if we learn more about them, will have a tremendous knock off effect on the way that we look at and practice our testing.

No comments: