This answer addresses the last part of the question: "why can't qualification testing be automated". You have a good point, but we need to clarify some terminology.

As an aside, the earlier parts of the question have some inevitable overlap with this question here by the same OP.

Back to automation. There are two distinct concepts in testing for satellites. There is Qualification testing and Acceptance testing. Where a piece of equipment will have a "large" production run, i.e. hundreds (thrusters, amplifiers) or thousands (solar cells) then acceptance testing is a much more intuitive candidate for automation than qualification.

There are probably others who could make this distinction more formally though this is it in human terms:

• The aim of qualification is to demonstrate that the design works and has sufficient margin to be tolerant of allowable build variations. It is usually done on just one or a small number of flight-standard production items.
• The aim of acceptance is to demonstrate that there are no workmanship errors in each item in the production run.

Loosely, qualification testing is more severe and intrusive than acceptance testing and the tested item would usually be considered to be degraded by the qualification experience, e.g. already having suffered a lifetime of use, and would not subsequently be used for flight.

There is a relatively commonly understood range of names given to different levels in the integration process: piece part, tray, sub-assembly, equipment, subsystem, spacecraft and the concepts of qualification and acceptance can be found at every level. Whole spacecraft are often (not exclusively) subject to a middle ground in test-severity terms, called proto-flight testing, which reflects the customer's risk-tolerance and agreement that it would cost too much to build an entire satellite, test it and then never use it.

This answer addresses the last part of the question: "why can't qualification testing be automated". You have a good point, but we need to clarify some terminology.

As an aside, the earlier parts of the question have some inevitable overlap with this question here by the same OP.

Back to automation. There are two distinct concepts in testing for satellites. There is Qualification testing and Acceptance testing. Where a piece of equipment will have a "large" production run, i.e. hundreds (thrusters, amplifiers) or thousands (solar cells) then acceptance testing is a much more intuitive candidate for automation than qualification.

There are probably others who could make this distinction more formally though this is it in human terms:

• The aim of qualification is to demonstrate that the design works and has sufficient margin to be tolerant of allowable build variations. It is usually done on just one or a small number of flight-standard production items.
• The aim of acceptance is to demonstrate that there are no workmanship errors in each item in the production run.

Loosely, qualification testing is more severe and intrusive than acceptance testing and the tested item would usually be considered to be degraded by the qualification experience, e.g. already having suffered a lifetime of use, and would not subsequently be used for flight.

There is a relatively commonly understood range of names given to different levels in the integration process: piece part, tray, sub-assembly, equipment, subsystem, spacecraft and the concepts of qualification and acceptance can be found at every level. Whole spacecraft are often (not exclusively) subject to a middle ground in test-severity terms, called proto-flight testing, which reflects the customer's risk-tolerance and agreement that it would cost too much to build an entire satellite, test it and then never use it.