Video: The Evil Tester’s Guide To Evil – Alan Richardson
“Have you ever heard someone say that “System Testing is a necessary evil”? Well, what they don’t tell you is that “Evil Testing is a necessary system”.
And will THEY ever tell you that? No!
Why? Because THEY don’t want you to know.
Only I will tell you. Because I want you to grow.
I want you to be the best tester you can possibly be. Why should you settle for being a good little tester? You can be better than that. You can experience the freedom and possibility for growth that comes from adopting lessons from the Evil Tester System of Evil Testing.
Too often people think they are advancing by following a well trodden standard path. It seems like the right path. Everyone else is walking it. I walked it too.
And I want you to explore the other path. The left hand path. The path that THEY are too scared to walk.
Yes, the information I’ll give you comes with danger. Be aware. These lessons do not offer an easy route to testing conformity. Instead they offer you the chance to build your own system.
I’ve spent years reading and studying forbidden texts. All so that you don’t have to. And now, I am prepared to share some basic precepts derived from those studies, illustrating how I have used them to change my testing, and how you can use them to change too.
Likely precepts include:
No-one is born evil
Benefits of a bad attitude
As Simple As Sin
Now, Now, Now – when to favour instant gratification
Nothing is True, Everything is permitted
One road to heaven, a thousand roads to hell
Deceive, but be wary of self-deception
What did you expect? The door wasn’t locked.
Having a tough time describing just what it is you do? Skillcrush has a half way decent definition you can send to non-technical family and friends.
You don’t need to know how to code to be a good QA analyst but it’s helpful to have a better understanding on how websites work.
Here are some great places online where you can learn the basics for free or cheap.
Articles, comments, queries about the processes of Software Product Development, Software Testing Tutorial, Software Processes.
Not the best looking blog but has some good information.
Atlassian makes Jira the bug tracking tool most of us have heard of or used. They have a lot of great guest writers for their blog.
Writing bugs is pretty fundamental to what we do. It’s assumed that anyone can do it. If you’ve ever tried to verify a bug written by someone else you know that’s not true.
EXAMPLE:
Text too big
Yes, this is an example of a bug that I had to confirm. That is a horrible way to describe a problem. How big is too big? It’s smaller now. Do I close it? I guess I should ask someone. Oops that person went home and we deploy in an hour. Crap.
A bug should be able to be basically understood by anyone of any skill level.
There are many different styles of bug writing but this is what works for me. I’ve gotten positive unasked for feedback from various developers (including non-native English readers) on the style which I consider a complement and a reason to keep using it.
Bug tracking software can differ quite a bit but they usually include a subject/title, severity, and body/description. I’ll limit my suggestions to just those areas.
1. Title/Subject - The title of the bug should contain enough information to let someone know where the defect is as well as a general idea what it is. A bug on the Front End for example should include the page, the component and a short description of the problem in the title of the bug. This is helpful when looking at a list of bugs. Someone doesn’t have to click into each one to have an idea what it’s about. It’s also handy if your system email updates.
EXAMPLE:
Homepage - Header - Log In Text Box - Can’t enter text
2. Severity - In my mind there should only be three. Semantics aside they should be something like Major, Minor and Critical. The system I am currently using has seven. I believe this adds more noise to the signal and leads to confusion and inaction. Really what’s the difference between Minor and Trivial? Ideally the severity definitions are documented on a company level or outlined in a Test Plan. However, in my experience you can’t rely on people reading them. Chances are good that they haven’t or even if they did they haven’t memorized them. Make it easy for everyone and keep the choices limited and easily understood. That way everyone has a clear idea what you mean without a lot of explanation. This will also lead to more trust built between team members so when you write that critical bug they know you mean business.
3. Body/Description - I always include expected, actual and example in clearly labeled sections in each bug I write. The order isn’t really as important as making sure each section is in there. Yes, I actually label each section each time. Depending on where you work you can’t count on the same person reading your bug each time who automatically knows what you mean.
- Expected - This is what I thought was going to happen. This can be taken from the requirement document, test case, or just written out. As long as it’s clear.
- Actual - This is what actually happened being as descriptive and full as information as possible.
- Example - This can be steps to reproduce, a portion of your test case, an annotated screenshot or a screencast video (A tool like Jing makes it easy) Whichever type of example makes it easy for someone to understand the bug. In this section I also try to add a link back to the problematic page. It’s another level of confirmation as to where the bug was but most importantly it makes it a lot easier for you (or someone) to confirm the bug later. You can just click on the link and get to testing much faster.
EXAMPLE:
EXPECTED:
On the homepage header the text under the banner that says “Welcome” should be Arial Bold 24px
ACTUAL
Using the font finder firefox plug in it shows the text to be Tohoma 20px
EXAMPLE
Screenshot of page- (link to screenshot with arrow pointing to text with error)
Screenshot of Font Finder result - (Link to font finder screenshot)
Page - (link to page)
So this is what works for me. When I have the opportunity I make sure the team I am working with also uses this same style. There are times that your first interaction with someone is from a bug you wrote. When your whole team writes in the same detailed style you come across as profesional, knowledgeable and trustworthy. This can lead a smoother and more enjoyable project and for everyone.
What technique and style have you had good experiences with?
