There are several signs that make my shoulders sag if I see them when I start working at a new site. These are the obvious errors that there is really no excuse for. If you’re guilty of any of these in your code it’s time to hang your head in shame, pull your finger out and stop it now!
I’m serious, watch out for Magic Numbers, they will cause you no end of headaches if you don’t get them under control from the start. I’m not talking about the musical brothers and sisters from Hanwell, (although if someone could get them under control and convince them to stop producing bland music I’d be forever grateful). No I’m talking about those mysterious numbers that appear in rules and formulae without any apparent meaning.
Following on from my previous post about the apparent lack of value placed in document professionals I’ve pulled together a quick survey so that we can find out what those mythical market rates really are.
To complete the survey please click here of the link doesn’t work go to
If you have any feedback on the survey please leave a comment or get in touch.
I was contacted recently regarding two separate contracts both requiring an HP Exstream Architect, and both roles fell through after discussing rates. I was asking for a rate somewhere between £500 – £600 per day depending on the specifics of the role and was told by the manager of “Talent Aqcuisition” at Espire that I was very expensive!
Of all the aspects of testing, preparing test data is probably the most time consuming and tedious. It is however, one the most important parts. If your test data isn’t correctly prepared and doesn’t tie in with your test plan then you are immediately at a disadvantage. Valuable time can be wasted examining code for bugs, when in fact it is the data that is at fault. Continue reading
Whereas Functional Testing test plans are generated from the Requirements documents, Structural Testing Test Plans are generated from the application itself. Whilst there will always be a significant amount of overlap between the two test plans(Functional and Structural), both should still be created as there are differences in the types of errors captured by each.
We’ve already discussed how a lack of an effective test plan is one of the the major reasons why your implementations fail and discussed effective testing techniques so now it’s time to get into the nitty gritty and discuss testing techniques in detail. We’ll start off with Functional Testing which, whether you know it or not, is probably the testing technique you’re most familiar with. Continue reading
If you routinely set all of your variables to a reset time of “automatically” and your formula variables are all set to calculate “as needed” in Dialogue you could be creating a maintenance nightmare for you and your colleagues. Take your Dialogue knowledge to the next level and take control of formula calculation timing and variable reset timing. Continue reading
A basic principle I always try to stick to with Dialogue is to keep things as simple as possible (Keep It Simple Stupid). If something looks too complicated to easily explain then it probably is. Take the following example (using word Mergefields to define the content) from an insurance document I have worked on recently:- Continue reading
Last time we talked about the impact leaving testing to chance can have on your implementations (and it’s not good), this week we’re going to look at the different types of testing that you can use to give your testing the best chance of catching the defects it’s supposed to. Continue reading