What is a Scrum Development Team - 7 minute Guide

I have noticed in many places that are working on implementing Agile methodology a popular misconception around the question who are the Scrum Development Team.
Most people wrongly assume that it is the de facto developers who write the code and when I point out that it is not the case it is being met by dismay and skepticism.

"Developers are developers, who else can development team be?" I was told once in a such discussion, and the answers to that is hidden with in the Scrum guide

If one will go and carefully review the guide one can find the following definition there:

"The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint."

Take a note of the phrase "... rofessionals who do the work of delivering..." those are not only the developers who write the code but also the Testers who test the code, the BAs who taking care of Backlog items to be kept in tact and so on.
To support that understanding the following can be found in the guide as well:

Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment

Again the clear pattern is emerging that the Scrum development Team is professionals of different trades that came together to create something new - a "Done" increment if you will.

But then there is a big question why we cannot find any mention of QAs, BAs, Developers (as pure code writes anywhere in the Scrum Guide?

The answer to that is simple enough because the whole idea of Scum is against it:

Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person

Scrum is about working together as a group and allowing each team member to do its best to contribute to the successful delivery of the "Done" increment.

Why this definition is important?
In my experience it happens that QA and BA team members work effort are being forgotten during the planning and estimation of the Product Backlog items, and the focal point lies with the de facto developers. This approach results in inaccurate estimation and unsuccessful Sprints when the Product backlog Items cannot be delivered on time because of additional and accountable  work that was required to complete the specific increment.