The Testing Corner

Do you love writing software? I love breaking it…

What is testing?

by Gema on August 30, 2011

I would like to give a brief introduction to testing as I see it in the first post. I know that when I say to people I do software testing, the first thing that comes to their mind is one of these two:

  • How boring, pressing buttons all day.
  • How cool, being able to test computer games all day and play non stop!

Neither of those views is completely accurate and the job is sometimes boring and sometimes very cool. You need to be able to do coding, to understand how software is created, designed, submitted and released, and most importantly, you need to be able to distinguish between correct behaviour and incorrect behaviour.

What makes software behaviour correct or incorrect is something open for discussion in my opinion, but I would say that when a feature works as expected by an average user, then its behaviour is correct. Formally, when a feature works as it says in the documentation (and the documentation answers all that was asked for in the requirements), then the behaviour is correct; my only problem with this is sometimes documents say weird things. So I think test/QA people should be involved in reviewing engineering documents (requirements, designs, specifications, API definitions) as early as possible, to help correct ambiguities and shape software towards testability and usability.

My main duty as a QA Engineer is to help ship a product that is better than if I weren't there doing my job. Products always ship with defects/bugs on them, they key point is not necessarily to fix them all, but to make sure as little as possible escape the testing and go out undiscovered. The ones that threaten security, data integrity or main functionality need to be fixed before releasing, the minor ones are not as critical. It is QA's responsibility as well helping put in place the right controls to avoid introducing those problems in the first place.

The earlier you find a bug (i.e. by writing properly a requirement or a design document, or discovering it before the code is submitted) the cheaper it is to fix.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>