This is what I do, I'm a tester

We have an application we want to create.

First we have Angie. Angie decided how the application is planned to function, look etc. based on users' expectations and demands (sometimes she's just guessing but she's good at that as well). She communicates her plan to Bob, Cody and Dora and let them have a say about the ideas. Cody is the programmer (of course), he makes things happen by writing incorrect english with very many special characters (also known as programming). But Cody needs help to make his cool stuff look cool. That's why he loves Bob, the designer. They are usually trash talking each other but deep within it's pure love.

Cody and Bob do their work based on Angie's plan but sometimes they, intentionally or unintentionally, drift away from it. Intentionally, for example, could mean Cody realizes that the plan conflicts with how the rest of the application is coded and he simply tweaks the new code to fit the old while unintentionally could simply be a misinterpretation. Also, many things are not explained in Angie's plan so Cody and Bob have to take initiatives in order to not constantly disturb Angie as well as to make their work creative and fun. Also Angie doesn't master design and code the same way Bob and Cody do so she has to trust their judgement.

Finally we have Dora. She looks at what Bob and Cody have created to get as much information as possible about the application's shape. Bad shape in this case can come in many forms (list definitely not complete):

• Stuff is simply wrong
  2+2 is not 9 and trying to login with an empty password shouldn't crash the application
  
  
• Stuff seemed good on paper but in reality it sucks
  A popup confirming you've made a change was a great idea until you updated 2000 items at once.
  
  
• Stuff is not consistent
  Angie likes popups while Cody likes CSS boxes. This can become a problem, especially when there's not one but twenty Codys, all with their own preference.
  
  
• By-products might be a problem
  A global search was a great feature until it was discovered logging in now takes 10 minutes instead of 0,3 seconds due to search indexing.
  
  
• Some desired features weren't anticipated
  "These short service messages seems really useful, maybe we should let users send them to each others?" "SMS? Useful? Well, I guess we could do that..."
  
  
• Bad people can do bad stuff
  
  Picture from xkcd.
  
  
• Stuff simply didn't solve whatever stuff was suppose to solve
  The new wizard (not the cool magical kind, the nasty GUI kind) was suppose to simplify the creation of new documents but now the user is presented with so many options they could earlier ignore it's just insanely complex! What a heck is document structure template, I just want a new document, damn it!

Dora looks for all this to help Bob and Cody (and Angie) look good so that users (and managers) won't come with pitchforks trying to end their lives. She also helps stakeholders like Angie and others make better decisions by providing them as much valuable information as possible about the application's shape. To make sure good decisions about the application can be made it's important Dora, just like Angie, is a great communicator.

Some people think Dora's job is about making sure 2+2 is 4. They are the same people who wouldn't care if the meat they buy is rotten as long as it's packaged according to spec. Others think Dora is a sadistic mistress, which she might be, but not during working hours. If she was she would just stay quiet about problems found and see the programmers run in panic as users storm the building with their pitchforks.

- You just want to see stuff break, Dora!
- No, but I rather see it break here than in the face of thousands of users

I'm Dora! Or well, I'm not, but this is what I do, I'm a tester!

Improving value from reading pt1: The School for Skeptics

Intro
"Improving value from reading" is a new series in this blog that I hope will be successful enough (as in value for me) to not just make it past the first post.

Some background...

One of many observations during my 2012 reflections was I didn't seem to get much out of reading books. In this series I will try to use/apply the content of what I read to hopefully change that.

The book
First out is the Swedish book Skeptikerskolan ("The School for Skeptics"). This book is divided into two parts, first an introduction to fallacies with examples when a practical part with illustrations of how to practice skepticism when discussing religion, politics, news etc. I will only focus on the first part by providing test related examples for each fallacy in the book.

For those of you familiar with skepticism, please help me correct my examples as well as my English translations of definitions and how they are used. I've tried my best but don't want to spend too much time just getting the translations correct.

Fallacies

Appeal to Authority
There's no value in certifications, if you don't believe me just listen to Michael Bolton!

Personal Attack
James Bach is a high school dropout, he's well over his head trying to challenge well established test methodologies.

False dilemma
Either we have test cases or we'll have no idea of what's been tested!

Appeal to consequences
I clicked the login button and everything crashed so there's something wrong with the login code.

The straw man
Exploratory testers just care about their own work. From their point of view no one else should know anything about the tests or testing status.

Argument from ignorance
We've never figured out why the node is crashing but it must be due to some OS bug.

Personal incredulity
I can't see how this patch would cause the performance issues we see, it must be something else.

Tu quoque
The senior testers don't care about following the test process so I can ignore it as well.
Comment, seems like the definition online for Tu quoque doesn't correspond well to the explanation in the book (but the term is used), is this a valid example?

Does not follow
We found a lot of bugs testing the user administration, there's no use to continue testing, this piece of software is just crap.

Final consequences
We need to embrace context driven testing if we ever want to reach an efficient test process.

Begging the question
Test cases makes our testing better so we need them.

Simultaneous
During traffic there is often screen flicker so they must be related.

Confusing currently unexplained with unexplainable
We've tried various ways to replicate the bug but failed, it's irreproducible.

Slippery Slope
They're trying to automate the smoke tests, soon we'll have to write automated scripts for every test we do.

Ad hoc explanation
- TMap can't improve any test process
- It improved my team's test process
- It can't improve any professional test process

No true Scotsman
- TMap can't improve any test process
- It improved my team's test process
- What you call test process is not really a test process

Argument to the stick
If you don't document your tests this project will fail miserably.

Appeal to Popularity
With over 200 000 certificates issued there's no doubt ISTQB is a must have for testers.

Appeal to Nature
Exploring software is just the natural way to test, it must be more efficient.

Guilt by association
Stop questioning his ideas, don't forget he was the brain behind both our previous successful releases!