Saturday, June 23, 2012

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".




Friday, June 22, 2012

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.

Saturday, March 27, 2010

Have you tested this ? Text input fields testing.

When testing text input fields recently I missed something very embarrassing and simple. I did not test for characters like "é" in the name field. Here is an (evolving) enumeration of tests for text fields. Depending on the nature of your input field some of these tests may not be applicable.
  1. Simplest Happy Case (an average, input string, without any errors or special conditions).
  2. Does it enforce input character set limitation ?
  3. †Does the accepted character set meet the minimum requirement for the field. For example a it might make sense for description to "™", "©", "®", etc.
  4. Does the accepted character set include unnecessary characters. For example a "#" in an email input field.
  5. Are validation rules enforced correctly ? For example payment amount in an Indian site my accept numbers with comma's like this 1,00,00,000 instead of 10,000,000. Sometimes an input field might accept "-username@domain.com"
  6. Is the validation rule exhaustive ?
  7. Is minimum length enforced correctly ?
  8. Does it trim spaces (leading and trailing) before processing data ? For example it should n't say illegal input for input with leading spaces.
  9. † Is the minimum length reasonable. For example if the minimum name length of a name is 5 or even 3 it could spell trouble because some folks have 2 character last names or worse just might want to use the initial of their last name.
  10. Is maximum length enforced correctly ? Does it accept maximum number of characters ? If it persists it somewhere, does it actually save all the characters and can you retrieve those correctly ?
  11. † Is the maximum length appropriate ? For example, should the maximum length for name be 200 characters ?
this will be updated sometime soon.

not considered here: security testing.

Email input fields: on top of the above rules here are some more
  1. plain vanilla email, like YourLogin@domain.com
  2. names with ".", like firstname.lastname@domain.com
  3. domain name with more than on segment, like firstname.lastname@host.subdomain.domain.com.cc
  4. hypenated names and domains firstname-lastname@some-hyphenated-domain.gov
  5. + aliases, like YourLogin+sortCoupons@domain.com
  6. very short email ab@bc.tv
† If there were requirements this would be caught at requirements review time, in the absence of it, testers are left with this task.

Followers

About Me