Over the years I have noticed that System Testing have had a special meaning at every place I have been at; and it has even meant different things for people on the same place. I.e. System Testing is depending on the context; and it is fuzzy because we are dealing with arbitrary and/or general systems.

“System testing of software or hardware is testing conducted on a complete, integrated system…” but the boundaries on what the complete and integrated system includes may vary a lot if you look at it from an outside perspective as well as if you look at it from within.

Some examples: When developing a cell phone, where does the “system” begin and where does it end? Does it begin with the cell phone OS or the phone (hardware + OS + software)? Do we need to include any network? How large network? What if you are a third party and developing the phone OS (that could be run standalone in a simulator)? What if you develop an application for the phone (or even different kind of phones)?

So when is a system “complete and integrated”?

I guess that it is very hard to define this because the boundaries of system testing are elastic, and this is true since the boundaries of an arbitrary system are hard to define. Still, we use the term “system testing” daily.

So what is my point really?

I have often found interesting things just by thinking on what system I am working with. I have found out that some things are really outside the boundaries that I first believed were in; and perhaps more useful has been to find things that really should be included in my system and the system testing. And the boundaries might stretch the further you get in a project; what was a complete and fully integrated system during the first half of the project might just be a sub-part at the end of the project.

So my advice is that you take a few minutes now and then in order to seriously ponder the boundaries of Your system. It will affect the type of testing You choose to focus on; and it will be a good aid in order to get a proper and valid test coverage.

Recently in Sweden there was a tragic death to a young child that could have been rescued if only the child had come to a hospital in time for a full exam. The one that was blamed for this death was the medical care hotline company that did not understand the severity of the illness and did not send this kid to the hospital. (Read more, in Swedish: http://www.dn.se/sthlm/pojke-dog-efter-rad-att-inte-aka-till-sjukhuset-1.859096)

After this tragic accident, it was discovered that this private medical care hotline company pays out a monthly bonus to those nurses that keep their phone calls short. (Read more, in Swedish: http://www.dn.se/sthlm/skoterskor-far-bonus-for-snabba-rad-1.864534 )
I.e. if they keep the call below 3.48 minutes and during that time complete the medical record, they receive a bonus of 1000 Swedish kronor (approx. € 100). In order to receive the bonus, there are some quality goals as well. E.g., you don’t get the bonus if you unnecessarily send someone to the emergency ward; or if you give a faulty medical advice.
Do I need to tell you that the county council paid the private company by the number of calls they handled.

This is what happens when you use simplified and dangerous metrics as a foundation for incentive pay… And these metrics are easy to abuse because they are based on simplified models of how the real world looks like.
When dealing with people, you are dealing with “complex systems” (read more in An Introduction to General Systems Thinking, by Gerald M. Weinberg ) and you cannot treat every person like they would be the same. I.e., the people calling in (and indeed children that cannot speak for themselves) are treated as a neutral “* 1” or “+ 0” in the metrics equation.
This happens if you include simplified metrics to measure your efficiency when dealing with people; metrics that leaves out the most important and complex parts of the equation: humans and human interaction.
Nurses know how to work with people, they know that people are unique; they know that their job is hard and requires skill and years of experience. They know that some patients require 20 minutes before they are calm or they need such time to explain everything important; they also know that some people just need 25 seconds before they are satisfied.
It is a shame that nurses are measured by how fast they finish a phone call.

It is the same thing that happens again and again in software industry; or rather the peopleware industry. People that work with developing software are measured by metrics that are dangerous and wrong; and in many cases it can have the same tragic outcome as with the young boy that did not reach the hospital in time…

Read more about (dangerous) metrics in the Software Industry:
Software Engineering Metrics: What Do They Measure and How Do We Know?, by Cem Kaner.
Metrics, Schmetrics, by Matthew Heusser.
Meaningful Metrics, by Michael Bolton
Measurements/Metrics/Analysis/Judgment, by Rikard Edgren