Friday, October 24, 2008

Looking for work

Blogging is slow as I'm currently looking for work. I'm out in western PA, so if anyone out there is interested, let me know.

Related to this and needs around the house, I haven't done much in the way of programming at home. However, I did start to work on a little C coding. Figured I'd best make myself a bit more marketable :-) So, I decided to start by writing a string library that would not be affected by buffer overflows. So far, I just got a strcat replacement working. It appears to work great, however since I use malloc to allocate a new buffer that contains the two strings concatenated, the new string has to be released using free. It's a bit more work, but it may be worth it. Of course, it would be nice to not have to worry about it. Just not sure how...

However, I think if I get the library working the way I want, I can later port it to C++ as a class. That may take care of the malloc issue since I can rely on a destructor being called to release any allocated memory.

When I get the code back to my home computer, I'll have to post the functions.

Labels: , ,

Wednesday, October 01, 2008

Testing Tips

I've been doing a good bit of testing of late for the project I'm working on thats now needs to be completed by COB Friday. I figured I'd post a couple things that I learned that may be useful.

1) The Gimp is your friend. Well, you don't need the Gimp per se, but an image manipulation program is a good thing to have. Trying to describe a bug is one thing. Make a screen capture, annotating it, and sending it to someone is a whole other thing. You really don't need to learn how to do much to be effective. Draw a box/circle, put text on the image, maybe draw a line or two, crop, and manage layers. That's it. I think that's less than 1% of what any decent image editor can do, so there's no reason to get Photoshop or something expensive.

2) Ad-hoc as you go. First, it can be tough to get a good test plan. Due to our schedule, or lack thereof, our test plan isn't that great because a lot of things don't get tested. So, test them as you go along. If there's an option that can be changed and the test plan doesn't say to do anything with it, change it. A user may do it so you should know if the application can handle it.

3) Stress test the damn thing. You don't know what user's expectations are, so throw more data at it than you think it will handle and see what happens.

4) Get good tools. For web testing, there are a variety of extensions for Firefox that are good for helping you generate data, resize your browser, see what errors are being thrown, etc. True, you don't need to use them, but if they make your life easier, why not?

5) Get good error information. Don't be vague. Don't just say "feature A failed." Get good info! Look at logs. Capture error messages. Sometimes when the developer gets around to trying to fix the bug, the log may be gone or you forget how to reproduce the error. Yes, it takes a little extra effort, but it means that the developer can get the bug fixed faster.