Doing more than you are asked
Yesterday, I met a prospective client who is looking for an offshore company to look after the QA for a particular software development project. Describing his requirements, he said, “I am looking for a QA team that does more than they are asked for.” Probing a bit further, I found that actually this was a very reasonable request.
Yesterday, I met a prospective client who is looking for an offshore company to look after the QA for a particular software development project. Describing his requirements, he said, “I am looking for a QA team that does more than they are asked for.” Probing a bit further, I found that actually this was a very reasonable request. He is looking for a team that aren’t just automatons – completing just the exact tasks they are asked to do by their client – but that actually apply the specialist QA knowledge and experience that they have to the requests they receive.
Any decent QA team should be doing this. In essence what this man is looking for, and in fact what any client should want, is a testing team that understands the technical and functional specifications of the software. And based on this knowledge continually checks that the software is meeting these and the overall aims of the project. This will involve the team doing some level of analysis of the errors that occur, rather than just sending them back to the client, notifying of the problem.
For example, I heard recently of a bank that outsources its testing. In this instance the bank was capacity testing a new piece of software that analyses trades. The pre-capacity testing had been completed but with the capacity testing, no matter whether 5,000, 10,000 or 25,000 trades were run through the software, the outcome of the analysis was always impossible. The outsourced QA team simply flagged this as a major issue. Had they looked into what was causing the problem a bit further, they would have found that it was because they were using the same trade 5, 10 or 25,000 times, creating a completely implausible situation that the system would never need to handle and therefore is not designed for. Instead it was the customer’s in-house development team that discovered this, leaving them wondering why they were paying QA experts….