I think this is a valid and valuable observation for team dynamics within the SDLC. The lack of experience indicates the gaps in "opinion/frustration" versus the actual topic/question that should be asked. In this case the question you are posing is the following:
"How do I constructively increase the value put on "Quality" inside of a development team dynamic, while at the same time increasing my ability to work well in this environment?"
There are a number of factors at play and the first is the most important.
- How many quality issues currently exist in the product/process?
The goal of QA is to ensure the quality. The amount of slippage in quality is a direct connection to the importance of the role. If there are never any issues, find another place as you will not have much value there. If there are tons of issues, then it is alerting everyone of the issues and proving that the current cycle will not work "successfully" without additional QA activities.
- How able are you to meet others where they are as well as understanding your own perspective?
You may find 40 issues, but if noone else cares about them including the Product Owner and customers then you need to adjust your perspective. The point of any job is to be useful, so you need to understand the goal and make your QA observations in support of the end goal. Being in sync with the Product Owner goal and finding gaps to accomplishing that is where your role fits, so any observations should support an "inadequacy" in the goal of the product (functionality, usability, speed, consistency, 508 compliance, security, etc...)
- How much pride exists in your team of developers?
I have worked as a developer myself for years and with hundreds of developers from a QA standpoint as well. Pride of ones work is always there and sometimes hubris in developers. QA is often seen as the critical poker of pointing out flaws in others artistic genius. The goal is a "quality product" not individual fulfillment, however in order to achieve a team dynamic every individual must feel needed and appreciated...as your comment indicates you don't feel that which frustrates you. You need to meet the developer where they are and help them to see how to make a better product. This may involve you learning some code and understanding the backend terms. I also recommend a question approach as that gives them the "expert" stance they feel from writing the code.
So instead of saying "this is broken and I can't use this" ask, I think I'm doing this right, but I can't seem to get this to work, is there something I'm doing wrong? Then you ask what about this and this part seemed like it would confuse users because of x, what do you think? This will make life so much easier on you as in fact this approach will help you "enable" developers to improve their coding, while at the same time ensuring they still feel good about their work. Understanding how the application fits together underneath is key to pinpointing the right places to test as well as the right places to ask questions to improve quality.
Lastly I'd say since you mentioned the PO, that the Scrum Master is supposed to ensure all parts are working together, so ensure you are targeting their goals and getting them to say something if it's not working together. Perhaps that person will have more tips for you.
Good luck and don't give up, but grow into a more team empowering person and SQA individual!