Moonlighting #2

#softwaretesting

Reflections on the Test Republic Test Challenge

(Not the 80's series with Bruce Willis.....)

My look at the testing challenge on Test Republic. It was interesting for a number of reasons. It re-affirmed the need for some key skills and highlighted that learning opportunities are all around.

I liked the challenge because it gave me a couple of learning opportunities. One was to try something new (explicitly testing a website) and the other was to write an example of a bug report that would be a good/useful example to others. It's sometimes easy to preach about technique, but sometimes just demonstrating is equally instructive.

I approached it from the perspective that it would give me some reminders about things to have in mind during our daily work.

The challenge didn't give any guideline on how the testing should be done (it's aim was on the fault reporting and motivation of fault fixing), so I approached the test subject from a usability angle using an ad-hoc/exploratory method.

Usability gave me the starting point and the ad-hoc approach limited my test session (30 minutes) and gave me the thread for the test step development. My raw test notes (to be published later - I want to add some additional thought explanation) show the test steps with observations and comments and how they lead to the successive steps.

The challenge didn't give me any groundbreaking moments but it did throw up some very useful reminders of skills and techniques to have in mind.

Take a break

#1. Emphasied the importance of walking away, taking a break, unplugging

When you finish a piece of work during your working day (test session, writing a report or reading a document) take a break. This might be taking a coffee, a five minute leg stretcher, talking to a colleague or walking the dog.

This take-a-break activity allows you to re-charge (resting), re-focus on your next activity and allowing a little non-focussed-thinking - this might be drifting into problem solving whilst doing something else (for me this was pushing a pram with my sleeping daughter.) Some of my best brainstorming happens this way.

The challenge didn't make me do this - but it's something I consciously employed as the challenge was an "on-the-side" activity.

The Power of Review

#2. Emphasised the importance of review, inspection and re-review

This is something I've been thinking about recently in preparation for a different post - the amount of time spent on reviews and analysis of work, reports and feedback. This is a huge resource for any testing professional.

Review and re-review was demonstrated as being very important in this exercise with two examples. One was to do with the actual fault decription/reporting and the other was to do with reviewing the test session notes.

Fault/Bug Report

Reviewing the reporting. When writing a report - whether a bug/issue report, a test session/execution summary or some presentation of findings it's always useful to take a break after it's "finished" and go back and re-read. Look at it from one of two perspectives: 1) proof-reading - does it make sense, does it say what I intended?; 2) will my intended audience/receiver understand it?

Test Session Notes

A re-review of the testing notes threw up a fault that I didn't pick up as an obvious fault the first time around. Whilst writing a report for another fault and explaining the steps involved (for reproduction purposes) the fault became obvious.

This emphasizes the need to review test notes, environment changes, lab set-up now and again. There is always information to be found. Sometimes it might show that all is as expected. Other times it might raise a question "why is this step skipped, this step inserted, this env variable set, etc, etc."

Keep it clear and understandable

#3. Illustrated that there are useful learning opportunities for testers in the most common of places.

A well-known website. Go find the errors... Ok, so you find an error, now describe it...

Sounds simple? Yes, but doing the simple simply is something everyone should be practising now and then. Describe something in a clear and straightforward way that's directed at your audience.

In this challenge this meant describing the faults found in a way to get the message across - that the fault is understandable, along with all the basic data, how to reproduce and some motivation for the fix to be implemented.

I'm a great advocate of "keeping it simple" or "simplify, simplify,..." - it's very easy to preach, but putting your words into practice is something we should all be able to do.

Push your own boundaries

#4. Learning is (should be) fun. Don't be affraid of mistakes.

Don't be affraid of doing something new, different or unfamiliar. This is something where you can always find a learning opportunity. You might "fail", achieve or exceed your expectations but you'll always learn something.

Whether this is to do with a new test technique, approach or a way of analysing a problem there are always opportunities to pick something up and improve.

Maybe the test technique didn't work for you. Why? Was there some preparation missing or do you need to go back through the basics?

Tip: Think about how you might explain that technique to someone not familiar with it. This challenges you to understand what you're talking about and is a great way to clarify your own thoughts. The next step is to do it in person - then you might get challenged for real.

If you never make a mistake you'll never demonstrate that you've improved. The Japanese work ethic is very open to making mistakes as long as you learn from them. If you're learning to ski or ride a horse you'll be told that if you're not falling over / falling off then you're not trying hard enough.

The "What's in it for me?" Priniciple

#5. Influencing factors - the perspective of the receiver or the report

The challenge called it bug advocacy. Some might know it as motivating your request. But however you understand it you can think of this as an example of the "what's in it for me?" scenario. I wrote a post recently, here, where I touched on influencing skills that are useful for all testers.

The bottom line for any motivational argument is how to answer the other person (the one you're selling to) when they're thinking "what's in it for me?" If you just tell them about you're problems (bug #n fails due to xyz, please fix) without any motivation then you're likely to be disappointed.

(For best results do the influencing indirectly - let them come up with the idea.)

So the problem might then be presented as: bug #n fails due to xyz, impact of failure "abc", estimated cost of solution "def", benefit to customer "ghi", benefit to supplier "jkl". If the supplier/developer then turns around and says we'll fix this as a priority to be delivered xxx, then you've done your job - you've convinced them of the need for the solution. Then the bargaining can start about actual delivery times, emergency/interim fixes etc.

This principle is an influencing skill - it's something all testers should have (to a greater or lesser extent) and it's something that needs continuous practice to stay sharp.

The above five areas occurred to me during the course of the challenge and during the susbsequent assessment. They are skills/techniques useful for all testers during their day-to-day work.

I'll post my actual entry at a later date with some extended notes on the approach and steps for deduction and reporting.

When did you last think about the skills you're using and which need improving?