{"id":1205,"date":"2019-11-15T11:29:46","date_gmt":"2019-11-15T11:29:46","guid":{"rendered":"http:\/\/talentedtester.com\/?p=1205"},"modified":"2019-11-15T11:29:46","modified_gmt":"2019-11-15T11:29:46","slug":"why-is-multiple-rounds-of-system-testing-recommended","status":"publish","type":"post","link":"http:\/\/talentedtester.com\/why-is-multiple-rounds-of-system-testing-recommended\/","title":{"rendered":"Why is Multiple Rounds of System Testing Recommended?"},"content":{"rendered":"

If you are new to system testing, you may be wondering what it is and why there is typically multiple rounds (or cycles) of testing.<\/p>\n

Why are multiple rounds of testing needed? Because each initial round typically results in defects. Each time a new build is introduced to address the defects, a new cycle is started to verify that the inial tests, that were passed, have not been adversely affected.<\/strong><\/p>\n

Now that you know why multiple rounds of the system is required, you may be wondering what is this “Gold Build” that people talk about, the objectives of system testing, who actually executes the tests and much more.<\/p>\n

The Theory of the “Gold Build”<\/h2>\n

The Gold build is the ideal build, that should, in theory, have little to know defects after a round of system testing. But, let me explain where this all comes from…<\/p>\n

System Testing is needed because a system is very rarely correct on the first iteration. Typically after the expected tests are run a number of defects are detected.<\/p>\n

If you continued where you left off after the defects have been fixed you would not know if the previous tests, that had been run and passed, have been tainted by the new code that had been implemented, are you with me?<\/p>\n

Regressional Testing<\/h3>\n

Therefore, it is important to repeat these tests, that have previously been run, on a new iteration (cycle\/round) to confirm that there have been no adverse effects to previously tested code. (Basically a form of regression).<\/p>\n

The Gold Build itself<\/h3>\n

Usually, after a couple of rounds of testing in this manner, you can get to what is deemed as the “gold build”. The gold build is expected to give little to no defects and be the final round of testing before completing the system testing phase.<\/p>\n

However, in reality, these things never quite go as planned. And, there can be a lot more testing iterations (cycles) than expected. Usually, based on my experience, a judgment call by the stakeholders is made, typically called a “Go-No-Go” meeting to decide if the code will be promoted.<\/p>\n

What is system testing?<\/h2>\n

System testing focuses on the entire system as a whole. As opposed to looking at it from a functional by function perspective.\u00a0 At this phase, you’re looking at the entire system. It is often regarded as an end-to-end view of testing.<\/p>\n

System testing is quite important because it is often part of a decision if the system is safe for release. In some cases, it is used for a legal or regulatory quality gate.<\/p>\n

So, what are the objectives (Goals) of system testing?<\/h2>\n
\"objectives

objectives goals of system testing<\/p><\/div>\n

System testing is a key part of the Software Development Lifecycle (SDLC). Because one of its main objectives is reducing risk<\/strong> to the production environment.<\/p>\n

Detect Defects<\/h3>\n

Its aim is to detect as many defects or functional issues before the system is promoted to the live environment. It is a formal method of validating that the system matches the agreed specification.<\/p>\n

Verifying the System matches the agreed specification<\/h3>\n

Obviously, at this stage, there can be situations where the system does meet the agreed specification, but it still does not function as one would logically expect.<\/p>\n

This could turn out to be more of a design issue rather than a system testing error (but more on this later, as to why testers should be involved early).<\/p>\n

Confidence<\/h3>\n

Finally one of the additional objectives of system testing is to provide more confidence that the system will work as expected and also no reduce the risk of defects being passed onto a later level of testing such as you 8000 etc.<\/p>\n

What test environment is required for system testing?<\/h2>\n

Ideally, for system testing, you need a system that closely matches the true production system. However, this is not always realistic due to the cost or resource availability. Either way it is important to try and emulate as closely as you can to the real production system.<\/p>\n

Why?<\/p>\n

This is because you want to feel confident that when it actually goes into production it will perform in the same way that you had it working in system test.<\/p>\n

How can automated regression help?<\/h2>\n

During system testing, as discussed earlier, there may be multiple iterations (cycles) of tests. During each of these iterations, a new build can be implemented which has defect fixes.<\/p>\n

Speed up the regression<\/h3>\n

It is an opportunity to use automated regression to speed up these repeated tests so you can clarify that the defect build that has been implemented has not adversely affected the system. Obviously, this regression automation can add complexities as well.<\/p>\n

Example of test Basis that can be used for system testing.<\/h2>\n

To make sure you have a reference to base your system tests against, it’s important to have a test basis. Documents that can be used for system testing are:<\/p>\n