The tester’s task was to formally document their testing effort using a test case repository tool. To do this they used their memory and experience of using the system to write out in more detail the test steps already performed. The tests were already executed, and bug reported. This was just a documentation exercise to capture the tests, for future use.

The testing performed was done using charters in an exploratory manner. The tester was left to learn about the product feature and build up a group of tests. They came up with many tests, including the following. They knew what each meant, but there was too little detail for them to be reused.

Test Idea: Logon
Tests:
1. Known bad password
2. Invalid password
3. No password

And each of the above were supposed to be split out so anybody could pick up the tests for next time. Ambiguity was to be cleared up, and greater levels of detail added. The intended detail was something like below.

Title: Log in to app with known bad password
Preconditions and Setup
1. User is general user, with general roles and permissions
2. Site is \\testserver\mainbranch\Application3.0\Login.htm
3. OS is Win64b Pro
4. Browser is FF9
Test Steps
1. Go to login page
2. Enter known bad password eg notmypassword12
3. Press Enter or click on Log On button
4. Wait for response
Expected Result
Error message saying “bad password” will appear

This would have to be repeated for each of the three tests they outlined (bad password, invalid password, no password).

But the tester did this:
Title: Log on using various passwords
Preconditions
1. User is general user, with general roles and permissions
2. Site is \\testserver\mainbranch\Application3.0\Login.htm
3. OS is Win64b Pro
4. Browser is FF9
Test Steps
1. Go to login page
2. Enter known bad password eg notmypassword12
3. Press Enter or click on Log On button
4. Wait for response
5. Enter invalid password eg !@#$%^&*
6. Press Enter or click on Log On button
7. Wait for response
8. Enter no password
9. Press Enter or click on Log On button
10. Wait for response
Expected Result
[4] Error message saying “bad password” will appear
[7] Error message saying “invalid password” will appear
[10] Error message saying “please enter password” will appear

The tester made some interesting comments.
Too much admin
The tester decided to mix up multiple tests in the one test case record. The problem in the testers mind was that they felt that there was too much description being replicated. They would have had to copy/paste the preconditions across all tests. They thought that if they combine tests, then there is less administration work.

The system will change anyway
The tester mentioned that there was little point in spending much time on the exercise as the system would change over time, and the tests would need to be checked each time for accuracy and relevance.

I wouldn’t follow this script myself
The tester exclaimed that they would not actually follow the test script. They find test scripts very boring and monotonous to follow. They find that they just read over the script, get some general ideas, and go and perform testing in their own way.

Documenting wastes a lot of my testing time
The tester estimated that they spent more time on documenting previously completed tests, than actually performing the tests themselves.

Illusion of structure
The tester confessed that they knew what they were doing was not adding much value. But they did comment that they thought management like to see tests all in one place, and in a table of some sort. The table gave the test script the illusion of structure.

Is this a disobedient tester or one trying to use their brain?

Author: Richard Robinson

And that got us thinking… what other testing animals make up the testing profession zoo?

• Possum testing – Playing dead in the headlights of process.  aka pathetic compliance
• Leopard testing – “Leopards are agile and stealthy predators”  – Wikipedia.  The stealthy tester is well camouflaged and appears possum-like to the untrained eye.  But quietly, the leopard is an agile hunter and will do valuable testing unseen and below the radar.
• Peacock testing – A deliberate attempt to wow via a magnificent display of extravagant test cases and scripts
• Meerkat testing: Always sticking your head up and being receptive to new information.  First to stand when overhearing a BA talk to a developer and go “wait, what was that?”
• Ostrich testing: Testing with your head in the sand.  If it ain’t in the requirements document, I don’t want to know about it.  It doesn’t exist until it’s written down.
• Penguin Testing: Testing in a tuxedo.  Black Tie testing.  Or Formal Testing.
• Blue Whale Tester: Big ‘fish’ but all blubber.  Has to stay near the surface lest it gets out of its depth.
• Manatee Tester: Noone really knows what they do or what they are.  They just seem to sit there
  

  Noone knows what they actually do

Have you spotted any other testing animals in the wild?

I’ve wanted an Apple ever since the original Apple II. My first Mac I ever saw was actually an Apple Lisa at my fathers design department. They were using it for CAD with a whopping 5MB Winchester drive. But the world turned out a bit differently. I never got to having an Apple II or a Mac.

Only in 2004, when we immigrated to NZ did we shell out for a MacMini and enter Steve’s world. Today we own several Macs, have had many more, have iPhones, iPods and are 101% Apple followers. We’ve never looked back.

But what has that got to do with a testing?

As it turns out there is/was someone at Apple which had a relentless drive for quality and usability. Now as you can easily guess that person is/was Steve Jobs (still struggling with the was here!). This drive is pervasive in all Apple products.

Again! What has that to do with my testing?

Ever since switching I have been confronted daily with something that works and gives me the power to do what I want. I have been using Windows PC’s for decades and have used Linux for nearly a decade and on no system have I felt this kind of empowerment. Empowerment, usability, friendliness, quality, ease of use, performance, craft, art, predictability and many more adjectives are what I use to describe Apple’s soft & hardware. And nobody can dispute that that is Steve’s footprint right there delivering all these things.

That is -fellow testers- what I took away, the ability to expect more. To be able to discern when something is badly made, unpractical, riddled with defects and plain unusable and to call it out. Steve has given me a new base reference I measure against. I now do care how many clicks something takes or if menus make sense or if screens and messages are understandable or not. The IT world has been badly served by most of it’s masters in that we are complacent and accept the bad quality and lack of proper thought when delivering IT to our customers. I can see it in the deliveries I get from developers. I can see it in the lack of criticism by testers. I can see it in the products that exist. No, the requirements are not the only source of truth. You are.

That means we should call out if something gets developed and is absolutely unusable or just plain wrong, even if requirements are met or the customer asked for it. Raise it as a defect! Raise a defect for things that annoy you, that you don’t want to live with. Or put yourself in the business users shoes and ask yourself if he/she would want that. Take a step back and look at the creation. Could it be better? Should it be better? Dare to ask the fundamental questions and act upon them. Steve Jobs has shown us all that thought and a relentless drive for quality can make you immensely successful. I’m not saying that all testers should now rebel against the establishment but I am pledging for common sense and reason to be used more readily and don’t be dissuaded by “it’s not in the specs/requirements/whatever”. That just means you have to find a logical, reasonable and good for the defect to be fixed (btw, one of those reasons should include why it makes $ sense!).

So that is what Steve did for me. He made me a royal -testing- pain in the bu**.

….and that is a very good thing, that I will always be thankful for.

RIP Steve Jobs 1955-2011

Author: Oliver Erlewein