Wednesday, 2 February 2011

Test Early and Often

On a recent project it was agreed that testing would mainly be executed at the UAT phase, I was to build a set of test cases that could be executed by the customer. While some testing might get done informally before UAT that was to be the main test phase. When UAT commenced there was delay while the test cases were proven and understood, before being run in anger.

Some test assumptions were wrong and test cases had to be updated. Some functionality wasn’t implemented as described in the requirements documents meaning more clarification and correction. Server issues further delayed the test progression and overall finishing UAT was delayed by around 2 weeks. Sign-off was achieved but it was done a little grudgingly based on contractual terms being met.

In an earlier project testing began before we even had the code. Test cases were used as a way to validate requirements and gaps were found. Not only in the thinking around the requirements but the third party applications that were part of the overall integration. Test cases revealed conditions that those applications wouldn’t be able to meet and a mitigation approach was agreed.

When new development was released tests were run straight away in part because automation was in place to assist. When UAT came around and the customer expected a final test run from us – we didn’t bother. There was no need for a final test run. We handed the code and test over and less than a week later got sign-off for the delivery.

These two very different approaches highlight the importance of testing often and testing early.

It’s not just about ironing out the issues early on. We want to do that of course. We want to find the issues in the requirements, in our test cases and assumptions, we want to have clear information in developer hands so they can code once and quickly. (Developers are artisans and artisans hate reworking what they’ve produced, they’re proud of their work like we are.)

Testing early and often saves time (and money), it cuts frustration and keeps people motivated as it gives feedback and insight, and confirmation of a job being done well.

Customer confidence and belief in the quality of work we produce, our ability as a competent and professional team all come across when we test early and often. In consultancy this is the holy grail of keeping customers and winning new ones. So many consultancies just do the job and follow the contract, it’s immoral, think of those that have been sued in recent years.

Build customer confidence by making quality and delivery a foregone conclusion by testing early and knowing it will be.


Liked this post?


Anonymous said...

tres interessant, merci

Anonymous said...

As a Newbie, I am always searching online for articles that can help me. Thank you Wow! Thank you! I always wanted to write in my site something like that. Can I take part of your post to my blog?

Mark Crowther said...

Hey, glad you like it. You can always use the blog and site content freely, just mention the source as usual :)

Lisa Davidson said...

Indeed very interesting post. I agree with you that Introducing Software Quality Assurance and Testing early and often saves time (and money), it certainly cuts frustration and keeps a proper flow with transparency and helps to achieve target.