Saturday, 15 November 2014

Being Quality Conscious

It may so happen that in the busyness of trying to achieve n(insert any random number here) test case execution per day, one may lose the childlike curiosity to view a product or learn from it. Unless, we crave for newness in learning, questioning, implementing, listening and to be wowed by it - testing hasn't gotten curious enough yet.

Testing skills can be enhanced by many ways:
  1. Testing solo
  2. Pair testing
  3. Testing with a team
  4. Participating in bug bashes
  5. Reading a book
  6. Reviewing bug reports
  7. Learning from a mentor
The list is not exhaustive. We all learn from many sources and in unique ways.

What have we learnt new in testing today?
This question can haunt if we do not practice to hone testing skills everyday. Practice here can mean practicing to observe, test, listen, read, explore, record and report the findings. Testing ideas can be derived from such practices.

Expected result of a test case may seem obvious, but each user’s behavior isn't obvious. Asking a tester to follow a set of test steps and ranking him/her based on this criteria is weird in any age and time. But it has to be done, as we finally will need a winner to announce in the race.

Everytime we test, we can ask the question, what is quality?
If we tend to follow a script or are testing a product using a tool, try to add an element of "I wish and want this result from this product, feature or service".

Coding, scripting, testing with tools can help introduce the testers to technicalities of the product under test. So let us not rule out or limit learning to test using these methods.

Context Driven Testing
Introduce context driven testing to testers around you along with imbibing interest to test beyond test cases.

How would we test a product A, if there was no competitor to the product?

How would we test product A in comparison with product B(a competitor to Product A)?
Would we limit testing to the requirements specified and signed off in a meeting based on a method used to derive tests or can we extend the quality of the product by including features of product A in product B?

Does testing contextually add to the quality of the product? Try it yourself.
Diversify testing.

What is Quality?
Let us not tie quality to a definition, a method, a cycle, a phase or a methodology.

We have been speaking about, testers learning to code and coders learning to test(Devtesters). Can we as a team be Quality Conscious in our respective roles(defined or undefined)?

Who should be Quality Conscious?
Let us just remember that Quality is everyone’s concern.
We can introduce testing to the BA, Developer, Product Owner and others in the team.

Is this Testing?
Matching lines of code to a requirement or an expected behavior is a happening test in many STLC. This ascertains that there is code coverage provided and a ‘Pass’ associated with the unit tests.

It isn’t all about record and play nor about traceability(the ability to trace back tests identified to the requirements gathered and signed off at the beginning of the project) which is the norm in some firms.

Introduce the team to testing beyond requirements gathered. Learn and aid the team to add testing ideas as we(or more of us) test together.

What are the testers testing for?
Testing needs to be extended way beyond the laid out architecture, platform chosen, standards set, tools chosen and metrics used.
Branch, path, statement coverage, unit and database testing can meet business needs. Do they also meet user needs? Knowledgeable and experienced testers can come in handy to test beyond what meets the requirement document.

Share the test environment details with the whole team. Details about the device, OS, Browser, Internet(speed, package, provider,router preferences), protocol, client, server and versions used. Familiarize the team with testing gizmos.

What is the vocabulary of the team?
Does the vocabulary of the team members start with requirements gathering and end at delivering clean code?

Can we as testers introduce term ‘testing’ into this vocabulary. Thus helping the team to be conscious about Quality.
Be meticulous about the terms introduced to the technical team, introduce terms that make most sense to you as a Technical Tester, the language which developers can follow. And not ruling out the fact that other testing terms can gradually seep into the system with this start.

Learn to learn that our differences can make us a stronger team ~ Diversity Heuristic referenced from

Credit - James Marcus Bach

No comments: