Month: April 2015

The advantage of having magic powers

The truth

People, by definition, have faults. Most of the time, people are unaware, to some extent, of them. Those dear people, alog with their said resident faults, go about their daily business. Manifesting code, conjuring methods, summaning instances and remotely communicating with web services. All these creations, once made flesh by their faulty masters, hold the fault pattern in them, emitting, sometimes weakly, sometimes beacon, fault energy. Quality assurance practitioners feed on fault energy. Unseen by others, it calls them. The QA practitioner unorthodox ear allow no beeswax to plug it, to avoid the siren call. His sneaky hands cannot be tethered to the mast. And so, by feasting and consuming the faulty manifestation, the QA practitioner transforms it, elevates it, into production ready code.

Just a bit

OK, that was not exactly true, and maybe, just a bit over the top. Yet, if you have the experience and the talent that motivated you to gain it, you should be able to pull some very impressive tricks. We all makes mistakes, and we all make repeatable mistakes. I’m not talking about the “turning a blind eye to your own best interest” kind (dating a person you know is not good for you, eating that extra fry, delaying a task until there is no way you can complete it in time). Repeatable mistakes are spelling a word wrong for the Nth time, trying to turn on the light when you know the power is out, and more important to this discussion – introducing the same bug – again. We, as the quality assurance people, should expose these bugs like hyperactive magicians during caffeine overdose. These low hanging fruits should not receive any mercy. They count, like all other bugs. And they also give you the opportunity to impress, without actually showing off.

Continue reading

Thinking outside the (Black) box

Wisdom of others ltd.

I’m all about learning new technologies, and bathe in the wisdom of others.

I’m also all about nodding my head politely and do my own thing, when I feel like it.

 The polite nodding stops when I hear something along the lines of “black box only”. It gets worse when it is followed by an explanation.

I have a beef  with the notion that the QA expert should always represent a user.
In other words: “If a bug exists and the user cannot cause / experience it, then it is not a bug, and all other testing methodologies (that do not replicate the user experience) are null”.

 In a fairy wonderland, where every single factor in nature can be calculated and controlled, this might be a valid point. But in real life it makes as much sense as eating a lot of feathers when you feel heavy, or connecting one end of an extension cable to the other end, expecting infinite power. Even worse, in many cases, this idea does not originate out of pure naivety. But let’s start easy….

Source without control

From my experience, such a misguided concept can arise from the following reasons:

 

  • Not understanding testing limitations
  • Not understanding testing capabilities and benefits
  • Underestimating the tester’s technical ability
  • Overestimating code and system quality

 

Continue reading

The rebel QA – a case for doing your own thing

On the road, be smart, not right

 

When you work with other QA persons, you have the privilege of having intelligent (= QA)  partners, that understand your language exactly. In all other cases (mostly when working under development or product persons)  you will need to make some adjustments.

 

Most of all, you will have to practice the gentle yet unavoidable art of processing what they asked for, and coming up with what they really want. This sounds a bit presumptuous, but in fact we see it all the times when someone is (only) partially learned in another’s profession – some of the things that comes out of the mouth will be nonsense if you take them literally, and some might be pure stupidity even with some friendly leeway. I’m pretty sure the dishwasher repairman I called knew exactly when to stop listening to my description of the the issue (Probably right after: “Dishwasher does not clean”). Sometimes your task description is just as useful.

 

 

Specing solutions instead of describing the problem

 

This is a very common issue, and it is not limited to QA. Some product people tend to spice up the requirements with technical terms and describe the implementation instead of the feature, reducing the developer’s experience and ingenuity to plain coding (If you have BDD written somewhere on your CV you probably have an allergic reaction to it).

 

In the testing world this becomes even more of an issue. If a product person limits the creativity of the developers (which might prevent a better looking, better performing product) , limiting the tester’s creativity (to the scope of the developer’s) will ultimately limit the test coverage as well, and I don’t have to tell you how it all ends.

  Continue reading

© 2024

Theme by Anders NorenUp ↑