How to communicate the value of QA & Testing to senior management

Question

I've recently taken a position as QA Lead/Manager at a small company that has been developing software for over 10 years. However, they have never had a professional tester or any QA department.

I am finding it very difficult in trying to get senior management to understand the importance of testing and the importance of change management (it's very hard to change a culture of over a decade).

They are looking to move to agile very soon (next 3-4 weeks after our last big waterfall release) but yet are still asking developers to add new features into the release now without any discussion on the impact that will have to development, test and release date.

I come from an enterprise software background where the QA department had already been set up. This new job was always going to be a challenge. Is there any advice?

Thanks,

Answer 1

Yes you have a lot of education to do for them.

Start with a high level concept:

Advocate for prevention over detection

Be simple. Say that and then be quiet. Let company management have a conversation with you and make sure they are on-board with this concept Without buy-in to this idea you're going to have a hard time with anything else detailed below.

I would start by identifying and communicating the processes that allowed these bugs to occur (if possible) and then, more significantly, on processes you wish to introduce that will prevent future bugs

I'd recommend using the Agile opportunity to introduce qa.
Explain that unlike traditional waterfall setups where you get requirements, write the code and then have QA test it. In Agile QA needs to be part of the development process itself.

Explain that for Agile the idea is that QA is embedded with the the dev team and is looking to prevent bugs in the first place. Would they rather have QA fixing bugs that cost the money or prevent them in the first place. Make clear that when you move to QA preventing bugs their work will actually be less visible. No pile of bug reports showing their worth, waiting for dev to fix, instead working software that avoid bugs in the first place.

Specifically you'll want to make sure the the development team (including QA) are using good approaches such as:

• Multi device,browser and version testing. Get your site stats from your server logs and see what users are using. Make sure management are aware that developers can't check all devices and browsers and versions. It's impractical and they won't do it.
• Making sure that the company's metrics for quality are being used. For some this would mean more revenue, for others more new users, for others greater market share.
• TDD/BDD You dont have to write the tests before the actual code, however make sure they are written before the code is finished and merged into master. Management need to know that this is practice is being used so they can observe when it is not followed.
• Brand your work QE - Quality Engineering over QA - Quality Assurance to emphasis the engineering aspect of a modern Quality shop and to make it clear that this isn't just about manual testing
• Page Object approach to using selectors. Be passionate about good practices like this to gain respect from developers who are passionate about code practices.
• Identify happy, sad and optional flows for automating to make sure that the product has good test coverage
• Use tools that analyze code and test coverage and show you where work is needed
• When introducing the Agile approach make sure that the definition of done includes approval for QE, however be careful not to make a QE roadblock for all tickets. Be selective.

Show management various examples of when quality engineering would have helped. This requires both patience and tact. You should have several opportunities over the course of a year to highlight bugs that cost the company money and could have been protected with better Quality Engineering. If you have no examples over a year it's going to be pretty hard to persuade folks of the practical value of QE

Answer 2

It depends on the size of your company and the software product you make.

It is not uncommon for a company that does not need a dedicated QA department.

My advice is:

• Use facts to convince them. During Agile sprints, if you can collect information that demonstrates having a dedicated QA team is better than having none. Such as the number of bugs that get to production and etc.