It seems like the understanding of ChatGPT is that 'testing', as done by a human, can also be done (act of examining) by a tool....
I have to admit it got a bit better after giving it a couple of feedback rounds (3)

I think I made it finally too difficult for ChatGPT:

Ultimately I asked:

From a respected and experienced software tester in the field I got the following feedback.
​

Well, before we can answer the question if something CAN or CAN'T be tested we first need to know what 'TESTED' means. Let's take Wikipedia as a starting point for the sake of simplicity:
​
Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to: .....etc
​

The difficulty with this page (read the full page) is that it does NOT say that this examining must be done by a person who's official role is software tester on the monthly payment slip.
In many places however the expectations are that those people are the ones that do the testing.

 -What is it about some things that prevent them from being tested?
​

We all know these type of overlapping circles, right?

If we only talk about the person in the role of software tester doing the actual testing... then there can be many reasons why the examining by this person can not be done.
- lack of application knowledge.
- lack of domain expertise (no knowledge of banking, insurances, etc)
- lack of SQL knowledge (not possible to verify if this new code is technically okay)
- lack of experience in software testing (incl. test methods / test techniques / etc.. )
- etc

Whatever the case, it is resulting in: testing can't be done... by that person. (or assistance is needed.) But does that mean that something can not be tested? 
Well, NO! because maybe some more experienced tester can test it, or some other person in the company with huge amounts of application knowledge. Maybe together they can test it?

So, again, what is the actual meaning of: it can not be tested?
Isn't it a more technical related statement then? 
Sometimes as tester we hear the phrase: only the production environment is suitable for that.
or
Only the production environment is set-up in that way.

So does that mean that all testing has to be done before production, but...
when things are in production, then the "test phase" is actually still lasting because... (otherwise not "everything" can be tested)?

- Why does this matter?
It matters because as a well respected software tester you want happy customers of course. You want to give an organisation the information that they need, an as good as possible status overview of the test object at hand.
In order to being able to do that you need to know 'what can be tested? / what can't be tested?'.
You need to know: what should I test? what is being tested by others?
Is it okay that not everything is verified (examined) by me?
Preferably you would like to read what an organisation's test policy, test strategy and view on software testing is.
Is the test report or the advice of the test team decisive for the product going live?
Maybe not and management sees the report as an advice or guideline and decides (for whatever reasons necessary) to go live despite the report recommending the contrary.

Does the statement 'It can't be tested revert to a person (or team)?'
In some cases a person is not able to test it. (a part of the artifact)
In some cases a person was not even allocated to test it. (a part of the artifact).
or does the statement 'It can't be tested to the test object?
Maybe in some cases it is not even possible to "test the object under test"...
but it is very hard to come up with a good example.

So maybe 'It can not be tested' should be looked at more like:
Not everything can be tested well under the circumstances presented to the tester at the time?

Maybe a better (underlying) question (then: Is everything testable/tested?) is:
Should everything always go according to plan?
But that arises new problems... Because what is that plan then? (are we talking about a test plan in such case?). Is it possible to get everything in that plan? considering:

Who's got input for Chapter 3?
I'd really would like examples of situations or scenario's when something was literally NOT testable! ​

There are lot's of websites talking about the theoretical aspects of software testing. However, far little websites talk about all practical aspects of projects and companies. 

So in theory a company can have a test policy, and/or a MasterTestPlan (MTP). It can even go as far that they have the work processes arranged in a manner that if they would do a TTMi or similar check-up they would score a level-5 optimized! wow great.

It doesn't say anything about what a software tester will encounter on the work floor during his working days. Most of the websites that write about software testing write in a way as of it seems "everything can be tested".
Whilst after almost 20 years of software testing you've learned, that is not entirely accurate.

To break it down there are nuances in this:
1) It can be tested, but not by the/this software tester.
2) It can't be tested in this environment (proof is in the pudding, production)

Scenario 1:
Can be caused by lack of application knowledge, lack of test (methods/techniques/...) experience.
Whatever the case, the tester needs help from another person in the organisation or even the testers needs confirmation (for verification) from another person that the outcome is correct.

Scenario 2: 
For several kinds of reasons, sometimes testing is very hard or even impossible. 
Thinking of a expensive mission to Mars makes this scenario easier to imagine.
(A little helicopter on Mars once functioned beyond expectation by the way)

Fact is that there are things that can be controlled and things that can't be controlled. An example of my own experiences is:

Although there were rules about putting new programming code into production, an employee (developer) himself determined what he did.

This is just an example, but my point is... : 
Try to find a website that tells you what to do in such cases! Show me the website were that is explained?

Are such moments unique? of course not, they happen all the time. Constantly.

In theory everything could be systematically and structured, but that is almost never the case. For some reason, some client finds a bug and it appears that the bug has big impact and thus high priority all of a sudden.
If we think back of the scenario's 1 and 2, of course it is more a scenario 2 like problem.

Can you honestly say as a software tester that of a new version of the software, everything that is new in that version has actually been (re)viewed by yourself?
No, but that is many cases in stark contrast with the expectations of our role.

Reality is:
(In scenario 0 we can test.)
​In scenario 1 we can assist.
In scenario 2 we can only sit and wait.