The question came up recently; what is the difference between testing a package to in house software? The very quick answer is none. Now before things get heated there is a longer explanation behind the quick response.
What is the general principle for testing? Making sure the change coming in works as it should and to mitigate risks of failure seeing how applications react in exception situations. Whether the change is in an application itself or there are peripheral systems that have changed or be impacted by others. Things still need to be understood, planned, executed against and validated.
Where the difference lies is the Service Level Agreement or contract the organization has with the vendor of choice. Most organizations will have sections in contracts that state the level of quality and test expectations they have with the vendor of choice. Normally they are very high standards. After the delivery of the change there is some form of testing that goes on afterwards.
Look at OS changes and updates. For the most part they are pushed to systems without a second thought. Personal computers get them all the time. Does that mean that Jane Smith will specifically go out and test all the changes that come in to her computer? Not explicitly. For organizations who use a third party software that is embedded in their product that is where things get a little less implicit.
Embedded software is becoming the thing to do as it is easier to partner with someone that already has functionality built and get it integrated than to build in house and potentially lose out on clients to the competition. Normally this is a very detailed process when an organization that makes that type of decision, for the sake of the blog I am making the assumption that the organization is working with a Third party partner.
When they make updates, changes or have regular releases. The main expectation is that the partner did all the testing they needed to do to ensure the product is viable. Depending on the use and integration there could be a few parameter or configuration changes that need to happen and will need to be tested.
In the end it becomes very “Black box” testing, similar to a User Acceptance Test (which is basically what package testing is in the end) where it is being looked at prior to giving it to clients to use with any additional changes to other software or just pushing through basic upgrades.
Plan, Do, Check, Act it is all the same general process for testing changes it is only in some of the details and granularity that a Test group will go through between packaged software or in-house software builds.