Today I want to present a non-technical advice: unlearning.

The traditional definition* of unlearning stands for giving up present habits and/or knowledge:

–verb (used with object)
1. to forget or lose knowledge of.
2. to discard or put aside certain knowledge as being false or binding: to unlearn preconceptions.
–verb (used without object)
3. to lose or discard knowledge.

_____________________________________________________
* -Taken from Dictionary.com

As we can see from this definition, there are negative and positive sides of unlearning.

How to benefit from unlearning?

• Use it as a brainstorming tool


• Use it as a problem-solving tool


• Use it for retrospective analysis and learning

As an example, below I put a few core assumptions about software development and testing that have already been unlearnt or currently being unlearnt in the industry.

• One needs requirements and test cases to do testing


• Testing can only be conducted after a build is deployed on test environment


• Verification tests passed -> no bugs


• A role of written documentation is critically important in software quality assurance


• Software quality can be unambiguously defined by requirements


• No bugs found -> no bugs in software


• No bugs in software -> customer satisfaction


• Programmers do programming, testers do testing


• Years of experience with tools, or techniques, or technologies is the most important hiring criteria

Image courtesy: theinspirationroom.com

 

Sometime ago I wrote about a quick way to shutdown a hanged application.
But, in fact, shutting down a working application could help you exposing certain types of resource management defects. This is how ends become means.

Sample tests, suggested below, were tried on different Windows Desktop applications, sometimes helping to reveal serious issues.

Local Tests

• Start an application. Begin working process then shutdown the application in the middle of it. Start the application. See if it reports than the previous session wasn't properly finished (and does it suggest something about it, like "start in safe mode").


• Start an application. Begin working process then shutdown the application in the middle of it. Start the application. See if it can access any previously opened files, and how is it handling and reporting the issues.


• Change settings in an application, apply changes. Shutdown the application. If the application saves settings only at exit point, all changes will be lost.


• Change settings in an application, apply changes and shutdown the application simultaneously. Start the application. See if it can access configuration files, does it report that they might be corrupted, does it suggest repairing them? (you can also try corrupting the files manually).


• If an application allows running 2 copies: open 2, then shutdown one of them. Observe behavior of the remaining one.

Server Tests

• Start a client. Shutdown a client. Try to login as the same user: a) immediately b) after a timeout given.


• Start a client. Shutdown a client. Repeat this process (you may want to automate that) while monitoring how Server side of an application allocates and releases (does it?) RAM and hard-drive resources.


• Start a client. Shutdown a client. Repeat this process (you may want to automate that) for a while - you may see errors like "max number of connections exceeded", etc.

Let us know results of your exploration.

Jakob Nielsen, one of the world's top experts in user interface design and application usability, was once already referred in Quick Testing Tips.

In today's tip I want to bring readers' attention to Usability Heuristics as ready-to-use test oracles. Please read entire list via the link provided, I put here just one as an example (per author's copyright requirements).

User control and freedom
Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Whenever you implement automation of GUI steps, suggested heuristic might help you to keep track of operations you need to code.



(click on the picture to see mind map in online version with expanded nodes)

SEED NATALI acronym stands for the following.

• Synchronize till object


• Exists


• Enabled


• Displayed


• verify Number of Arguments


• verify Type of Arguments


• Log test flow


• Investigate any issues occurred

Here's how I can tell I need help:

• I'm working at 1:00 AM and it's not because it's required (like some performance testing) or because I really like doing it (too much cool software and not enough daylight time).


• People are talking about something that needs to be tested and I can't follow the conversation (due to a lack of domain knowledge or technical knowledge).


• I'm missing deadlines (for the project I'm struggling with or for other projects because I can't get away from the project I'm struggling with).


• I'm not happy with the quality of my work.

If one or two of those happen for a short period of time, I probably need help. If all of them are happening (like they are right now), I know I need help.

When you need help, ask for it. That's easy to say, but hard for a lot of people to do. I know it's hard for me. I also know it's hard for many people who've worked for me. For me, it's an ego thing. But sometimes I need to recognize that I'm not helping anyone (most of all myself) by trying to hide the fact that I need help. Often, help is there - ready and waiting to be had.

If you're overwhelmed, ask for help. You might be surprised where it comes from.