PDF Estimated Time To Read This: 2 minutes
Photo by kkirugi - http://www.flickr.com/photos/kkirugi/
As Carl had mentioned in an earlier post, we FileMaker developers try to convene on a regular basis for what we call “FileMaker Day”. We do a number of things on these days such as improving our standards/best practices, share tips/tricks, even watching webinars to learn something new. This most recent day was a busy one indeed, so much so that we ended up running out of time. One of the things that we discussed was our FileMaker Standard System Testing Checklist. New features have been introduced to FileMaker since the last time we updated the checklist, so it was time for us to freshen it up a bit. This checklist is what our development team uses to inspect our own work prior to even handing a system off to our QA department for further testing. All in all, it’s pretty thorough, and combined with having a second set of eyes (Our QA department) to test the systems that we ship is a recipe for success. Hopefully you find the checklist helpful for yourself, or even have some suggestions. Drop us a line either way!
4 Comments
Very useful! Thanks for sharing.
How long does it usually take you to go through the whole checklist? Seems like a work for way more than one manday when examining and average solution.
Do you have an optimization methodology when to test only something? Or do you do a complete regressive test every time you deploy a new version of any solution?
No problem Honza;
glad you find it useful.
It’s hard to put a time on how long it takes to go through the checklist, as that can vary quite significantly based on the scope of the project it’s being applied to.
There are various techniques that I employ however, that are an attempt at speeding up the process. One example of which pertains to scripts.
We include a standard comment block at the top of each one of our scripts as part of our standards (purpose/creation date/modification date/created by/modified by/dependencies/etc…), so, while I’m writing a script, I’ll certainly document the script with comments throughout its body while writing it, but I don’t add the standard comment block to the top of the script until the script has been completed AND checked against the list. This way, I can be checking the script while it’s still fresh in my mind, instead of waiting until the entire system is finished to go back and check every script.
You have a very high level of quality control!
If I understand correctly you do not test everything with every release, just the new and modified things. Right?
So I guess you use your development standards to prevent situations when changing one thing breaks another…
Such as never using the same layout for both UI and scripted processing…
Correct?
You are correct Honza;
I definitely try to test all things new and modified, but sometimes it just proves too much to re-test the entire system with every release. Especially when newly made modifications to a system don’t affect various modules of the system in the slightest. As for never using the same layout for both UI and scripted processing, there are times when I break that rule. One of my previous posts (which I see you read also) is a prime example of that –> http://coresolutions.ca/complicated-relationship-with-the-gf