Comments on: The Boundaries of System Testing http://thetesteye.com/blog/2010/03/the-boundaries-of-system-testing/ by rikard edgren, henrik emilsson and martin jansson - with torbjörn ryber and henrik andersson Sun, 05 Feb 2012 11:36:25 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Henrik Emilsson http://thetesteye.com/blog/2010/03/the-boundaries-of-system-testing/comment-page-1/#comment-343 Henrik Emilsson Mon, 22 Mar 2010 08:42:15 +0000 http://thetesteye.com/blog/?p=717#comment-343 @Rikard: That is a good idea! Scenarios is a very useful technique to visualize the system and to analyze the boundaries. This gives you an opportunity to step in and out of the system, which of course stretches beyond the software. @Martin: Yes, and I guess that there should always(?) be an overlap for at least two reasons: Coverage and use case. Coverage isn't hard to understand, but the use case is interesting because the "current system level" might have a whole different set of use cases than its sibling, children or parent. Often these use cases steps in and out of the "current system level" but can cover completely different things. @Rikard: That is a good idea! Scenarios is a very useful technique to visualize the system and to analyze the boundaries. This gives you an opportunity to step in and out of the system, which of course stretches beyond the software.

@Martin: Yes, and I guess that there should always(?) be an overlap for at least two reasons: Coverage and use case. Coverage isn’t hard to understand, but the use case is interesting because the “current system level” might have a whole different set of use cases than its sibling, children or parent. Often these use cases steps in and out of the “current system level” but can cover completely different things.

]]> By: Martin Jansson http://thetesteye.com/blog/2010/03/the-boundaries-of-system-testing/comment-page-1/#comment-342 Martin Jansson Sat, 20 Mar 2010 17:20:57 +0000 http://thetesteye.com/blog/?p=717#comment-342 Excellent thoughts! Another interesting concept in this is when you have a larger organisation and you have different levels of testing. On one system you might have up to 50 levels. So, the question as you phrase it "What is the boundary of my system" is very interesting. I also think it is interesting to know what did they test before me? Perhaps what boundary did they see? I am sure if you start to compare these boundaries between the different levels you will see lots of overlap but also a lot of spots where no one tests. If we see the universe as a quite complex system, how many levels of testing would that be? Excellent thoughts!

Another interesting concept in this is when you have a larger organisation and you have different levels of testing. On one system you might have up to 50 levels. So, the question as you phrase it “What is the boundary of my system” is very interesting. I also think it is interesting to know what did they test before me? Perhaps what boundary did they see? I am sure if you start to compare these boundaries between the different levels you will see lots of overlap but also a lot of spots where no one tests.

If we see the universe as a quite complex system, how many levels of testing would that be?

]]> By: Rikard Edgren http://thetesteye.com/blog/2010/03/the-boundaries-of-system-testing/comment-page-1/#comment-341 Rikard Edgren Sat, 20 Mar 2010 12:44:38 +0000 http://thetesteye.com/blog/?p=717#comment-341 Yes, this is an important observation. The most important issues might occur outside your system, but be due to things within your system. Of course, testing the "whole system" (a small part of society?) is too time-consuming, but we should at least test "things" from our system that other interacts with. Maybe with a scenario that starts and ends far from the software being developed. It has been wisely said something like "Never make your box the biggest one. It isn't." For system testing we sometimes should think in the opposite way: "make the box of possible testing scope as large as possible" Yes, this is an important observation.
The most important issues might occur outside your system, but be due to things within your system.
Of course, testing the “whole system” (a small part of society?) is too time-consuming, but we should at least test “things” from our system that other interacts with. Maybe with a scenario that starts and ends far from the software being developed.
It has been wisely said something like “Never make your box the biggest one. It isn’t.”
For system testing we sometimes should think in the opposite way:
“make the box of possible testing scope as large as possible”

]]>