Come to the Dark Side - We Have Cookies!

It was recently suggested to me that QA folk are 'evil'.  Evil on the order of BEELZEBUB.  Evil... on the order of Sith Lords.   For those reading this that need a little extra help - this would be the bad guys in Star Wars.

Now, of course this was in jest -  but it brought up some interesting points that I'd like to explore.

With all of the accusations that we like to throw back and forth between teams of wrong doing -   which team, Dev or QA (and including Support here), really is closer to being in tune with the Dark Side of the Force?

The incident which spurred this conversation had something to do with my unfortunate glee in finding a bug one day.   (I really don't intend it to come across that way.  I was happy to have done a good job in my QA sphere - not delighting in having discovered a deficiency.  -  this really needs to be a blog post all of it's own, though.   I digress... )


Development likes to view themselves has brave Jedi masters - fearlessly slaying requirements with their brilliantly written code.    They are knights - they are heros.   They are the true Jedi and must get their pure code past the Evil process and scrutiny of the QA Lords.  QA  sits at their desk cackling as they rack up the bug count to meet the bug quota that on one will admit exists.  (It doesn't exist)   QA  taps the ends of their fingers together as they devise new and painful rules to impose in the name of  structure and 'process'.   QA is pure evil.

QA (and our Support friends) will counter we are the true Jedi because that we have to defend the universe from evil bugs in the code.   We must find the issues before they would reach an end user and thus destroy peace in the galaxy.   We must ensure that Development does not attempt to use their mind tricks to divert us from asking for the required documentation.   Development, in this view, sits shrouded in mystery in dark rooms spinning spaghetti code and unrealistic release dates.    All the while, slipping in 'just one more feature'  that must be tested without affecting the deadline. 


So where is the score?  Who really are the evil ones here?  Who really deserves to be the true Sith lords and who gets to be the Jedi's? 

The answer should be clear.



NEITHER!


 WE ARE ON THE SAME DARN TEAM.   We are not fighting against each other.  We are all Jedi (or maybe all Siths...depending on the mood we're in).   In the end  we all contributed to the destruction Death Star and we all get to party with the Ewoks.

So,  let's save our energy to and focus on the real evil in our midst -  3rd Party Vendors,  Auditors... and occasionally Project Management (sorry guys...;))

Since today is Halloween  I 've decided that the team we ALL are on is the Dark Side -   So... with that in mind... if you're in the office today come by my desk... we have cookies!

Stray Cats and The Cat Lady

I coined what I *think* is a new term this week -  Stray cat apps.

You know... those mangy apps (or servers,  *sigh*)  that no one wants to work on. Every so often I go to my door and find another one there... sad and starved.   The little wretches have been kicked around the team from developer to developer or from QA to QA until some poor sap takes pity and starts feeding them.   After a while those cats become yours.    

I think we all have accumulated one or two of these beasts.  But lately  I'm starting to feel like maybe I've let myself become the crazy cat lady... 

These are a few of my favorite bugs

In the sometimes hum drum world of TPS reports and status meetings testers take their entertainment where it comes to them.  
I present some of the bugs that make me giggle when I find them :

1)  Bad grammar errors - and naughty grammar errors.  It's always a treat to stumble across some forgotten bit of code that pops up a poorly worded message that a developer never intended to see the light of day.   Sometimes it's just some text that never got edited...sometimes it's an expletive hidden in a pop up – and sometimes it’s a fantastic combination of bad grammar and desperation in an error message letting you know that  if you've managed to get yourself into this broken state " Your screwed buddy".

2) Data truncation errors -  this is the equivalent of shoving firecrackers in a watermelon.  It's a crude sort of bug - there is nothing clever about typing a bunch of characters into a field and pressing submit -  but sometimes it's just fun to watch something explode.

3) The Highlander Principle of Pop up Windows aka "There can be only one."  -   This applies to any bug managing the parent/child relationship with pop-ups.   Mostly I just like finding these errors so that I can use that title in the bugs.  It separates the wheat from the chaff,  if you know what I mean.


4) "I reject your reality and substitute it with my own" (See MythBusters) -  I dub any bug this when it appears to the user that the system just ignored their input and just went and did whatever the heck it wanted to .  Often fun browser caching bugs will have this effect. 


5) The spastic clicker error -   Any time you can resubmit a form by clicking a button more than once.   I loved it when I found this one in my banking software.  After I paid my car payment...twice.   Here is the problem - EVERYONE STILL DOUBLE CLICKS.    It's not *just* spastics... we all do it.  I know, I know... it's a web web web web world...and we should all know that only a single click is necessary for all things web.  The reality is, people double click.  It was bred into us in elementary school computer lab and we are all doomed and / or overly caffeinated.    Even my 4 year old this morning told me that 'If it doesn't open you have to click 2 times really fast'.

You HAVE to protect your apps from people abusively clicking!  And you can't do that by just putting up a neat little sign that says 'please do not click more than once'.



What are some of your favorite bugs?

Exploratory Testing aka Pirate Testing

As Promised - here are the slides from our meeting today.

Gary decided we should call exploratory tests 'Pirate tests' because you're using more of a 'Guideline' than a script. :) Thanks Gary!

Connie made the point after the meeting that she hopes we'll use these approaches to help us get out of the tunnel vision of only testing the specific bug we're working on. I didn't make that point as clearly as I would could have in the presentation.


One last thing... keep in mind I used a lot of information from various sources. Not all of them are noted in the slides but they are all listed at the end of the document.


Enjoy!


Link to a PDF of the presentation

Darn Cheating Gamers!

We asked around to find out what the philosphy of our co-workers was when it came to using cheat codes in games. The results were quite illuminating :




There seem to be two main groups - those who use cheat codes (for a variety of reasons) and those who think using cheat codes is...well... cheating.


One interesting thing was the same justification was used by two people for opposing view points. One said that "Developers designed the game to be used without cheats, so that is the only right way to play it" the other said "Developers added cheats to the game, so they must intend them to be used"

No-one was willing to admit to EVER using cheats in multi-player scenarios - unless, of course, the game was defined as a 'no holds barred' cheat-o-rama. Even then, the purists among the group were opposed to the idea.






We found as we collected responses that we had to protect our sources a bit. Those who feel most strongly about not using cheats were very interested to know who was on the other side of the fence. It started to look like someone might get beaten up - or worse, fired.