Trigger-Happy vs Rapid-Fire Testing

 #qa #softwaretesting

 So, what's that then? First impressions? Is it a desirable or less desirable action?

In General

Let's assume that Trigger-Happy has more "undesirable" associations and Rapid-Fire has more "desirable" associations.

When it's an undesirable activity or approach to testing it can be associated with lack of direct questioning, or lack of processing of the results to determine the next steps. It might be a sign that the tester is "lost" and isn't asking for help or it could be a sign of a misunderstanding about an action, procedure or step.

Alternatively, it could also be purposeful action to generate data/results without interpreting them, i.e. "I'll only need to interpret them if I see something interesting - if nothing interesting happens then I won't care too much."

So what is it?

Trigger-Happy Testing is an approach to testing where the thought process is put on hold unconsciously. It might be:

• The pound-the-keyboard approach (sending in several strings of data to an input buffer without any connection between them or having a specific question in mind). [This is trigger-happy when there's no "time to stop" or "stop to change" guideline.]
• Performing some action because "I saw someone do this and it always works for them."
• "This step is written in my notebook and I always do this." Without any meaning or understanding behind the activity or its expected result.

Rapid-Fire Testing is the approach to testing where the feedback loop of result-analysis-decision is consciously suspended. Examples might be:

• Let's try and break it. When we've broken it then we'll analyse if the way we did it was "reasonable".
• "The pound-the-keyboard approach" when used to generate a batch of results which might be analysed as a group. Analysing the results may help determine a "test step" grouping, determine a pattern in the behaviour of the product or probing for certain responses.

The essence of trigger-happy testing is a warning sign and it's useful to recognise them either in you or someone else.

Indicators

This approach can be a sign of:

• Running out of ideas - try something new. This is a positive approach, when you're at a dead end - "do something" - but try to know when to understand the results and have an idea about when to change approach.
• Not interpreting the results so far from the application/platform and forming a hypothesis about what to do next. If this is done for a purpose ("I'm going to analyse later", fine) but if not then it could be a warning sign ("try anything", rather than "ok let's get my bearings and what shall I do next?")
• Receiving a new/unseen response/result from the application/platform and resorting to a "this usually works or gets me back to a known state". This could indicate not using defined operating procedures (for certain HW) or knowing if what I'm doing is appropriate.

So, why have you named something Trigger-Happy Testing or Rapid-Fire Testing?

Because I could!

But, more importantly, after taking James' Rapid Testing (read previous post) I was triggered to re-look at some of my own assumptions and observations.

I've observed this type of activity on several occasions and asked the testers what their thinking behind it was, what led them down this path.

Many times it's frustration, reaching a dead-end in ideas and not knowing what to do next. From the perspective of "doing something" and not freezing, it's a good idea. But it can be dangerous if it becomes a general approach - i.e. getting stuck in the "pound the keyboard" mode without necessarily evaluating, "why did I do that and what shall I do next?"

Other times it's a "let's just break it mentality". Also good as long you operate within some criteria of "when to stop" and to understand the results.

My motivation is to highlight when it's a potential benefit (rapid-fire) and when it's a potential danger (trigger-happy) to a tester and help testers identify some of the warning signs.

Understanding your own approach and when each is applied is fundamental to learning how to be a better tester the next time around.

Oh, I haven't finished exploring this area yet...

Do you recognise a trigger-happy or rapid-fire approach?