The System Under Test, or SUT, is quite simply the specific piece of software, or the particular part of a larger system, that we are currently focusing our testing efforts on. It is the bit that's "in the spotlight" for our current investigation. It can be, but it is fairly rare for a whole system or network to be under test at the same time.Â
Defining your SUT clearly is very important. It helps us to scope our testing better and to understand exactly what we are looking to confirm or understand. If you are testing a whole banking application, the SUT might be the entire application, which is a lot. But, if you are just checking if a new feature like "transfer money" works, then the SUT could be that specific transfer module, or even just the API endpoint that handles the transaction. It could be a single function, a particular screen, or even just a set of interactions. This, of course, needs to be supported by some form of regression testing for the rest of the system.Â
For us testers, pinpointing the SUT for any given test or scope of testing helps us a lot. It makes sure we are all on the same page about what is actually being tested, which helps in designing relevant test cases, identifying necessary test data, and understanding the boundaries of our investigation. It also helps when reporting bugs, as we can clearly state which part of the system exhibited the unexpected behaviour. It is about being precise with our testing focus, so we know exactly what we are talking about and can communicate it in the best way for the project.Â
An SUT can sometimes be referred to as a Product Under Test (PUT). While they, in rare circumstances, can be used interchangeably, more often they are mixed up by mistake. Remember that the SUT is about the scope of what you are testing right now, which might only be one small part of the entire product.
Defining your SUT clearly is very important. It helps us to scope our testing better and to understand exactly what we are looking to confirm or understand. If you are testing a whole banking application, the SUT might be the entire application, which is a lot. But, if you are just checking if a new feature like "transfer money" works, then the SUT could be that specific transfer module, or even just the API endpoint that handles the transaction. It could be a single function, a particular screen, or even just a set of interactions. This, of course, needs to be supported by some form of regression testing for the rest of the system.Â
For us testers, pinpointing the SUT for any given test or scope of testing helps us a lot. It makes sure we are all on the same page about what is actually being tested, which helps in designing relevant test cases, identifying necessary test data, and understanding the boundaries of our investigation. It also helps when reporting bugs, as we can clearly state which part of the system exhibited the unexpected behaviour. It is about being precise with our testing focus, so we know exactly what we are talking about and can communicate it in the best way for the project.Â
An SUT can sometimes be referred to as a Product Under Test (PUT). While they, in rare circumstances, can be used interchangeably, more often they are mixed up by mistake. Remember that the SUT is about the scope of what you are testing right now, which might only be one small part of the entire product.