Can you see the real me?

Since there weren't any negative comments regarding work posts, here comes the first.

In real life, I'm the Senior Software Quality Engineer at my company. This means I spend my time testing software and writing bugs against that software. My tasks also extend to doing light project management, 3rd tier tech support (if Customer Support can't figure it out, it goes to me - usually at that point, it's a bug that needs to be fixed), and test automation (programming).

Automation is a program that is used to test another program in much the same way a user would. I used to be a full out software developer, but due to various and sundry circumstances I ended up being stuck testing. This means that the programming aspect of my job is the one I find the most rewarding - even if I don't get to do it much.

Recently, we drastically changed how our company's software works and so about 90% of the automation I had created in Rational Robot does not work now. This means that the release I've been working on has been a pain in the butt to test, because it forces me to do everything manually. It's a slow process and I've had to pick certain things I will not test because I simply do not have the time. Because my boss flatly refused to update the support license on our test software, I will simply have to stop using that automation tool.

However, it's always darkest before the storm...err....dawn. Using the coding library "WatiN", I will be able to rebuild my automation using C#. C# is the Microsoft Language that our application was written in. Because all of the devs have Visual Studio, I can pick their brains from time to time for assistance. The OTHER nice thing about this is that it will open up my future job prospects by giving me coding experience.

But I digest...

Now, I need to decide how best to go about rebuilding my automation and where I start.

The goals of test teams, especially in small groups, is to find the important bugs fast. Lets face it, when you are using software, do you care if a seldom used portion of the app has badly formatted text, or if the main screen of the application crashes when you use the control that its raison d'etre?

What this means is that the first thing to be tested needs to be "things that are changed". This is where undiscovered bugs most likely hide. Code that hasn't been touched in years may indeed by hiding a sinister bug, but if the users haven't even seen it, it's not as important to test it as it is to test the brand new feature that just rolled off of the assembler line. Clearly though, this is not a good candidate for automation. You will need to manually test this first and start thinking about how to automate it as you test it.

The next thing you look at is a PRIME candidate for automation: Core functionality. These are the things that are the main purpose of the application. They are critical and popular. You'll be hitting this the most in your testing and even if it changes, it will usually do what it has always done so that your automation is not invalidated - or at least will require minimal changes.

So, you've figured out what your Core functionality is. How do you code for it? Starting off, create a basic framework that touches each of the areas you will need to be testing. You aren't working at creating deep functional tests, but a basic "smoke" test. For example, if you are testing a calculator function, you are worried about if it can add, subtract, multiply, and divide at all, BEFORE you start looking at all the different ways numbers can be added. Approaching your work this way permits you to have a framework which will let you easily add functionality. Here we start into test case identification, so you need to have created clear and solid test cases to start from.

More Later.