How to start a test team in a company?

A while ago I saw a question on the Ministry of Testing Slack channel that I’ve heard asked a number of times before.

Has anyone started a QA team in a company? How did you do it? What did you do first?

Context: This was asked by someone who needed to do this and had never done it before.

What advice would you give someone starting from the ground up? It can seem pretty daunting, particularly if you’re on your own.

1 Like

I haven’t had to pave the way for a new test team, but knowing the transition from waterfall to agile, having upper management buy-in is really important. From there you can work towards development team trust and buy-in. One of the keys to success is building strong relationships with the developers and providing value to the product team throughout the development process. If you can show and communicate the value of what your providing the buy-in comes naturally and there is a good chance the QA team members will be sought after from different teams.


It’s a good Idea to start a QA Team as many organization are started giving importance to QA.

No matter how strong an idea you have, the fate of your startup ultimately rests on the shoulders of your team. After all, it could take only one weak member to bring down your entire business.

I have shared URL, you can prefer that to know how to start your QA Team?

I loved it.

1 Like

I’ve started 2y ago in my current company with the goal to build a QA team. I didn’t have such a previous experience, but had lots of other experience in QA, so decided to take the challenge. The first thing I did was actually a decision not to build a QA team at all, but to get some experienced people from various roles that can help implementing QA processes in development to work in our existing development setup. Why not having a QA team, well, simple, there were already existing dev teams, and having another hierarchy level wouldn’t bring any value. Together with some other stakeholders we defined the roles we needed to hire in order to cover all tasks in QA and who can fit our current agile teams. The roles we decided to go for were created according to our tech stack and product. So, we started searching for QA engineers who would support various functional teams building customer products on mobile. Web QA engineers, doing similar work but only on web platform and Software Engineer in Test, working on low-level automation in backend teams. After searching for people we jumped on defining a strategy on the test architectural level. As there was no any architecture, it was easy to start and build an idea. What that exactly means? First, we started building internal tools to support test data generation and automating it and then included this in every new feature development. This helped a lot to simplify testers work and to save bunch of time during testing. Next, we decided how to build automation infrastructure and and in which part to focus first. The direction was to start with low level and build the API automation checking across. The same time started with mobile UI automation. According to the skillset we have chosen the open-source frameworks, but some of them we build ourselves. Apart from the operational work, we focused a lot on test awareness across the development teams, meaning, working closely with developers and teach each other about testing and improving testability of the platform. In our case it was more challenging as we have a lot of external integrations which are not always easy to test, so this kind of an approach made even more sense. I could probably write more in a few medium posts :slight_smile:


I’m wondering why some replies are talking about a ‘QA Team’ rather than a ‘Test Team’.

Hi Steven,

Do you believe your statement has in any way benefitted the participants of this conversation? When you make sarcastic and ‘smart’ comments like yours it will discourage people from participating in these discussions and will have an overall detrimental effect on the community.

Discussing semantics and terminology is definitely important, but perhaps a snide comment on a post about testing teams isn’t the best approach.



It’s a perfectly valid query and your response is likely to discourage others from making such valid queries. I have to ask, does your comment in any benefit the participants of this conversation?

The OP has asked how to start a Test Team. They have not asked how to start a QA Team.

1 Like

It’s a perfectly valid query

What query? Your post was a statement that you were wondering something. You didn’t ask a question.

The OP has asked how to start a Test Team. They have not asked how to start a QA Team.

OP literally said “Has anyone started a QA team in a company?”.

I apologise if I misinterpreted the tone or intent of your message. I was just trying to promote constructive conversation because your post seems somewhat superior and belittling. Too many people nowadays are too busy correcting people instead of actually answering questions or offering advice.

I said I am wondering why some replies are talking about a ‘QA Team’ rather than a ‘Test Team’. So…why? This suggests they do not know the difference between the two.

The title of the post is…

“How to start a test team in a company?”

In regards to starting a test team, I’ve been involved with starting two test teams from scratch and the best advice I can give is that personality is more important than experience. Especially early on. You need to be able to sit in a room and just talk testing, ideas, philosophies, strategy etc. For hours or even days sometimes. This doesn’t work if you’re not interested in what they’ve got to say, or vice versa.

If you get on with your team, you will learn from one another. I don’t mean agreeing with each other on everything, that would be dull, but it’s vital to be able to discuss or even argue a point without it becoming personal. This way you’ll be able to trust them to represent the team and champion testing whenever you’re not in the room.


Hi there Jon and Steven,

While I think we can all agree there’s a distinction between Test and QA and that there’s value in the discussion, I don’t think it’s here.

I offer you a different place: Quality Assurance - stop using this term!
At this point it doesn’t matter who’s right or wrong or who misinterpreted who, the discussion has been derailed. :slight_smile:

I for one would love to hear your thoughts on how to start a team that is focussed on providing information about quality and helps to improve said quality.
Help me get this thread back on track? :wink:


You beat me to the punch! Cheers man!

1 Like

I would be keen to read those Medium posts if you decided to write them Mika! I’m especially keen to hear about your Test Architecture journey. Thx!

1 Like

I have some suggestions below and in no particular order. Hope this helps.

  1. I generally start with understanding the team members by doing a one-on-one. I will check what they know, their fears, inhibitions, and what they need to learn.
  2. I then get something created like a team profile - an excel sheet with columns for skills, testing or non-testing, years in the industry, contact numbers so forth.
  3. Then dependent on the project needs in terms of skills needed, problems and so forth I will align tester capabilities with project expectations. There will be gaps which will need filling over time.
  4. An Action plan will need to be formed focused on people, capabilities, training needs, tasks and so forth.
  5. A repository of some kind hosting test assets - templates for design, execution, reporting, good practices to be followed, presentations and forth. This will need the entire team to access/contribute to these.
  6. Goals for the team will need to be formed with team involvement to improve ways of working, learn new technologies, knowledge sharing and so forth.
  7. A discussion with other team players (Project Managers, Dev Leaders etc.) can be scheduled to understand their expectations of testers and problem areas from their perspective.
  8. Over a period of time, some leaders will emerge from the test team apart from the assigned ones. Watch out for them, encourage, motivate, push them to go higher.
  9. Ensure ongoing discussions with the team both via formal and informal means.
  10. Mentor / build confidence. build a team which has both breadth and depth. Takes time but doable.

If you need a deeper perspective please write to me. I am on Linkedin as well.

All the best!


Actually, I did that question! :slight_smile:
And I’m currently on my way to create a QA Team from scratch. I started as myself and only me on the department and, after 6 months, we are 3 persons on the Department and we are searching for new members.

1 Like

Aha excellent! How did you do it? I love hearing follow up stories on questions like this :smile:


Well, the company is 80% dedicated to mobile app development, so I work closely with the Android and iOS department. Firstly, I created an CD and CI structure (almost nobody used Jenkins before) so I started working with the devs to understand how to compile an application for Android and iOS and set the CD model using Jenkins.

Then I worked to be able to launch the android / iOS emulator and perform a simply monkey runner test and sonar to check the quality of the development, and then we start working on a Core project with Appium to start with the automation testing.

Also, we created a TestPlan for several projects (some selected project who will start working with the QA department) on TestRail and define the workflow to work with the QA department: how to report an issue, how to create a test plan, how to execute a test plan, how to export the result, how we work with a Release Candidate…

Right now we are collaborating on several project and starting to create automated test on two of them (we are only 3 people: two of them technical, one not technical; functional tester).

Also I did a meetup about QA on the company ( and we are trying to learn as much as possible and get better working closed with the dev team.

Any other advice to continue? Anything you think we could do better? I’m open for suggestions :slight_smile:

1 Like

How to start a test team?
Don’t do it.

What you want to do is to start a community of practice of people passionate about quality that includes all roles, from testers to developers, analysts, ux people, sysadmins, product owners etc.

Test teams are silos, don’t create another one

1 Like

Hi there,

I’ve been stalking on here for a while, but, this is my first post on here. So, hello! I thought I’d bump this thread rather than start a new one.

About 8 months ago I took on the challenge of starting up a dedicated testing team in agency (mostly focussed on mobile apps). The focus has been on manual, blackbox testing with a view to get automation in place in the (hopefully) not too distant future. There’s now two of us in the team and I’m finally getting the chance to come back to looking into some of the basics for the team based on my experience and learnings since starting the team.

One of the main issues I’m facing is that testing isn’t truly considered as part of project teams. We’re left out of conversations, meetings and only brought in further down the line so we’re on the back foot from the beginning (with limited time to then actually test the product(s). I’ve been trying to get buy-in from management for this and have succeeded in getting us involved slightly earlier in the project lifecycle, but, it’s still after the design phase and after user stories and acceptance criteria have been gathered. Ideally I want us to be involved from the beginning, but, appreciate that this may not be possible due to business constraints. So, I guess my question is in two parts.

  1. Can anyone recommend ideas on how to get management buy-in so testing is involved from the beginning of a project?
  2. If I can’t get this, are there any recommendations on how to handle this and prevent (or even just handle) being brought in late with limited knowledge and time (I’ve been looking into context-driven testing which seems good, even if it only helps me feel about the situation!).



When I was involved with a test team which only tested after everything was done, I spent a portion of my time when I was ear-marked for “test design” in reading and remarking on all of the other project documentation I could get my hands on. My pretext was, “If I am going to test this, I need access to these documents.” From there, based on my feedback, it was a very small step to get to, “Wouldn’t it just save everyone’s time if I could ask these questions before the code was checked in?” And later it grew to the whole team being involved from the inception stage of the projects. (As a small aside, for THAT team, having everyone involved with feasibility and specification was somewhat of an overkill, but vastly better than not being involved)

Based on this, I have this advice:

  1. Be assertive in requesting what you need to make the team better
  2. Ask questions. Be visibly curious.