Constantly remind the team that your intent and feedback as a QA resource is always to represent the customer and push for great product experience

If you really want to be an elite QA person, part of achieving this goal will be your willingness and non-stop effort to provide feedback to whatever parts of the company are introducing risk to product features, timely delivery, and user experience.

These main attributes will separate you from QA resources that are, what I like to call, "button pushers" or "test automation monkeys" and prove the real value of your expertise to the product and the team.

It is not an easy thing to do.

One of the major reasons that it's not easy is because most QA teams work for an engineering organization on the company's org chart and any honest and constructive, critical feedback will always be discouraged. It can be considered a conflict of interest. We still do live in the world, unfortunately, of office politics. Any good intention and truthfulness exposing activities within the company that are genuinely negatively affecting the product and user experience will normally not be taken and perceived with true intention from the QA person, or perhaps because traditionally the development team doesn't respect the QA team because of their lack of technical skills.

It's unfortunate, but true, in a majority of traditional product development teams.

Do not let the potential of friction with development or product teams discourage you from expressing your very well-informed opinions. If you have data showing high bug counts and can show risk at certain points in the development cycle, then it is almost impossible for anyone to have a rebuttal to your recommendations.

Data drives decisions. And as the rock star QA person, you have all the data you need to prove your points because you know the product and user experience better than anyone else in the company.

Smart teams, and smart team members, will respect your opinions and want to make the necessary incremental changes that you recommend.

And most of all, eventually, if they are honest with themselves, those team members will realize that your feedback is entirely given with intent of best possible product quality and excellent user experience. Your feedback is intended for better product experience of the customer.

Embrace the friction and make the product better.

I'm a Professional SQA Engineer, so please don't consider me a SWET

Although I am very truly grateful and appreciative when I get emails from recruiters wanting to interview me for the newly minted job title of Software Engineer In Test (SWET) job requisition at their company, searched on from my LinkedIn profile or other resume job posting in the recent past, I always immediately delete the email.

Why?

Because I am not a SWET.

I gave up being a software engineer in 2008 after 25 years of being a paid code monkey. I transitioned from being a software engineer and architect several years ago, because I wanted to make a positive and dramatic impact on User Experience (UX) and overall software quality as a Quality Assurance Engineer.

I have software development and object-oriented design skills in several languages.

I have been a Motorola 68010 Applesoft and assembly programmer since 1983.

I started programming in Java in 1994. I was a software engineer and architect in 1996 when the only way you could create a functional website with dynamic web pages was with either Active Server Pages (ASP - Windows) and CGI Perl (Unix) and I developed functional websites with Java Servlets and JSP in 1998 when the spec first was released to the public. Before EJB. Before AOP. Before SOA. Which, of course, I was also a developer and Architect during those times.

In recent years, I have been a leader and architect in developing software with the purpose for rapidly automation software testing.

However, consider this: I am a Software Quality Assurance professional and my deep background in software development has NOTHING to do with my qualifications as a SQA Engineer, and doing testing at the very highest level.

Why? Because my passion has always been for the best and most enjoyable user experience and best possible software delivered to......

Why? Because I identify potential process and team friction points and bring them to attention, because I realize those have much potential impact on software quality for.....

Why? I realize that a chosen software development process by may not be the working out for the best at that particular time in the evolution phase of the company, and that any chaos and missed product development deadlines will always negatively affect.... 

Why? Because if I can get automated tests working non-stop and seeing positive and consistently good test results (100% pass rate) then I feel more confident that all this effort benefits....

Why? Because everything I do during the workday, every decision I make to prioritize the many tasks I have to perform, I always keep one thing in mind.....

The customer.

The end user.

The person who deserves the best product experience and needs it to positively impact their lives and want to use it everyday, because it benefits them and makes their life better. From a personal/consumer usage perspective. From an enterprise/for pay product perspective.

Your customer deserves the very best every single day. Your job as a Quality Assurance Engineer is to do everything you can to make that happen.

Pushing buttons on a mobile device and writing automated tests and providing reports on test pass/fail results don't impact on software quality, but YOU can if you choose to.