As a Software Quality Engineer (for about 10 years now) I have been giving teams advice on how to improve their process all the time, with great success.
He said it's not QA's responsibility to add processes or suggest
anything that's why the team don't like it. They see you as a
I have to clear disagree with this remark, hopeful I can explain why I think it is QA's responsibility. Let's start with the three aspects of software quality:
- Functional quality: This is what most QA focus on, e.g. testing from a user perspective.
- Structural quality: This is was Agile QA should focus on if you ask me. From the Agile manifesto: "Continuous attention to technical excellence and good design enhances agility.". Teach developers to build testable code and how to refactor-safely with the goal to create software that does not resist change.
- Process quality: Going from requirement collection to product delivery. Actually the whole SDLC should be a QA responsibility. There is so much to improve, so many risks to minimize. Focusing on Agile risk management helps to get influence, as it is a clear QA task to remove risks in the process for the users and sponsors competitive advantage.
These three aspects are of equal importance. If you are only a functional tester it is hard to get respected on vision in the other quality aspects. Structural quality could be a developer responsibility, but often they lack the knowledge and urgency to improve here. Process quality could be the main responsibility of a Scrum Masters, but they often focus on project management and not product quality. Even if the Scrum Guide describes this: "During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate". So YES there is a lot of overlap with other roles, but still enough room for the QA to focus on.
When starting at a new company I would do one-on-one status-quo interviews and or training with all personal (CEO, Managers, Key-Users, Key-Stakeholders, Developers, Product Owners and Scrum Masters) explain them the difference between these three quality aspects, internal vs external quality and maybe the Agile testing quadrants and which skills this entails. Showing you have broad knowledge of all aspects of software development. This will help accepting suggestions you make greatly, set yourself as THE quality guy or girl.
Something I have learned over the years:
- Act confident, but with respect. Truely believe what you advocate.
- Describe or visualize the problem. Let the team find a solution. Only suggest solutions when they ask you. This will make adoption of changes easier. Even better let the team do a research activity, not a single person.
- Changes in culture are slow, this can take up to three or more years. The ones repeating often, but quietly tend to win this culture change race. Making a big fuss is never a good strategy for cultural change.
- Being a Scrum Master gives you greater influence. Reading up on Agile and Agile testing can be the first steps into this path. I have been working in a dual role (QA + Scrum Master) since 2009. Seems to work great for me.
- Ask the Scrum Master or Agile coach to help you implement a change in behavior. Let them describe the problems to team.
- Use retrospectives and keep repeating serious process issues you see them. Try to not talk in solutions. Explain the WHY, not the What and How. Same as with perfect User-Stories. :)
- As a last resort I always like to quote Martin Fowler: "If you can't change your organization, change your organization!"