chromosphere

For those of you who don’t know me, you almost certainly won’t know what I do. Of course, there are probably a load of people who do know me, who still don’t know what I do (and, no, “Nothing” is not the answer). I work as a software tester and I have done for the last 7+ years now in a few different places.

Generally, this job involves a fair bit of evangalism – sometimes it’s quite successful (eg Promoting the use of Bugzilla as a defect tracking tool). One of my favourite diagrams is that shown in this post – I like this graph a lot. It is a graph showing the rough relationship between the cost of fixing a bug or defect, and what stage of the development process that bug or defect was found.

It’s fairly clear from the graph that, the later you realise there is a problem, the more it costs you to go back and unravel what is wrong and sort it. The reasons are fairly clear – if you find a problem at a later stage, you often have to go right back to the beginning of the process of development, testing and so on.

Some notes I like to make relating to this:

1. Even if you are already employed by a company, you are not “free”. Having someone fix a problem, and work repeated costs money – “we already pay their wages” is not an argument! Sheffield Teaching Hospitals Trust – take heed (Quote from the Reg article: The trust argued that the consequences of its decision making had not cost public money, “just time and effort by the IT teams”.).
2. Accurate. timely requirements are essential. Finding out that you have mis-specified something as it is nearing the release date is a Bad Thing™.
3. Not having requirements before coding is asking for even more trouble.
4. Changing requirements part way through the process (or, worse, finding out during testing that your requirements were duff!) is much along the lines of 2 and 3 with similar outcomes (moving goalposts anyone?).
5. Doing unit testing is much better than sending code straight to the testers – it saves a lot of heartache on both sides…
6. Actually having enough time to perform a sufficient level of testing can save you an enormous amount of hassle and cost.
7. Squishing bugs as you go at the earliest possible opportunity is much advised – multiple bugs can quickly make a system unusable and costly to fix up. (There is another similarly shaped graph – see it as The Law Of Bugterial Infection)
8. No one is perfect… not even me

Feel free to use the graph above if you want and evangelise away…

Start Slide Show with PicLens Lite

In the past I have used (many times) Photobox to get prints from digital photos, and they have been very good – the prints are generally very good, even given my lack of photographic ability.

However, recently (June ish?) they have “upgraded” their website, and all seems to have gone to pot for me since. It started off last Friday (25th July) when I was trying to get some pictures from my albums like this: Read the rest of this entry »

Start Slide Show with PicLens Lite

…then it means that Apache is back to normal. On the server (I run it), we had a little bit of fun with a post ranking quite highly on Reddit. The corresponding traffic saturated Apache’s processes meaning that the whole server started to run slowly, and became apparently unresponsive.

Of course, increasing MaxClients doesn’t help if you start to be RAM/CPU limited, and it helps even less when the kernel starts sending out syncookies in light of the barrage of requests.

Anyhow, back to normal for the minute, but we need to move to a better front end… (at least sometimes) we are:

Start Slide Show with PicLens Lite

If you are a BT or Yahoo email user, then you may notice occasionally that your email takes an age to arrive. Sometimes you may even discover that an email someone sent you you has never arrived. If you experience this, here’s a bit of an explanation as to why this may be happening…

Read the rest of this entry »