Catch Up Time

You know what's good about catch-up time? I get to do things that I normally don't get time to do. You know what's bad about catch-up time? I'm sick right now. Snot is dripping out my nose like water through a facet. It's the end of winter, shouldn't all the colds be leaving now? One of the tasks which I enjoy most of the time during this in between time is working on an automation script in order to make my testing life more efficient.

There are certain areas in software which can always be automated. For the most part the areas include the command line interface(testing to make sure the output is whatever is expected from the input), stability testing(graphing cpu, memory and other hardware related stats over a long period of time and an average load), and performance testing(graphing performance metrics such as memory and cpu over a short high load time). I won't go into details on any of them because this post is probably not entertaining what so ever. I'm not going to lie, programming is not the most exciting topic in history.

But, since this blog is about me, and i'm writing it...a bit of history about myself. I took programming classes in high school where I learned archaic languages such as turbo C, visual basics and Delphi. Then, in Computer Engineering I took classes in C+ and a bit of Perl. Unfortunately, it was not challenging because the teachers were more keen on giving us high grades then letting us learn. So they gave us the program we needed to do for the finals and told us we just needed to switch a couple variables and change an equation. Everyone wins! Teacher gets to keep their job, students get to raise their GPA. And people said post-secondary was tough! PFF!

Looking back, it would have been nice to actually try and get better at programming. It would have helped me out in quite a few situations in the past few years. In 2001, who knew I would be needing to dive into programming here and there. It's only once every 6 months or so, but still. The programming i've been doing in the past few years while following my SQA career is strictly scripting though. I'm not creating a new world for anyone or jumping any boundaries. Just simple stuff like if the program does a certain thing then something is expected so test to make sure it happens the way it should then Pass it or Fail it so i can manually look into it. So now i'm mostly writing using a progamming language called Python. My recent few lines in the script look like this:

for index,line in enumerate(count.splitlines()):
line = re.sub('[\, ]', ' ', line)
line = line.split()
if 'Clients' in line:
row = int(index)
cl_out[index] = line
total_sec = cl_out[row+1][0]
print total_sec
total_bytes = int(cl_out[row+1][-2])*int(total_sec)
print total_bytes
log.info("Finished Curl Loader HTTP Traffic")

There might be a better way to write this out, but that's the learning part that I go through all the time. Especially since I only program every 6 months or so. The fun part is having different scenarios every time and trying to overcome the challenges. I had help on this little section, but now i understand what's happening.

It has been my goal every year to have an least one major automation script to work on during catch up time. It isn't very common to have a QA tester that does not know how to automate very well. Gotta try to keep up! Luckily my co-worker has been very helpful through a couple rough situations and helped out.

Back to the grindstone!

From 11 winter