Continous delivery (CD from now on)
Each commit to GIT causes the integration machine to build the
project, run both unit and integration tests and notify about the
result. And now - the app gets deployed to a test environment so as to
perform QA activities by QA guys. Is that continuous delivery?
The case you expose might not be considered CD
Companies like mine use Jenkins (CI tool) to automate the process of performing unit tests, packaging and deployment in test servers after Git commits. But this is quite far to be CD. It just serves us to save time and keep the wheel (QA or other dev teams) moving on.
CD is an strategy applied to software lifecycle. To the whole lifecycle
It has by main goal to reduce costs times and risk. How? Producing software in short cycles, performing test, builds and releases frequently.
Frequent deployments on production (release) demands flexebility at delivery management. What it's intended is to release bugs fixs/upgrades/updates anytime. As straightforward as possible. Moreover, by any member of the team.
Other reasons behind CD: high availability is needed (by critical systems) or continous feedback from users (or customer) is wanted.
Back to the question: Should Continous Integration do deployments on environments?
Answer: We are mixing concepts.
CI is related to make periodic the process of compiling and testing, in order to garantee the stability of the code during its life time. Happens here that CI tools are also capable to perform deployments. But such "capability" (being dogmatic) is not related to CI.
However It's a good way to say: "I can be used as tool for deployments if you need to automate deployments".
and why?
As we pointed CD aims at building and test frequently. Here is where CI shinnes. It automate such task.. But the task itself is just a part of the lifecycle.