I know from personal experience that there is a tendency in general and South Africa in particular for people to skip quality assurance in business integration projects and rely entirely on testing to pick up the snags in a project, writes Kevin Palmer, senior QA consultant at Red Man Technologies. They do that because they think they’re saving time and, therefore, money.
The irony is, of course, that delaying delivery of a project for reasons of quality is much cheaper than fixing a defect in operation. Besides, if you do things coherently at the beginning, you can actually reduce the time needed for testing – and therefore the cost of testing. Also, the more people (testers) you have to involve in a project, and the more something has to be redesigned, rewritten, and retested, the more your project costs grow, often exponentially.
So, at the most simplistic of levels, it’s self-defeating to dodge quality assurance.
Also, the idea that quality assurance necessarily adds time to a project is a misconception. It arises because people think that quality assurance is a tool. And, yes, there are some automated quality assurance packages out there that are more tool than methodology. But true quality assurance is in fact neither a tool nor a methodology. It’s a lifestyle.
It’s about getting things right the first time. It’s about doing things in an orderly way. It’s about going from the general to the particular, the big picture to the detail.
At Red Man, we apply a quality strategy to everything we do in the workplace, from general admin in our own offices to software development and ERP and other implementations for clients. That way, we don’t have to go back and do things over again. And, that way, we’re able to deliver projects in a structured, incremental way that both ensures that the projects are accurately aligned with the business’ strategies and that they work properly from day one.
The point of quality assurance, you see, is to enable you to get to the desired result with the least amount of effort and cost in the shortest possible time. Which means imposing discipline and structure. Specifically, because development, implementation, and deployment entail so many different skills – from code developers, to database designers, and systems developers – it provides an impartial means for managing a team of highly individualistic specialists who would otherwise focus only on their own areas of expertise.
Testing, on its own, simply can’t do all that.
In addition, testing, independent of a broader quality assurance strategy, is not enough to ensure that a deliverable will be aligned with actual requirements and that the applications released into the operational environment will be made to an acceptable performance standard and level of reliability.
Because a quality assurance methodology includes identifying the development tools – such as fault logging, source code repository, document repository, and automated testing – to use.
It defines the standards to be adhered to – including coding, naming conventions in the database, and report layout.
It defines the software development process – including the controlling of change.
It stipulates the application release process – and should cover software builds, database changes, environment changes, and document updates.
Naturally, it will define the testing methodology, covering everything from test definition and planning to testing techniques.
And, it should contain a full set of documentation templates for each step in the process – from a fault or bug report and a test strategy to document templates for requirements, minutes and plans.
All of which ensures that the entire project is under control and that outputs are consistent, predictable, and repeatable. That actually cuts time, wasted time, out of the overall process and, accordingly, makes it possible to bring in a project in or under budget.
More importantly, it makes it possible to deliver a project that works the way it should from day one and, therefore, gives the customer rapid time to benefit.
In other words, there really is no way to justify avoiding quality assurance.