I’ve done quality assurance (testing) on several software development projects and have learned a lot about testing along the way.  Though there is a lot to consider when testing software I’ve found that many of the practices are useful in everyday life (even if they seem a little OCD at times).  Here are 4 types of tests that are critical to software testing that can also be very effectively used in everyday life.

Positive testing is the most basic type of test; perform a test that proves the software works.  If I’m testing a text field on a form that is supposed to accept letters, but not numbers, a positive test would be to enter letters into the field.  This positive test will show whether or not the field completes this basic requirement.

In life you perform positive tests all the time simply by trying to use or access things in your environment; every time you flip on your light switch, change the channel on your T.V., or start your car you are performing a positive test.  If your car doesn’t turn over when you start it then the test has failed and you know something is wrong with your car.  If you turn on your Teddy Ruxpin and he starts telling you stories while creepily blinking and making you feel uncomfortable, then you know your Teddy Ruxpin is working.  Positive testing tells you something works like it is supposed to.

Negative testing looks to see if the software can gracefully handle invalid input or unexpected user behavior.  If I’m testing that same text field mentioned above that is only supposed to accept letters, my negative tests would involve attempting to enter numbers, special characters and spaces.  The positive test first checked that the field accepted what it was supposed to, the negative test then checks that it properly handles and does not accept what it was not supposed to.

In life negative testing is a bit rarer and less thought about, but still very useful.  Let’s say you are staying at a hotel that is a little shady, but they provide safes in the room for you to store your valuables.  So, let’s then say that you setup the safe to unlock with the pin code 1-2-3-4 (which is a terrible pin by the way please don’t use this), the positive test would be to check that, prior to putting your valuables inside, you are able to use the pin code 1-2-3-4 to unlock the safe; the negative test would be to verify that using the pin code 4-3-2-1 or 1-1-1-1 does NOT unlock the safe.  Now you can be assured that your valuables will be safely stored and relatively certain that only your pin code will unlock the safe (of course you can’t be 100% sure unless you try every possible combination, which I also would not recommend, unless you want to spend half your 2 day vacation in Vegas hanging out in your room playing with numbers that don’t pay out when you could be hanging out downstairs in the casino playing with numbers that don’t pay out).

Where positive testing often fails is when you assume something works because it worked previously.  This is where regression testing comes in.  When you perform a regression test you are checking that features and functions of the software that worked previously still work.  You generally perform these tests after changes have been made to the software and prior to releasing the changes to the public because any change in the code could possibly break existing code.

In life regression testing is very important.  In fact I used it recently to save myself a bit of a headache.  I had recently booked a car rental online for a decent price.  I input my pickup date and time, Dec. 10^th at 6pm, along with my preferred pickup location.  I wasn’t completely familiar with the area and after doing a little more research found that there was a pickup location closer to the airport than the location I had previously selected.  Luckily, the website allowed me to reopen my reservation and change my pickup location.  While waiting for my flight at the airport I called the car rental place to confirm my pickup.  I already had my reservation set and email confirmation sent to me, but I wanted to make sure I would have no trouble picking up my rental car.  Upon calling the rental car company I was informed that the location I had chosen to pick up the car at closed at 5pm.  Even though I had entered 6pm on the website and assumed there would have been some sort of catch in the system that would prevent me from attempting to make this impossible pickup, I checked on the reservation anyway.  The lack of testing performed by the website developers for this car rental company was of minimal hindrance to me thanks to my own testing.  Though, if I had gotten that new flux capacitor for my DeLorean on time none of this would have been a problem.

Smoke testing is performed after a new software build is made available to check that the basic and most critical functions of the program are still working just fine.  Starting with the most critical functions ensures that at the very least the core of the product is working and stable before you spend time checking on the smaller assets of the software.

In real life it is always good to perform a smoke test after you fix anything in your house or make changes to something you often use.  A timely seasonal example I think most people can relate to are holiday lights.  Your lights may have worked just fine last year, but this is a new year and you should never go through the exhaustive effort of hanging up your elaborate holiday lights that flash and blink in a choreographed light dance to some rockabilly version of Jingle Bells prior to plugging in said lights.  You may plug them in and find half the string has burned out and that you either need to replace some bulbs or buy a new string.  Smoke testing can save you a lot of time and effort.

There are lots of other types of testing and different factors to consider when testing in software and in real life, but I hope this gets your mind thinking about how you can use testing in everyday situations to make things easier and more effective for yourself.