Quality assurance does make a difference

Here in our online accounting and payroll online development team, we have an excellent group of people who spend their days making sure our Sage One service and updates are of a high enough quality to release to the market.

So, no surprises there really. Every reputable software development company should have a dedicated test team, or teams. It’s what that team does that makes the difference.

In order to produce features ready for use by our customers and to launch them to the live service on a regular basis, we need to have confidence in the quality of the updates. Did you know, we have enhanced the Sage One product with over 30 updates since we launched in January 2011? We have much more in the pipeline and each of these updates needs to be of the same high standard.

That’s where my team comes in. We aren’t just a test team; we are a quality assurance team. You might be thinking what’s the difference? Well there’s a very big difference between testing and quality assurance (QA).

Testing and quality assurance

If we were just testers, we’d just be looking for bugs, mistakes in the work the developers do once they have completed it. We would run through scenarios and try to capture these.

When we perform true quality assurance, we prevent these bugs appearing in the software in the first place.

So, for example, our Product Owner will write a specification document which details a new feature. We in the test team will then review this document, so already our QA process is starting. We review this document for small things like spelling mistakes, as well as compliance with accounting or payroll legislation and the overall end user experience. We think up the edge-case scenarios which may only happen rarely, but which would still be encountered by some of our customers. We then feed back to the Product Owner.

Any updates are made to the document, and this all happens before it has even gone to the development team. If we only tested, we’d take that document, write a test script and run the tests when the feature has been developed. By analysing and performing a static review we highlight issues sooner. That is the point of QA.

We also work very closely with our developers. Yes, testers and developers can get on! We start reviewing their work as soon as they start developing. So by the time it is classed as complete, there are no surprises for us and we can concentrate on testing edge case scenarios.

Quality Assurance starts from the minute a discussion is made about a feature right up to the point when the feature is released to the live service. True Quality Assurance makes a difference, which is why the Sage One community sees smooth, high quality updates going live on a regular basis and will continue to do so!

Claire Adams, The Sage One Team

  • Hi,

    I work in a QA Team in France and I really agree with what you wrote.
    Even if we can’t really apply it actually, we work for succeed in future to make quality assurance and not simply test.
    Did you have problems to make accept your all scope of work by the others teams, like R&D? How long do you do this job?
    I have so much questions, could we mail ?
    Kind regards