Everyone Wants To Test

You are new to testing. You are sitting in front of your computer staring at the software code you need to test. What do you do? Let's look at testing from a very basic level and maybe this will help you make progress. If you don't "get it" at this level, you should consider spending more time training yourself at being good at testing skills.

 

You need to come up with ways to break the software UI or code you are looking at. How are you going to poke holes into it? The simplest tests are validation tests where you make sure everything looks correct. But that's not where the fun lies. You want to try the unconventional - the unintentional actions of the customer - and isolate those for repeatability. Everyone has the ability to test, some just don't understand that they have this desire. Trying to break software that is sitting there so shiny and new on the computer screen in front of you is rebellious, totally going against the norm. Have you ever sat in a library and thought about yelling? How about shaking up a soda can before opening it? There are many "rebellious" actions that aren't truly rebellious, just fulfilling curiosity. If I yelled in the library it wouldn't be to get in trouble, but to witness the reaction to the yelling and see how the situation changes. If you shake up a soda can, it's not to spray sticky soda all over you, but to challenge yourself to see if the result is expected. And then to try different approaches to see if things change - what if it's a bottle instead of a can? What if you shake it just a very little bit? What if you shake it a lot and then wait a long time before opening? Oops, it's hard for me to stay away from the questioning involved with testing an approach. If you do this commonly as you go through life, you are a tester.

 

The basic concepts of testing are found in our elementary schools, they just aren't yet called testing. Think about science class, when you had to create a hypothesis and then do experiments to prove whether are not it is true. This is similar to a tester who creates test cases and then executes them to prove whether or not they are true. If I do X, I expect Y to happen. If Y doesn't happen, I found a defect in my software.

 

Where else does testing become fun in our lives? Have you ever played a board game? What about one of those like Jenga or Don't Break the Ice? The whole game is based on testing! If I hit that one ice block, will the guy in the middle fall through the ice or not? Those initial ice blocks are like validation testing, you can hit them out and the guy won't fall. But do you really know which remaining ones are safe to knock out? You are testing the physics of the game. You may even call those boundary cases. As the user of the game, you are the customer trying to make it through without losing. Similar to a software customer, you think your actions are valid and will produce good results. But when you try something unconventional (like knock out that ice block that is holding everything up), what happens? In these games, it is fun. In the software industry, it's also fun if you are the tester and not the customer! What ice blocks should you hit in the software you are testing to make everything fall down?

 

Let's face it, everyone does testing and some people, whether they call it testing or not, actually enjoy it. Everyone wants to have the freedom to be destructive, rebellious, and spontaneous, to go against the norm, and to try something unpredictable. The great thing is that in the software industry having that desire lands you a job in testing software, proving that the software keeps working after you do something unconventional to it, after you shake it up, after your next action is not exactly what was predicted by the software developer.

 

So for anyone out there who doesn't think they know how to test, doesn't want to do testing, or doesn't think it's important, watch your actions for a day and you may just find that you do way more testing than you ever thought. So you are staring at the software you need to test, what do you do? Go be rebellious and unconventional! I give you permission!

Comments

• Anonymous
  November 11, 2010
  get familiar with the software, just through knowing which button does what check for user interface standards (small text, cluttered design, typos) basic standards, like sorted lists, .... try breaking the software (dont fill mandatory fields, fill with wrong data, click buttons randomly,....) - best part dig deeper into data/database/rules/bus. requirements.

• Anonymous
  November 11, 2010
  Great article

• Anonymous
  November 11, 2010
  I actually like doing functional testing. Clicking on button 1, when I was supposed to click button 2. Type Y, when I was supposed to type X.Try to save when a comboBox has selectedIndex == -1.But I find doing formal unit testing very boring. Sometimes in a case like this:public int GetNumber(){    return 1;}I actually need to do the unit testing for that, even when I know that there is no other possible outcome, just for the formality's sake. I hate that and many most cases where unit testing fits in.What kind of category do I fit in?Ah, and great article by the way.

• Anonymous
  November 12, 2010
  Fabio - based on your first examples, yes, you definitely have the attitude of a tester.  Sometimes there are tests (unit tests and/or validation tests) that can be boring from the standpoint of being repetitive or having minimal value to run through.  For any tests like that, you should make sure you are prioritizing all your testing work and hit upon the areas where the testing is the most needed and there is the largest return on investment.  If your formal processes require that these tests are created and executed, perhaps those are of lesser importance than others and that should get communicated.  I have seen projects where everyone follows the formal processes and the common path through the software is flawless.  Only as the project team gets close to shipping do they find more bugs in the least common areas and that causes the project to slip or the product to be shipped with lesser quality.  That's why this idea of trying to break the software by doing this ad-hoc testing is important.  A good balance between formal processes and having fun exploring and break the software is required to have a product with good quality.

• Anonymous
  November 15, 2010
  Thank you for your response. I guess that my attitude helps me delivering software with a low bug rate ;)Kind Regards,Fábio

• Anonymous
  November 25, 2010
  Good article to start of testing. And as mentioned its the surface of testing which is scratched in this post. Hoping to see more posts with subject deepening.Thank you.

• Anonymous
  December 08, 2010
  thanks alot for explaining it from basic now i know what is testing exactly