What Agile Testing Is (Not) – Java Code Geeks

Okay, I’ve to confess I’m the type of one who, when requested about one thing, tends to begin replying by saying what one thing isn’t.

So, let’s begin this piece of writing by stressing what Agile Testing isn’t in my view:

• Testing sooner
• Skipping testing
• Testing too late
• Making unskilled folks check

Let’s undergo these factors one after the other.

Testing sooner

One factor is to be as time-effective as potential when testing a software program product.
The fully completely different factor is to be compelled to hurry testing one thing pushed by unreasonable deadlines.

Even worse if what is anticipated from the tester(s) is simply to verify (as quickly as potential, after all) that every thing is okay.

So, to me Agile Testing has nothing to do with quick and shallow validations or with (rapidly/dangerously) confirming (doubtlessly unsuitable) assumptions. This may slightly be reckless and meaningless testing.

So, as I see it, good testing takes (affordable) time and environment friendly testers.
Quite the opposite, although dangerous/inefficient testing might apparently take much less time, try to be warned that you simply’ll ultimately understand that it was really dangerous/inefficient and mainly meaningless in the end.

Skipping testing

Effectively, you need to be capable to foresee the danger of doing that.
If you’re not, likelihood is you might be residing below the phantasm that:

• Your staff is so good that they’re producing good software program or
• Your prospects are so easy-going that they don’t seem to be going to note that your software program is definitely fairly removed from good.

Let me stress that I’ve by no means occurred to check any software program product which was so spotless it didn’t really should be examined in any respect. Principally as a result of such a product doesn’t exist. And I’m fairly certain you too are conscious of that.

In any case, residing in denial doesn’t clear up something.

Testing too late

Based on my expertise, beginning to check a product on the very late stage of the software program growth course of is sadly nonetheless quite common, particularly when organizations imagine that creating/delivering one thing is rather more vital than difficult their assumptions about it.

So, in some unspecified time in the future, somebody may need an thought which suggests constructing a software program product (hopefully, with a view to clear up an issue slightly than to create one other one) and so they may begin both doing that themselves or hiring a staff in a position to do this.

In the meantime, no one is difficult the concept itself, the software program structure or the code that’s being produced to implement it.

So, after a minimal viable product (which, by the best way, too typically isn’t viable in any respect) has taken form, somebody realizes that some glitches could also be hindering the method.

So, one tester (normally misnamed as a QA) is urgently introduced into the staff to validate the software program product and to examine (and guarantee the stakeholders) that every thing is okay.

I’m wondering, although, would you want a tester if one thing was okay?

The factor is, difficult assumptions at this level is normally not properly accepted: it’s really one thing that solely notably skilled and courageous testers would dare to do.

In any case, what most managers wish to hear now, with out additional ado, is simply that every thing is okay.

Which implies the group in query might find yourself:

• Delivering a low-quality product with out figuring out that it’s a low-quality product (their prospects positively will, although),
• Delivering a low-quality product in spite of figuring out that it’s a low-quality product (whereas protecting their fingers crossed and hoping that their buyer is not going to understand that),
• Not delivering in any respect what they initially thought was a reasonably good product however turned out to be a harmful and embarrassing minefield.

Wouldn’t it have been higher to begin testing earlier? Ideally on the identical time different actions (coding, enterprise evaluation, and so on.) have been being carried out.

Making unskilled folks check

That is most likely essentially the most controversial level to cowl, as a result of sadly fairly widespread development/misunderstanding that testing ought to be all people’s duty.

After greater than fifteen years working with software program, and greater than ten as a tester, I nonetheless battle to know what makes some folks imagine that software program testing is so completely different from all the opposite issues that may be wanted to implement a software program product (enterprise evaluation, software program structure and design, coding, and so on.), that it may be carried out by anyone.

I’m wondering, although, if certainly not would you wish to make unskilled folks code, why do you have to need unskilled folks to check?

You could suppose ignorance about software program testing might be one of many causes behind that.

However, lack of understanding about coding doesn’t normally make folks imagine that anyone can code: really, fairly the other.

So, why underestimating software program testing is so well-spread appears to me a very difficult conundrum to unravel.

Throw the same old misconceptions about Agile into the combo and also you’ll have a recipe for catastrophe: folks saying that, with a view to be extra environment friendly at testing, all it’s worthwhile to do is to automate (the execution of) your check circumstances, will ship the ending blow to your software program growth course of.

What’s extra, unusual as it could sound, fallacies about such an unlucky self-discipline are sometimes unfold not solely outdoors the software program testing group (the place we are able to assume there may be a by some means affordable lack of understanding) but additionally contained in the group itself, which appears to be tormented by a harmful combination of Dunning-Kruger impact and numerous mythological Trojan horses.

The factor is, making unskilled folks check normally means settling for confirmatory testing, that’s to say, demonstrating {that a} software program product does what it’s anticipated to do, with out caring in any respect about exploring a system to study the way it really works or investigating below which circumstances it’d fail. And sure, that is what software program testing actually is in any case, isn’t it?

Alternatively, it must be observed that even a normally expert particular person may be unskilled in some unspecified time in the future: in the event that they constructed the software program product themselves, for instance, they’ll more than likely lack the essential distance required to deeply and unbiasedly check the product itself, which is what you want while you actually wish to uncover unanticipated issues, don’t you?

Wrapping Up

Wrapping up, by way of this piece of writing, I made it clear that, to me, Agile Testing has nothing to do with unreasonably quick, meaningless, reckless, late, shallow or uneffective testing (or, possibly even worse, with no testing in any respect).
So, in the event you suppose Agile Testing doesn’t give you the results you want or it isn’t offering you with the outcomes you have been hoping for, properly, likelihood is you may simply be getting it unsuitable.