The role of Testing in IT projects can often be underestimated until the project timelines are nearing completion or have even slipped and the defect count is too excessive to deem an exit criteria having been met. It’s at this time that the noise grows within the project by the customer and the pressure mounts across the project 

Often this situation can be avoided and yet it is still repeated time and time again in projects because there is a lack of Appreciation and understanding of ‘The Art of Testing’.

We all know that delivering ITSM Programmes is an expensive business and the appetite to deliver fast and cheap is a constant driver when making decisions on how many resources to deploy across a project. The cost of resources can be the one thing that sends a project budget sky high.

The reality of the situation is that if you are implementing a large and complex solution then it’s smarter and most commonly cheaper to bring in specialised resources at a slightly higher cost. This way, you have the assurances that the product knowledge is available and this will de-risk the opportunity for unnecessary defects from finding their way into the Production environment. It will also see that things are done faster because the knowledge is available to accurately deploy and test the solution.

It makes sense to do things once and well rather than having to go back and do it all several times poorly.

The tasks that are carried out within a testing lifecycle are done for very good reason. To gain the maximum benefit when testing, the process needs to be methodical and controlled. For people who don’t enjoy documenting things then this might not be the career path for you.

Writing test scripts and ensuring they are reviewed and accurate is the basis for good testing. To test the core functionality first will identify the obvious defects and provide the ‘steps to reproduce’ when a defect is identified. The test scripts need to cater for positive and negative tests and the majority of a testing effort is found here at the scripting stage. Good test scripts will result in good tests. Think it through, brainstorm and most importantly, work with specifications that have been approved.

Once the test scripts have been run and enfirst pass of defects have been resolved and retested, the road is clear to carry out some exploratory testing where users can carry out ‘what if’ scenarios …

“What if I clicked on …..”

For all of these tests, as the tester carries out each step, they are required to document the steps they have taken so that any defect being raised can be investigated by the developer in a more informed manner. Testing is not just about finding the faults but there is a responsibility to report the faults as clearly as possible with as much evidence as can be obtained at the time of testing.

I have referred to testing as an Art because it is definitely for everyone and you need to have a certain quality about you to be a tester. An appreciation of why testing is carried out as it is will result in you being a better tester. I can tell you that there are many in projects who do not have that appreciation and these people come from testing, projects management and development roles.

By adhering to the disciplines and simply having an appreciation of them will make you a better tester and you will have more opportunities to show your art across more projects as good artists are often in demand.