When you are the Project Manager on a software development project it is important that you understand the importance of the different testing requirements that are needed. I use the word needed, as I consider testing a very important part of any software development project, and something that doesn’t get enough time or effort allocated to it, in most instances.
This article will explore the difference between System Integration Testing (SIT) and User Acceptance Testing (UAT) and how you can best move from one testing phase to the other.
System Integration Testing (SIT)
Techopedia has a great definition and explanation of System Integration Testing.
The key piece of the definition for me is: “testers verify that all related systems maintain data integrity and can operate in coordination with other systems in the same environment.”
This is a very important aspect of testing, especially when you have data passing between several systems, or components of systems. You need to ensure that the data is being sent and delivered exactly as you are expecting it to be. Algorithms need to work as expected.
This testing needs to be done by technical people, or technical users; those who fully understand the system and the way that it currently operates, as well as what your expected outcomes should be. Systems Analysts, or Technical Analysts who work with the system, or are part of the project, are valuable in this testing space.
By missing this step in your testing you are more likely to have issues in User Acceptance Testing (UAT). SIT is a form of shake out testing for me, as it ‘shakes out’ any issues with system process flow, where data is moving between systems, screens, databases and is a key thing that needs to be done before you move to UAT.
Once you are comfortable that your SIT has been carried out and any core defects fixed and re-tested, then it is time to hand over testing to UAT.
User Acceptance Testing (UAT)
User Acceptance Testing is the testing carried out by the business users to satisfy that the requirements that were specified have been met in the delivery.
It is the final piece of the testing for a software development project.
UAT testers need to be business users who are familiar with the system, familiar with how to use the system in a number of ways, and people that are not afraid to try things and have them break. They also need to be strong in process understanding.
One problem that may occur is if you have business users who do not understand the process that you are replacing with the system. This will not be as advantageous, as if you have strong SME’s with process understanding.
Moving from SIT to UAT
Here are some of the key things that you can do to make the move from System Integration Testing (SIT) to User Acceptance Testing (UAT) successful:
Write clear test scripts for business users
One of the first things that is important in moving from SIT to UAT is that clear test scripts have been developed. These need to be written for business users and be based on process flow. They also need to describe exactly what you want tested and how.
The test scripts also need to cover off the full end to end process cycle. It is no good only testing the system piece. You must ensure that you include all inputs and all outputs in the process, in your testing.
Hold an information session
I then suggest that you set up an information session with your business testers. This information session is all about describing the project i.e. what is it that you’ve developed, why you’ve developed it (or what is changing) and what the changes are. This background information is useful for the business testers, especially if they haven’t been involved in the delivery of the project to date.
Next I suggest that you run them through the testing process. What is it that you are expecting of them. For some of these people it may be the very first time that they have been involved in User Acceptance Testing, so you need to ensure that each one understands the process that you want them to follow for the testing, and why.
Some of the key things you need to cover are:
- How are they going to receive the test scripts;
- What is the criteria that you want them to log for items that work/don’t work/only work partially;
- Do you need them to capture screen shots of all of these or only some, if so which ones;
- What time frames do you need them to undertake this in;
- Are there times when they won’t be able to access the system;
- Do they need to log on as different level users and test scenarios.
Consider if there are other items that need to be clearly articulated to the business testers.
You also need to explain what support the testers will get, from the project team, during this phase of the testing. Will there be someone walking the floor? Will there be a project team member on hand during all of their testing? Will there be someone available on the telephone if they have a question or the system doesn’t operate the way that they are expecting and they want advice?
If users are moving between systems to undertake their testing, how are you going to ensure that they can do that easily? How are they going to know that items are available for them to test, if there is a dependency on another business tester along the process chain to have performed something?
Having a process map of the new end to end process to provide might also be useful.
Be very clear about your expectations, how much time you are asking them to commit to the testing process, and what you are expecting from them. This will help all parties get the best from this testing experience.
Work WITH the business during this entire process.
Support the testers during the testing process
It is important that the project team support the UAT testers during this phase. If you provide the right level of support you will be sure to achieve a better outcome, with the business being confident that the testing process has been as thorough as they need it to be for them to sign off.
Written by Karen Munro