Wednesday, December 10, 2008

Skills for Software Testers in the Future

Last month I delivered a keynote address at EuroStar on "Trends that May Impact the Future of Software Testing." There were some interesting questions following my talk, one of which I would like to discuss in this post. "What do you see as essential skills for testers in the future?" Great question.

First, let me say that the list could be long and your list probably will differ from mine and that's fine. In fact, please comment with your answers to this important question.

Skill #1 -Thinking Skills

Too many testers fail to think through what they are doing and why they are doing it. They also fail to use imagination and instead rely on a repository of knowledge somewhere that is probably outdated and incorrect. Sure, we can curse the darkness of bad documentation, but we've been doing that for over 30 years already so let's get over it. Let's light a few candles to illuminate the subject of hidden understanding.

So, for example, when doing a boundary test, ask, "Is this test meaningful?", "What will it prove or disprove?", "Are there more important tests that I haven't done yet?".

As testers we have to be very careful about falling into ruts and thinking the same way all the time. Learn to look at problems from different angles.

I like to play thinking games just to stay in practice. One game that is helpful for test teams is "20 questions for software". I improvised this game in a class on exploratory testing when only I had my computer at the front of the room. Here's how it works. The leader (perhaps you) are at the front of the room with an application projected on a screen. Then, go around the room in order (a u-shaped room or circle is best), with one person starting the questioning of the application. They should ask a question such as "What happends when you...(fill in the blank)?". Then, the person next to them asks a question based on their question. This continues around the room, maybe even multiple times. There are only two rules: 1) you must wait your turn, and 2) your question must be based on someone else's question or answer before you.

You may be surprised about how much you can learn about the application by doing this. You may also be surprised (perhaps dismayed) about the quality of questions. This gives the team leader insight into where to develop the thinking skills of the test team or individuals on the team.

I also like to work Sudoku puzzles because they require deducing, eliminating possible solutions to find the right number(s), and using other thought processes that are the same as used in exploratory testing. I've never tried to work one puzzle together as a group, but that would be an interesting experiment.

Skill #2 - Communication Skills

I believe that communication is the basis for everything else we do in IT. Without good communication, we can't even define the problem to be solved, much less define the solutions to the problem or the testing of the solutions. Ironically, communication is the last thing we take training for, or practice, or apply in the workplace.

Testers especially need to be good communicators in the following ways:

Accuracy - People must be able to trust the accuracy of test results and other information from testing. Once the accuracy slips, so does the credibility.

Timeliness - Timely communication helps people to form good responses to problems, take advantage of opportunities, and generally work together better. Sitting on bad news, hoping for it to become better news, is not a good approach.

Thoroughness - Telling only part of a story is as bad as giving inaccurate information.

Courtesy - How people say things is just as important as what they say.

Helpfulness - Overall, the information a tester provides should help the rest of the project team to fix issues, make improvements and deliver a great project on or ahead of schdeule.

Meaningfulness - The information must have value to the audience, otherwise people will disregard it as "just another report" that may or may not be read.

Skill #3 - Measurement Skills

When you think about it, testing is measurement. However, we as testers often struggle with what to measure, how detailed the measures should be, what to do with the measurements, etc.

It takes skill to know what to measure without going overboard. It also takes skill to make the correct interpretation from the measurements and metrics. But how does one build these skills? I'm going to suggest a radical approach. Don't start by reading books on measurement, unless they are basic.

Like many things, including testing, we are up against Parkinson's Law that says "work expands to fill available time." My variation on this is that simple things can become complex just by writing books, having conferences, etc. As an example, function points started as a fairly simple idea but then evolved into more complex ways to count and apply them. So when you read a book on measurement your first thought may be that you need a large set of measurements to "do it right."

Instead, simply look at what needs to be improved and find two or three things to measure that could show progress in meeting those goals. You can also consider a typical project and what you need to know to stay on track. This is the dashboard concept. Have five or six indicators at the high end.

Then, find ways to measure without being intrusive. This in itself can be a big challenge. That's why simple is good.

Skill #4 - Configuration Management Skills

CM has always been an essential skill for testers. After all, what good is it if you test the wrong version or configuration of the software?

With virtual environments, it is even more important to know how to manage them. At this point, you may be thinking, "Yes, but the tool has features for that." Consider though, that a tool is not a process.

So testers need to know how to control all the items in the environment - software, hardware, data, and any other system components.

Skill #5 - Technical Skills

This is an interesting debate. How technical does a tester need to be anyway? On one hand, it is the lack of technical perspective that gives testers the same view as users. Too much technical knowledge and they may apply workarounds that users would not think of, therefore not seeing problems from a true user perspective.

The term "Technical Skills" is a fuzzy one, so I'll clarify my meaning a bit. The technical skills I refer to here are those that allow testers to use new tools and approaches effectively. I don't believe that testers need to be coders, although sometimes that skill comes in handy. But, if a tester likes to code and they can maintain objectivity, it does open some options.

I believe it is a mistake to eliminate a tester from hiring consideration just because they can't code or work with a particular tool. There are simply too many other needed skills and attributes to limit the decision to technical skills alone.

It's like being in a swimming pool and being able to go in the deep end as opposed to just staying in the shallow end. While we can all be in the pool and have fun. Some will be able to do more advanced things, like diving and snorkeling. It's not about worth or value, but about the ability to experience different things. So, if an inexperienced swimmer gets thrown into the deep end, it's "sink or swim", and that can sometimes be a dangerous thing. You may have experienced that "over my head" feeling.

Another example is owning and driving a car. Some people are happy just driving the car and keeping it filled with gas and having the fluids changed on schedule. Others want to get more involved in their vehicle's maintenance and repair by doing things such as changing the oil, replacing air filters and spark plugs, replacing fan belts, hoses and brake pads, etc. A few braver souls with older cars get into major engine repair or replacement. All of these types of car owners can drive the car well. Some can perform maintenance but due to time issues prefer to have the work done for them. All are valid owners and I would rather be on the road with good drivers who know little about auto maintenance than bad drivers who can replace engines in a day.

At the end of the day, the answer to this question of should a tester have technical skills may be a firm "it depends!" It depends on the person and their abilities, the projects they work on and the types of testing their job requires them to perform.

Skill #6 - Business Skills

Testers need to be able to speak the language of business. How can we as testers expect to be invited into business-level meetings if we don't understand the culture and language of business? This is more than just understanding business processes. We must know what's important to the business - profits, market share, strategic goals, markets, growth, legal, return on investment, and trade issues.

So, these are some of the important skills as I see them. Agree or disagree? I would like to hear your comments and ideas!

11 comments:

Mike Kavis said...

Great post Randy. I shared it on Twitter with my network. The technical skills point is a tough one. I agree with your point as long as there is at least one very strong technical person on the team. Today's development approaches are becoming more complex (EDA, SOA, Cloud Computing) and there must be somebody on the team who really understands the underlying architecture. Security is becoming so much more complex in the world of distributed and off-premise computing and is orders of magnitude more challenging than n-tier computing. Your thoughts?

Randy Rice said...

Hi Mike,

Thanks for your thought-provoking comments. The topics you mention are some of the things I see test teams struggle with. Back 20 years ago test teams tried to adopt test tools, but learned about 10 years ago they needed that technical person on the team. Then, about 5 or 6 years ago I started noticing more and more testers moving into testing from development and not only using tools well, but building their own tools. I don't see that trend diminishing.

What I do see, though, are testers that lack knowledge and skills in the approaches you mention - SOA, Cloud, Security and even agile. I had to greatly simplify a version of my security testing course recently so that the testers could understand it. I was told by the client not to even use the term "SQL" because that would cause the people's "eyes glaze over". That makes it tough to discuss security attacks and tests! (Then I had the big company that discontinued my security testing course because they felt it was teaching people TOO MUCH about the attacks!)

Also, how can testers develop test strategies when they don't know the basics of the technology they to be testing?

I think you raise a good point that technical skills and knowledge go far beyond tools.

To me, the issues are 1) how beneficial are technical skills? (I would say "very"), and 2) can these skills and knowledge raise a testers credibility with developers? (I would say "yes").

Too many testers aren't even willing to stretch and try to learn new technologies. Thankfully, there are those testers that are!

Here's my closing thought on this comment. The future of software testing will be more technical. To survive and prosper as a tester in the future technical skills will not only come in handy, they will distinguish you among other testers.

Thanks,

Randy

Shobha said...

Hey Randy, Congrats for the award that you received and Thanks for all the efforts that you are taking up to make all testers competent to the current market. Thanks again. I will stay tuned to your blog and your conference calls and am surely implementing them in action. I have many questions for you and I would myself would like to contribute in future in this momentum as well.
Merry Christmas!!!!!

Randy Rice said...

Hi Shobha,

Thanks for your kind words and for being part of the discussion. All questions and thoughts are welcomed. Merry Christmas to you as well.

Best regards,

Randy

Shobha said...

Hello Randy,
I always feel that many of the testers have the zeal of learning, but everyone donot get the chance to try their hands on different things practically and thats one of the reasons why testers lack knowledge hence lose competency despite being able. Pls correct me if I am wrong.
As per me, the best tester needs to have following know-how:
1. Tester needs to have basic language skills like C, Java,XML, etc.
2. He must have tried his hands on different types of testing like regression, security, performance testing.
3. He must be aware of most of all testing terminologies theoretically and practically.
4. He must have tried his hands on different types of applications like web based, desktop application -client server, mobile applications, etc.
5. He must be pretty comfortable with usage of automation tools like RFT, QTP, etc.
Pls comment-Randy?
If I am correct even to certain extent, how can we try being an all-rounder in case we arenot getting every exposure to be an expertise in our field?
Another question is how do certifications help? I am an ISTQB certified tester, does it help in my career?
Next, I have heard about TPI for planning and estimation for testers. We follow agile methodology in our project where we have a 15 days of iteration cycle... we use planning poker to estimate and commit on different issues before we start a new iteration. Now, my concern here is, we need to have a systematic wayout to estimate our efforts for each task/issue.I want to know more on TPI. Is there any url or can you share your knowledge on it?

Hush!!!!!! Too many questions, I am sure, you must be blaming yourself for welcoming me and my questions.

Thanks Randy

Randy Rice said...

Hi Shobha,

Thanks for your comments. There's a lot there and I'll try to be concise.

First, I agree that most testers have constraints in building skills. I like to find ways to break those constraints like using free and cheap tools instead of the expensive commercial tools.

Instead of saying a tester "should" have XYZ or "must" do "such and such", I like to say "it may be helpful" or "it has been helpful for others." That's why I say "it depends." When it comes to skills, it really depends on where you are in your career and where you want to go.

I think that the more exposure you have in terms of environments, roles and technologies the better. In my case, I have been able to leverage a little experience to be a platform for other projects. But be careful. There used to be the joke that just because someone "touched" a certain piece of equipment they would claim that as a point of experience. Don't claim or list something as experience unless you really do have it.

While specific tool or language experience can be a big plus, you can't be all things to all people. Learn what you can and don't be discouraged if you can't get the skills you may want to have right now. Things have a way of working out. To me, the most important thing is that you don't turn down an opportunity if it materializes.

OK, you threw in the question about certification. I don't have time to really flesh this out and there is controversy. I must say that I have a bias since I am an officer of the ASTQB, but I am there for a reason, that is to help make test certification meaningful and helpful. In my opinion, test certification helps to establish that someone has achieved a level of knowledge - foundation, advanced, etc. I don't see certification as a demonstration or evidence of skills or abilities. Those normally are proven in the workplace. That's just my opinion. I could get into that more later.

I don't have a lot of background or experience in TPI, but perhaps someone else could provide some perspective.

Thanks,

Randy

Shobha said...

Hi Randy,
can u pls recommend any opensource freeware automation functional and performance testing tool for webbased application which works almost as easy and efficient as QTP?

not-bob said...

I'd like to see these skills organized into a curriculum for post-secondary training (tech centers as well as undergraduate majors and minors specifically).

It's one thing to ask for these skills to exist, but without some organized way of preparing the next generation, it's a crapshoot when it comes to hiring.

For too long, we've taken warm bodies and made them a QA team and then wondered what skills they need to be successful.

Suppose there was a minor in software quality that could be added to either a Comp Sci or MIS degree that covered the following
- Test Planning and Execution
- Project Planning and Execution
- Testware (data creation, data manipulation, test harness creation, unit tests, custom system utilities for cleaning data, making system changes, etc)
- Statistics from a Project/Test management perspective (metrics, measurements)
- Decision Making (drawing heavily from the Psychological research on the topic)
- Technical Writing
- Software Quality from a historic perspective

Having people graduate with this experience would be invaluable for companies looking for new hires.

Scale this appropriately (Usability, Security, Quality Assurance topics in particular) for trade schools and for a full major on the topic and we would have a strong view of quality as a baseline, regardless of what role that person had in the development process.

Randy Rice said...

Hi Shobha,

You probably won't find a free tool that has the ease of use and robustness of the high-end commercial tools such as QTP. However, the best place I know of to find the open source tools is at http://www.opensourcetesting.org.

This does bring up another thought about the types of test automation that can be performed. While capture/playback is very nice in the demo, the scripts will need to be modified after recording. Many test automators go on to use what I call "script-intensive" tools that just focus on allowing you to create the scripts from the beginning. Tools like FitNesse (http://fitnesse.org) can also be a way to achieve this.

I also suggest sometimes that testers can use tools like MacroScheduler (http://www.mjtnet.com) to learn the basics of automation. Keep in mind however that macro tools are row and column focused while the high-end tools will recognize objects by name. Also, macro tools don't do the comparisons to baselines like the commercial tools.

I hope this helps!

Randy

Randy Rice said...

Hi notbob,

Good comment. I agree that there should be more visibility in higher ed for software testing skills. There have been attempts but we still have far to go. It would be nice to have a program in at least one institution to hold up as an example.

Thanks,

Randy

Shobha said...

Thanks Randy