Test Positive

If a non techie asks a tester what do they do, you can expect an answer like "I find problems (bugs) what other people create". Well is that testing ?


As per dictionary.com the meaning of the word test is
noun

1.

the means by which the presence, quality, or genuineness of anything is determined; a means of trial.

2.

the trial of the quality of something: to put to the test.

3.

a particular process or method for trying or assessing.

4.

a set of questions, problems, or the like, used as a means ofevaluating the abilities, aptitudes, skills, or performance ofan individual or group; examination.

I don't see the world bug, problem, failures etc in the above statement.. But somehow many of use managed to make testing more about finding problems than anything.  Hence questions like did this build pass testing.  And testing becomes a gate that stop bad things from going out the door. Something that delays the release of the product.  Some laborious thankless job that gets done after the developer tosses things over he wall grudgingly.

That brings us to the term quality assurance.  This term is about enabling, about problem solving and helping deliver something of value and quality.  Please don't get me wrong here, quality assurance will also include testing, the very important phase that helps confirm that the product is of good quality. But that is all but one portion of "Quality Assurance".

Answering Machines

Recently I interviewed a fairly experience tester for a SDET role at my company.  He has a few years of experience under his belt and seems to have a successful track record at a large software house on the east side of Greater Seattle area.  But like many candidates I have rejected before, he failed utterly on the interview day.  The idea behind this post is to remind people that we could, or might I say must, apply the learning's from one area of life to another.  In this case from one area of our professional life to another. 

As testers we are used asking questions like what if, how about this, what else etc. to almost all problems we  are given.  Discovering the details of the products by digging around every possible nook and corner is part and parcel of a testers job.  Because requirements, however detailed they are, seldom give the complete picture of the product or the problem at hand.  Even if they do the solutions people come up with regularly hide issues that are not apparent at the first glance. 

Similarly bringing a semblance of structure to otherwise chaotic SDLC is a regular part of SDET's life.  Be it implementing continuous deployment today or a writing a good old test plan. Testers add quiet a bit of structure and determinism to seemingly unwieldy problems that technology creates or solves.  So testers who practice such curiosity and discipline day in and day out, completely and utterly fail to use any of that when it comes to the interview day.  They become nothing more than a mere answering machine.  Please don't be an answering machine.