preload

More on Unlearning

Posted by Albert Gareev on Jul 22, 2010 | Categories: HeuristicsNotes
Master Yoda teaches Luke Skywalker

Image courtesy: starwars.wikia.com

You must unlearn what you have learned.
Master Yoda to Luke Skywalker

Although Unlearning is not a testing heuristic itself, I found it very helpful in many activities – from testing and test automation to problem solving and management. That is why I wrote about Unlearning on quicktestingtips.com.

Yet I wanted to share even more about Unlearning, applied to testing, and beyond that, so here is my today’s post.

Test Requirements

It’s nice when you have detailed test requirements which instruct you to verify that an application works the way it meant to do. But keep in mind that users don’t always read guides and instructions (or might even say – never read), so unlearn “right” user habits and try to do same tests in a weird manner.

Test Management

There is a long time known IT joke saying “Project Manager is a person who thinks nine women can deliver a baby in one month”. The idea of replacing experienced staff with cheap, unskilled resources, supplied in great numbers, with a hope that the same results will be achieved at low costs, still lives. However, if you want to unlearn it (or convince someone), I suggest you reading “The Taylor Termination Programme” story published on polite-unlearning.org web-site.

People were taught to believe in numbers. If your approach is “metrics first”, you may want to know that you will die from tomatoes. Surprised? Read the following case study – “The Dread Tomato Addiction“.

Testing

Unlearning and re-learning testing habits could be fun.

Used to navigate through an application with mouse only? Try keyboard shortcuts, Space/Enter instead of clicking, Cut/Paste instead of typing, holding Ctrl/Shift during GUI manipulation.
(One of little tricks here is that modern software has a lot of functionalities built-in by default. Operating in an unusual way you trigger them, or you not trigger pre-programmed event handlers thus affecting inner flags and counters in a program.)

Breaking sequences and not following assumptions is another way. Try performing an action before or after it’s expected, double-click instead of single click, manually pasting urls instead of clicking navigation links, Undo/Make changes/Redo cycles. Rename binary file to txt extension and feed it into your application. Change XML tags. Try French or Chinese input instead of English characters.

Parallel or reversed work instead of sequential. Here we have a variety of options; below I gave just a few examples that helped me exposing bugs in the past.

  • Save / submit data (file, report, web-page, …) while requesting it as another user
  • Send / request data and disconnect session before receiving a confirmation)
  • Delete (to Recycle Bin) a named item (file, web content element, etc.), create a new one with the same name, and try to restore the deleted item
  • For scheduling and filtering functionalities, change computer dates and item dates

 

Test Automation

A successful test automation engineer must be proficient both in testing and programming.
However, design of testing scripts requires unlearning from both tester’s and programmer’s habits.

That is, the following should be unlearned:

  • automated testing is execution of testing scripts
  • testing script should mimic tester’s actions
  • testing script is a program that drives another program

 

Further reading

Unlearning101 by Jack Uldrich


  • One response to "More on Unlearning"

  • sitcomfan
    9th August 2010 at 18:26

    You have a way with writing, but remember by and large, language is a tool for hiding the truth

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.