I decided to post about this because it's turning to be a pet peeve of mine. Our company is a customer of other companies but we also have customers that we have to answer to. Unlike most of the companies we deal with though, I like testing everything I do before a customer gets their hands on whatever product or service we've given them. This makes sure that:
- I've done my job
- I see what the customer should see
- If I notice any problems, the customer will too
This testing I do has caught a great number of simple mistakes I've made in the past. This type of testing would have saved me from the email nightmare we went through 2 weeks ago. I've blogged about it and I won't try to link to the 4 posts about the experience.
Part of my problem is that I have some OCD tendencies that I won't deny. Testing for me is almost a compulsive behavior but I find that 30 minutes of testing will save me hours of work on the back end. I deal with a number of companies that don't apparently feel this way and seem to have problems when I report issues. When I reveal that their simple mistake could have been found through simple testing they usually shrug it off and repeat the process in the next version/upgrade/whatever.
To be honest, I hate testing. The main reason I hate it is because it's a completely manual process on my part in 99/100 things I do. I could automate some of it, but it would require a lot of time I don't really have on technologies I'm not really familiar with.
Here's a brief list of areas that I test regularly:
- Portal
- User additions
- User changes
- Permission tweaks
- New items
- Upgrades/Code improvements
- Active Directory
- User additions
- User changes
- RSoP
- SalesLogix
- User additions
- User changes
- Permissions
- Development of any kind
- Upgrades/Code improvements
The majority of the tests for the portal are done by me logging in as the user in question. By logging in I can verify that their personal information is correct as well as make sure that the portal is correctly rendering just the information they need to see. I do the same for SalesLogix because even if you built a testing application outside of SalesLogix you really wouldn't get the same kind of results you would get if you were to login to the client directly. Active Directory is one of the easiest to test because there's a number of testing material already out there. Also with AD you are usually guaranteed results across the network whereas with the portal or SalesLogix you often have to guess which outcomes you'll receive.
One area that is very annoying is the testing of upgrades and improvements. In SalesLogix I've learned not to trust the company and I have to test every single upgrade or enhancement before putting it into production. Blindly upgrading has cost me dearly in the past and even though SalesLogix is getting better I don't think I'll ever be able to fully trust them. The portal is another area where testing the improvements are a necessity. There have been numerous occasions where there was a planned upgrade and when I go to test our demo I find that the portal is completely unusable. Browsing to our web server would have easily identified the problem but the company apparently wants me to figure these things out for them.
I guess I come from the mindset “measure twice, cut once”. Even though the saying applies to mainly work you do with your hands, it very much applies to any work you do on a computer. I measure initially by designing the change or implementation. I then cut by doing the actual work involved. I measure again by doing the testing to make sure that A + B really is C, not some undesired result. When I'm satisfied with my results then and only then do I release the implementation to the client. The client in my case can be anyone from a customer, an employee, or sometimes even companies we're customers of.
The problem, I find, is that more and more companies aren't really willing to test their services or products. I agree that there is only so much testing you can do but it would behoove any company to make testing of their product as easy as possible. This makes sure that your product gets used and the administrator behind it can trust that whatever is done can adequately be measured to the administrators liking. It's not easy to do given some technologies but I think if you're not willing to offer the help to administrators you're not really doing your job.
Then again I guess it's perfectly okay for people to screw up and wonder why you blame them even though a simple test would have solved the problem long before it ever became one.