How to test your IT project – the basics
You’ve built your product or system
…and it all looks great but you really need to be sure it’s work as expected. This post gives you the basics around how to test your project. Testing is a specialist area and can get quite complex. We’ve tried to explain things as clearly as possible but if you can’t quite get what we’re saying you are welcome to ask questions in the comments and we’ll do our best to get back to you.
So what is testing?
Testing is defined as the process of validating that a system, application or new business process works as expected & meets requirements.
Ultimately, testing what you have built gives you the confidence to put the new system into operation.
How do you go about testing what you’ve built?
#1 List the functionality of the project
It’s important to cover:
- What the system is required to do (the happy path)
The happy path will be made up of positive and negative tests i.e. things that the user should be able to do (positive) and things that the user shouldn’t be able to do (negative).
For example, you may need to test approval of purchase orders above £500,000
Positive test: Finance Director SHOULD be able to approve the purchase order
Negative test: Admin Assistant SHOULD NOT be able to approve the purchase order
- Any other valid routes the system can take (alternative path)
- How the system responds to errors (exceptional path)
Errors could be from users inputting incorrect information or misusing the system
If you started with a clear set of requirements you can use these to test against. If not it make a note of the things you need to be sure are working before go-live and tick them off when you’ve tested them.
#2 Determine the priority of the functionality
Putting high, medium and low against each piece of functionality helps to determine their criticality.
Depending on the size of the project it may not be possible to test all of the functionality. However if it is not realistic to test all of the functionality a pragmatic approach is taken, for example testing only high and medium priority pieces of functionality can be more achievable but still provide the confidence required to go-live.
#3 Determine who will sign-off testing
You need to determine who is responsible for signing off testing and accepting the product as ‘fit’ for business use. This should be an individual or group of individuals who are receiving the product once complete.
It can also vary depending on the stage of testing you are in, for example unit testing may only need signing off by the test team, whereas user acceptance testing will need signing off by the business. These stages are explained in more detail below.
#4 Agree what will be tested
It’s important to engage all the relevant stakeholders when agreeing priority and scope of testing, including those who will ultimately sign-off testing as complete.
It’s not unusual for the business to want everything tested, but also want the job done quickly. Finding a balance can be difficult, but it’s important for everyone to be clear on how much testing is necessary for the stakeholders and sponsors to sign the project off for live. Use your list of functionality to agree the scope of testing.
Remember, it’s all about the business being confident enough in what you’ve built to put it live.
#5 Have a process for managing defects
Once testing starts it will identify areas where the system is not functioning as expected. These issues are called defects. Defects are normally rated in terms of severity.
Managing defects is a big part of managing testing. Each defect should be logged and kept up-to-date as it goes through the process of being fixed.
It is also useful to agree what level of defects will be acceptable to go-live with. Normally all high severity defects will have to be fixed, and in fact these may be things that would stop the project going-live if left unresolved. Low severity defects are minor irritations rather than serious issues with the functionality, so it is often accepted that a project go-live with some minor defects.
Once again, the stakeholders and those signing-off testing as complete should have agreed to what level of defects is acceptable.
#6 Test each piece of functionality individually (unit testing)
Testing each piece of functionality in isolation ensures that they all work as individual pieces. Any defects discovered should be logged and resolved before moving on. Normally developers will carry out unit testing.
#7 Test multiple components of functionality together (functional and integration testing)
End-to-end processes will often involve multiple pieces of functionality. For example, the process for a user purchasing car insurance online might be:
User clicks to purchase insurance – Back end systems process purchase and generate insurance documents – User receives email to confirm purchase – User receives email providing logon details to documentation
Joining up multiple components of functionality to test a whole end-to-end process ensures that the components work together as well as individually.
During this stage of testing it is also important to test any interfaces e.g. between different systems or between manual processes and the system you have built.
It’s usual to have test scripts that testers can follow. These are literally step-by-step guides of how to carry out a particular test along with the expected result.
There may be multiple processes to test for a project. Normally people assigned as ‘testers’ will carry out functional and integration testing.
#8 User acceptance testing
User acceptance testing is about getting end users involved in the testing process. This is the final stage of testing before putting a product live. Getting a select group of end users to carry out some testing really helps to get them on board before go-live and can also pick up any user experience type issues that the project team may not have picked up. An example would be that the new process takes twice as long as the old process (although let’s hope this isn’t the case!)
Once again, test scripts can be used to provide a more co-ordinated approach to user acceptance testing.
Alternatively you can just let the users go on the system and see what they come back with. This can work particularly well for apps that should be intuitive to use.
#9 Go back and test everything again when all the defects are fixed (regression testing)
Sometimes fixing a defect can have an unexpected knock-on effect. It is important to test all end-to-end processes and interfaces again when all the defects are fixed to make sure that fixing one defect hasn’t broken something else.
#10 Consider performance testing
Performance testing determines how the system responds under varying conditions (e.g. high load, constant load or when accessed remotely from outside the network).
A system can work perfectly well from a functional point of view i.e. it can support the business processes, but if it does not perform at peak times it is no good. For example users won’t go back to a website that runs very slowly when many people are accessing it.
Performance testing is a very specialist area of testing and normally requires a performance test organisation to assist.
#11 Get sign-off
When testing is complete and defects are fixed, the people agreed as signatories should sign-off that they are happy to put the project live.
Sometimes this sign-off will include caveats that some of the defects are fixed once the system is in production within a certain period of time.
This blog post was a very basic introduction to the world of testing. If you want to know more, keep an eye out for future posts that will go into more detail.
So that you don’t miss out, you can sign up to receive an email notification when we release a new blog post. You will also get access to FREE pdf summaries of all of our blog posts.
Thanks for reading. As usual we’d welcome your comments or you sharing this post on your favourite social media network if you’ve enjoyed it (top of the page).