In this issue of the inversion series we’re going to take a light hearted look at building a testing team and testing software. . .
Let’s assume this is a major project – a new Policy, Billing and Claims System for an insurance company. And let’s also assume that we’ve tested stuff before. So we’re “old heads” when it comes to testing. That means we don’t need to waste time on test strategy as this will just hold up the project and distract our BAU staff and our project developers.
- How do we build the test team? What we need to do is get a test team together . . . it’s a good idea to get all the testers on board from the beginning of the project. We know they’ll be idle for a while (and they will eat into the budget). But it’s important to get them started writing test cases as soon as possible. If the requirements change (we haven’t quite started those yet!) all we have to do is tinker with the test cases rather than build them from scratch. Because we’re experienced we shouldn’t miss anything important!
- What kind of test experience are we after? Well, we don’t need domain experts because they’re more expensive! So long as the generic tester has bought insurance then they should have a good enough understanding of how an insurance policy works. And our business people – senior underwriters and claims managers – will have enough time and knowledge to help them find all the bugs.
- Where do we find them? When we get to the actual testing we know we might be a few resources short. But we know that some of our programmers could be utilised. And of course our CIO is happy to release his best programmers to help us with testing! The best programmers will of course make sure that any errors or omissions that can affect critical business functions or prudential risk will be picked up before they ever become an issue. And that way the CIO can use his less experienced or capable programmers for critical application development and support.
- Where are we going to put them? If we draw our internal team from different departments then it makes sense to leave them in their normal environment. They’ll feel more comfortable in a familiar environment than in a dedicated test team. And if they need to spend a small amount of time on their “normal duties” then this can easily be accommodated without much impact to testing. A side benefit will be that testing whilst located in Development will allow the testers to build rapport with the developers! If we’re supplanting our internal team with vendor, contractors or outsourcers then we should make sure that they are geographically dispersed (for risk mitigation); ideally in time zones that mean we can squeeze more hours into any logical 24-hour period!
- What about the test technology? Servers and environments that require a complete rebuild are the best strategy to employ. If possible we should keep them un-integrated, this keeps the testing focused on the software. With all the human resource we’ve built for testing we can save some money on testing software; ideally we can find something adequate in shareware/freeware. And if we have to buy then we should be able to cycle the environments in such a way that we can defer the expensive production environments for performance testing to the very end of the project.
- How long do we spend testing? If the project falls behind (it won’t of course) – we can always reduce testing time to get it back on track. This is easily achieved by reducing test coverage or the amount of data tested, or we can save time by doing all the testing in parallel. Unit, system, integration and user acceptance testing can all be done at the same time. And we can defer UAT; after all, that is what production is for isn’t it?
So we’re all done. It doesn’t have to be as complex or require as much planning as we’ve been told by the so-called experts.
At Orpheus we call this the sure-fire way to end up with poor quality software, project over-runs and budget blow-outs. However if you want to do it properly contact us . . .