Archive for January, 2007

Holub Associates: UML Reference Card

Holub Associates: UML Reference Card

Looks like a good UML reference

Comments

useful SQL

UPDATE table_name SET column_name=’value’ WHERE column_name=’value’

Comments

Some advice about new clients

Every 3 months, in the uk, about 3 or 4 thousand businesses go broke, or bankrupt.

If you are employed by one about to go bust, the same could happen to you.

Here are the figures.

COMPANY LIQUIDATIONS 1998-2006

I’m still owed quite alot of wages by one of them; if I’d done my homework extensively I would have run a mile rather than work for that man. According to the record, his business was finished earlier last year. But it wasnt at all easy to see who I was working for. A slight name-change was enough to hide his identity from what was available on-line; turns out he had to get his wife to be director since he had been disbarred from directorship for years. I should have known this guy was a player when he laughed at contracts “we dont need to do contracts, surely, haha haha??” but at the same time asked for an NDA. Because the sums involved were going to be large I did not dare to ask for an advance. Dear oh dear oh dear. What a fool I was – all the risk was taken by me and minimial from the crooks. When it turned out their business plan was nonsense and was somekind of weeze to get money out his wife, I was already being strung along waiting for the third payment that never came, having worked whilst waiting for the cheque to not bounce.

Anyway, blood under the bridge and all that.

If youre unsure about a new client or if you just want to know how strong they are, get some ID, check their records on Companies House (pay the £1 for the downloadable TIFF - its well worth it – but n.b. they maintain opening hours) and see if they are on the London Gazette – the place where all the insolvencies and requests for owing money from solicitors are published – its free to search.

So before you step into a verbal or written agreement with someone you dont know, find out who your new client is, and, comparing the story you have been presented, and what you may dig up, some surprises may be in store for you. You could frighten off someone genuine, but as long as you handle the ID stage with some grace, any upstanding individual should not be taken-aback by such a request.

Anyone worth their salt will tell you the small but significant cost in terms of time & money researching the new client is well spent; you dont need to go through their trash or call a P.I. but wouldnt you want to know, if youre working freelance and have no legal-dept to call on, that after a months hard graft, you are definately going to get your wages in full?

Should you have discovered some “skeletons in the closet”, you can politely decline further approaches from the individual and save your time for people who wont drag your business down with them.

If you need more proof, the chances are significantly higher now than several years ago that there is a problem with an individuals credit:

Individual credit problems

So you have to be even more careful with non-companies than you do companies.

Take care in the jungle!

Comments

boundary values in software testing

Over at extreme testing, a good article on test cases.

What values do you input to your program?

Since errors tend to happen around the boundaries of predicates, you write test cases for those boundaries. So if you have a range of 0 to 999 you opt for -1 and 1000, with valid tests being 0 and 999. Everything in between being immaterial.

Here are some exam questions asking for test cases in three different scenarios:

  1. Consider a program that accepts the age of a person as input and computes the amount of premium s/he has to pay for a medical policy. Describe your design of test cases for testing the program. (Note: Assume that the age of babies before their first birthday to be one year).


  2. You have been asked to test one of the modules in a software system that supports of an e-commerce website. This module processes credit card details supplied customer credit card number, card type (Master/Visa), ‘Valid From’ date and parameters. If the card is valid for the date of the transaction, then this module transmitted to CyberCash to process payment from customer to merchant.


  3. Consider a program that accepts the speed of a car in MPH (miles per hour) as input and displays an estimated stopping distance somewhat similar to the figures mentioned in the Highway Code. Write test cases for testing this program, stating clearly (i) the procedure you would use for designing test cases and (ii) any assumptions you make.


Hmm, great. What does a test case look like? The chaps at cam have a good idea.

And whats this? a Test Case Format? Ahh, yes. Another shows what a test case ought to be plus other notes on what types of black box testing there are out there.

“test case: A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. After [IEEE,do178b] ”
from here

inputs:
preconditions / assumptions:
expected result:

Comments (2)

« Previous entries · Next entries »