You might also consider the case when several programs depending one on another are developed simultaneously. You have then to take into account the applicative architecture which groups all those applications into several functional domains
So, for instance, a financial application having to process a large number of data would be one functional domain, in which you would have to develop a:
- dispatcher module in order to process those data on several computers
- GUI in order to see what is going on
- launcher in order to initiate the right connections retrieve the correct data and format them
- and so on
But that would only be one functional domain, as others would have to be developed in order to exploit the results of your programs (for instance, a "referential domain" would be there to store those results into various databases, and offer a communication bus for other programs to access them: that would be a second functional domain).
So I would add to your tests the following categories:
- Assembly testing: when you test within your own functional domain (on an assembly server when you deploy the different applications of your domain, with a set of testing data)
- Integration testing: when you test all the applications from all the functional domains, which is also called front-to-end testing.
Note: "integration testing" is not the same as "continuous integration testing", which basically can process the black and white tests you describe, for one program, on a very regular basis.
The tests I am referring to are executed a few times a week by an:
- "Project Operational Architecture" team of your domain for assembly tests: usually some developers of your team which set up an assembly server, check if the data are up-to-date and deploy the various program you are in charge to develop.
- "Production Operational Architectural" team, in charge of setting a "production-like" environment and who is the only one able to really test the all chain of application from font to back.
Note: an "Operation Architecture" team has the role to "make operational an execution environment", meaning to have:
- the right logistic team contacts in order to have the right servers and networks,
- the right application teams contacts in order to know about the various start/stop application processes and deployment procedures of all the application of your system!
In short: your categories are for one program, but when you are developing an IS (Information System), you are forced to acknowledge the fact that you are not talking about "one exe developed by one team deployed on one production machine"... and then, welcome to an all new world of testing ;)