In our opinion, website development isn’t quite a professional industry. There are pockets of professionalism, but certainly on the Small/Medium Business side there is certainly a high proportion of ‘Nephews’ (as in, “My Nephew does computers at school, so he’s doing our website for us”… really? Well, that’s the sort of client KP Direction would rather not have anyway!).
One of the aspects where an amateurish approach really shows through is in dynamic websites created with PHP – specifically, the Testing arena. A web development company we know of recently told us that they’d almost finished a large scale website for a major client, and were now ready to test it – how could they show their client that they had a formal testing process in place? We fell off our chairs. What they were asking is, “How can we pretend to our client that we do something that we don’t really do”.
Testing a dynamic website properly is the same as any major software engineering project – and as such, it starts at the start of the project. You can test your PHP class definitions as they are written, which reduces the time required at the end of the project – at which point, testing should not pop up any major surprises. Testing properly is a career in itself, similar to Designer or Programmer.
At a simplistic level there are two ways to test a site; White Box and Black Box.
White Box testing means that a test designer (who should *not* be the programmer at this stage) is able to see the specification for the internal class definitions used in the program. He then designs a series of tests which test every possible combination of input – valid and not – to see if the program handles them correctly, returning valid results or user friendly error messages as appropriate. Remember to test *every* input field (e.g, name, address1, zip code) for No input, short input (1 character), long input (More characters than are allowed), extended character input (e.g Quotes, backslashes), invalid input (deliberately put an incorrect value in to see if the system handles the error correctly). All tests should include database accesses.
Black Box testing comes after White Box. This time a second tester does not have access to the specifications of the system. Their approach is to use the system normally and abnormally – they should use it as normal users, and document their results, but they should also try to break the system – by unscrupulous means as well as valid ones – such as xss attacks etc.
After Black Box and White Box testing, you then move to Beta test – invite certain people to just ‘use’ the system. If you’ve created and proved valid test plans already, they shouldn’t be able to break it. You can do that before, during, or *instead of* (yes, I’ve had clients do that!) User Acceptance testing – let the client play with the system and see if it does exactly what they asked for. It’s not unknown for a system to get to this stage, then the client sees what you’ve built, and admits that they really wanted something else…
The deliverable to the client is sight of the test plans at each stage, which shows that you’re taking testing seriously. To give an idea of size, a test plan I did for a contact form (OK, a reasonable complex one which wrote the information to a database, sent emails etc) was 281 separate test cases.
As you can see, then, testing is an intrinsic aspect of web development. Odd things can still happen, and requirements can change – you can never allow for absolutely all combination’s of strange user inputs – but a good testing plan shows that you care about your product.
As you may have guessed, we care. If you care as well, let us know, and lets discuss your next web site development. And if you’re a developer who needs to show a client that you have a formal testing procedure in place – call us on (801) 928 6953. We can work with you to develop procedures, or you can outsource your module or system testing to us.