Imagine you’ve joined a new organization as a QA manager and you see a great product. The product you think which can be next big thing.

Sure your new company isn’t where it can be right now, but it has huge potential.

So as a QA manager or anyone in charge of quality for that matter, where will you begin your job?

In most cases, companies hire staff for testing and leave them on their own. So when you are all alone against big responsibility, what to do?

We’ve created this guide to help managers with the challenges they face on daily basis in such situations. Our goal with this guide is to prevent reactive management and prepare for many things upfront.

With this guide, you’ll start with the basic questions and work your way to the top to solve bigger challenges and reach your goals as a team. Constantly working with these questions in mind, you’ll also help your organization have a great testing strategy in place.

Before you begin, you need to understand that quality doesn’t happen by chance. It happens because of a process. And the process is created by people, in this case, you. Maybe you already have a process, but it’s never a bad idea to improve or stop and evaluate it to keep the process up to date.

If you have a process, and you still find yourself under a lot of stress because of the job, then it’s the process to blame. If people who work under you aren’t delivering as well as they should, again, it’s the process – not them.

Many times we have observed a team start using a test management tool, and that’s about end of their testing process. A test management tool is just a beginning – and you still have to set some conventions on how to use it.

It is important to know that this blog post isn’t going to solve your immediate challenges or problems. It is preparing you to build a scalable process which will improve itself over time.

For any process to be successful, it has to be accepted. For acceptance, it should have something for everyone. As a manager, it starts with you personally, then to people you manage and the senior management.

To get started, you need to begin with these simple question:

– What?

– Why?

– How?

– Where?

– When?

As you read further, you’ll see how these simple questions can get really complicated when you put in the complexity of a real-world application and team dynamics in place.

These are simple straight-forward questions, and if you and your team can answer this you’re already doing a good job as manager.

But sad truth is, it’s often difficult.

Let’s elaborate further on what they really mean…

WHAT?

Nowadays no application is simple enough, and as a QA manager your job begins with asking ‘what you’ll be testing?’

When you do ask that you’ll have further information about this ‘what’, and soon the simple looking thing will begin to open up more.

Say, you’re in charge of testing a web application, so you’re ‘what’ becomes ‘web application’, but it might not be simple enough, right?

Maybe you distribute this web application as a package to clients, in that case, your ‘what’ will include a list of all platforms your company supports.

Your list of ‘what(s)’:

– Web application

– Web application on Windows server

– Web application on Linux server

What if you support, multiple database adapters like MySQL, PostgreSQL, SQLite, and so on…

Your “list of what(s)” become even more complicated. Of course, at this stage, you’ll need to prioritize because it is likely that 80% of your clients use 20% of options. But the point is to know these in advance when you’re designing a process.

Even this is a small part of ‘what’, what if you offer a plugin with your application, your list of ‘what(s)’ grows exponentially with each and every variable. And these all are part of the equation: environments, configurations, and platforms.

For a mobile app testing, platforms will be various devices which you want to support and different OS (Android / iOS etc.)

WHY?

This part has to do more with human psychology than your application.

Many QA managers get thrown a lot of work at them by management. As a result, they are often left alone with testers with a lot of work.

A lot of managers don’t ask and share this, but I think it’s really important: it’s answering the ‘why?’

Yes, why should they test something?

What’s at stake?

Are they testing database app for a large corporation that will suffer serious damages if it goes offline?

– or –

Are they testing a B2B app which is only used for few minutes a day?

More powerful your ‘why’ is, more testing efforts will be required to ensure you can deliver such level of quality.

Your team, especially testers need to be explained this ‘why’ explicitly. If they know what’s at stake and that’s a good reason for them – they’ll give you their best. But if it’s for some unknown reason they don’t know, ‘they’re just doing their job’.

Do not assume they know already. Don’t, seriously! Instead, keep communicating this why at every important milestone or before every new release.

Depending on context, you will have different ‘whys’ every week and every month (say when you’re pushing out new releases or hotfixes). You’ll still have a big permanent ‘why’ (your organization goals or values) which will reflect your long-term goal.

It’ll also motivate your testers to excel themselves and be responsible.

What do you think will work more towards motivating your testers:

“I need this application tested by Monday so we can release by Wednesday.”

– or –

“If we do not launch this by Monday, then our customers will not be able to work with their marketing campaigns next week which will cause them serious losses in coming Holiday season.”

What if you have more than one ‘why’?

Find the most powerful one which resonates with all your team and use that.

Takeaway: Work on this ‘why’ for the whole team and communicate regularly. You are not working with robots who do what you ask them to do, you’re working with real people, emotional beings who are motivated by reason and logic.

HOW?

Now is the time to get technical with nitty-gritty details, the heart of your process: how.

The prerequisite for making a scalable process is that everybody in the team should understand how to do something they’re supposed to. In quality assurance context, this would be:

• how your application will be tested? (list of all cases)
  
• how to test a particular case? (most important)
  
• how to test a particular feature?
  
• how to prepare test environments for testing?
  
• how different these environments behave?
  
• how to test a particular case: manually or automated?
  

.. or more depending on your business.

If you or a team member are spending time again and again in explaining this ‘how’ then you’re doing it wrong and the process cannot be scalable.

You need a proper place to store all your test cases with detailed steps in easy to understand and executable steps. Obviously, all basic test management tools can do this for you.

Read our article to learn how to write test cases to know more.

These are good primary questions to get you started.

WHEN?

Next piece of the puzzle in creating a beautiful scalable testing process is asking yourself ‘when do you test?’.

When do you test, currently?

and also

When are you supposed to test, but don’t?

The significant problem in almost every organization is seeing testing as something to be done before release or this attitude:

‘we’ll take care of it once development is done’

Of course, agile development practices is changing it and if you do follow it you’re probably paying more attention to testing than a team on waterfall model, but that doesn’t mean your team may be doing everything right.

Each stage of your application lifecycle will pose a unique challenge for developers and testers. Let’s take a look at each stage:

(you may have more stages with different requirements but I’m trying to keep this short to give you an idea)

1. Planning:
   Your team is brainstorming the idea for this brand new mobile app and all of you have decided the features. That’s when you start documenting.
   All your app requirements have to be put in place so everyone in the team has a good idea of the final picture.
   Then once requirements are documented, you’ll be defining how these requirements will be fulfilled and how a feature will behave.
   Many teams are not doing this, but should.
   
2. Development:
   It goes without saying that each commit will bring some risk to your codebase. Each commit has potential to break one or more things.
   So this is another stage where you’ll be testing. Ideal solution for testing this is with continuous integration as you cannot do this manually.
   Knowing what broke the build will give you everything you need at this stage.
   Some teams also benefit from a combination of a continuous and nightly build. Nightly builds can be great for running automated tests that take a lot of time and are less important.
   
3. Pre-release:
   This is the critical stage where you absolutely have to make sure that everything works. You want to be as extensive as you need to be.
   If you do not release quite frequently, then think about all potential disasters that can happen and document each of them.
   If you release frequently, then make it a practice to release to a staging environment automatically first and then pushing anything to production.
   
4. Post-Release:
   Once you have released your application or update, you have to ensure it stays healthy. What steps have been taken to monitor the deployed app?
   How and when will the production instances will be tested to make sure they work as expected?
   

WHERE?

Depending on your application development stage or deployment type, eventually, you have to get on to define ‘where’ of the whole testing process.

Nowadays every development team has multiple deployments for their apps on staging and production. Some might even have more.

Needless to say, how important it is that each of your developer and tester should be made aware of where these deployments are and how to access these.

Your testing process will contain rules on where to test your app (and when as discussed above). Again these different deployments will behave differently and you’ll need to document these differences.

As an example, your staging environment might be a copy of your production app with few configuration changes. You will need to make sure that a staging instance should have some restrictions so that it cannot interact with other production APIs.

Does your app send emails in production? If yes, how does email sending work in staging environment?

If data is copied from production to staging for soft releases, are there automated checks in place to avoid sending emails to the real clients?

.. or avoid calling external APIs from staging environment?

Of course, this is just scratching the surface, but you get the idea. You need to brainstorm well and have your team on board with all such differences. Then document these in your test management tool so everyone in your team knows and tests accordingly.

If you do 3rd party deployments, then you might also need to document all assets to test. For this step, it’s a good idea to classify 2 things:

– Test subjects (various deployments to be tested)

– Behavior (there will be some difference between how app behaves in production and in staging – document that)

Another good idea would be to have a key responsible person for each critical deployment. If you can give them a little control over staging environment or others, it carries no risk for you and your teammate may learn a lot.

Summary

It is important to understand that these basic questions will turn your efforts into a big framework or a process. You could use all the fancy testing jargon (contextual testing, agile testing…) but if your team is not on the same wavelength as you – then the whole process falls apart.

And that is where a test management tool comes in, to answer these questions. To carry this out – you need to spend a good amount of time in information collection and sit down with your team more than once.

One of the biggest mistake any manager can make is seeing only one facade of quality assurance process and not realizing that it has several more.

This way of thinking (starting with basic questions) will also help you in preparing your testing strategy as well as help in carrying out execution because

– you’re defining a very clear set of goals for each member of your team.

– all the information and contexts are mapped out upfront.

– you are making decisions in advance and scheduling based on all the information gathered above.

If you liked this article, please comment below and let us know. Thanks for reading!

‍