There are probably hundreds of things you need to do in order to get an efficient, well-organized, productive and sustainable QA team in place, and there are many support actions you need to do on a daily basis to make sure that you keep both your team and your client happy.
For this article, I’m will be assuming you’re in a leadership position and can communicate with the client directly for your project, and that you have enough experience to be able to drive and put in place everything in the list below, while coordinating with other teams within our company (HR, CM/CD, DM/DD, IT, Admin and so on). With this in mind, read on for the 10 things you need to do to kick start your QA team.
1. Determine expectations
I can’t state this enough — before the first test case is written, before the first sprint is kicked-off, even before you start interviewing people for your team, you need to find out what the client wants to accomplish. You should set up meetings with the client stakeholders (or be a part of meetings already set up by your DM/DD). Always try to have a consulting mindset and learn to read between the lines. Remember that the client came to you for solutions to problems they are aware of, but it’s your job to also identify problems they’re not aware of and to offer your technical know-how.
At the very least, you should be able to get a pretty good idea about the size of the team you would need, it’s composition (automation vs. manual, seniority, component areas, location — everyone in the same space vs. distributed in multiple locations), release frequency, sprint structure, branching strategy, roadmap for the current year, and so on. Basically, everything you need to move from planning to execution.
At this stage, you could be tempted to go too much into detail and try to figure out too much at once. Resist that temptation! There’s plenty of time to figure everything out. You just need the bare minimum right now.
2. Set up your team
Keep this in the back of your head — you will never get the headcount you want, and sometimes you won’t even get the headcount you need (at least at the start). This should be taken as a given, and the sooner you can come to terms with that, the sooner you can start making the most of what you’re able to get.
It’s very important to stay away from extremes. A team made out mostly out of seniors will work great for a while, but then tensions will start to arise. That’s a promise. There’s nothing you can do about it; it doesn’t matter what leadership style you have, people in senior positions will want to outdo each other consistently, especially if there isn’t enough room for promotion. I won’t go into too much detail here — on some occasions, it can work, but it’s risky to go senior-heavy.
On the other hand, getting a team which is junior-heavy, has its own set of challenges. Besides the fact that you’ll need to spend a lot of time with each of them on a daily basis just for their own work, you need to complete your own work, and there’s no one there to delegate it to. Also, their overall times of completing tasks will be much longer, which means you’ll need more of them, which you won’t get (this goes back to the headcount tip I asked you to keep in the back of your head).
Ideally, you want to aim for the sweet spot where you have a 1:2:1 ratio between juniors, mids, and seniors. That way, there’s room to delegate tasks, assign responsibilities and offer support, while also making good progress with a relatively small team. In reality, there’s no silver bullet here, and you should adjust your ratios based on the project needs.
3. Figure out processes
Ok, not all the processes should be figured out from the start, but some of them are essential, and I split them into two categories: project and team.
By now, you should know who the stakeholders are and what kind of relationship you should have with them. Set up recurring meetings with them often enough that the communication is fluid and there aren’t large gaps, but make sure there’s also enough space between them to actually have something to talk about. Make sure you document everything (send out a summary of the meeting to all the attendees, with talking points, action items and assignments).
Besides this, make sure you keep good email communication as well as instant messaging, where applicable. Just make sure that everything you talk about using IM gets documented in a more permanent form — email, google doc, etc.
Your team needs to work together towards common goals. You should make sure you do things correctly from the start. Have processes for everything ranging from how you write test cases and file tickets, to how you send daily status updates or who attends scheduled meetings and how often. I’ll go into more detail on this below, but remember that any process you put in place needs to be clear, easy to follow and easy to scale.
4. How much Agile do you need?
We all know and love Agile and everything it stands for. But do we really need all of it? You might only pick a few key points that are essential at the start — like Daily Meetings, User Stories with Points and Planning Poker and Scrum; then after a couple of releases, you decide to drop User Stories and Planning Poker and just go with giving Points based on previous experience. Plus, you add Sprint Retrospective on top of everything you’re doing.
The main purpose of Agile is actually to be agile. You can use as much or as little from the standard Agile methodologies and practices and create your own process which is the best fit for your project. You don’t need to do Backlog Grooming when you don’t even have a backlog; you don’t need to do Paired Programming when you’re in a time crunch, and you only have one developer anyway.
The biggest pit you can fall into is trying to apply too many standards too soon. You’ll drown yourself and your team in best practices without giving them time to actually be productive.
5. Test case structure
It’s difficult to estimate from the start what kind of test case structure you should use, especially since apps tend to scale over time. By the time you reach that point, you already have hundreds of test cases and changing them would create huge overhead. However, with good planning, you can offset some of the issues you might run into down the road.
Some tips on how to write good test cases can be found below:
- Group test cases in suites based on a common denominator — same functionality (sign inflows for instance), same feature (adding a filtering option to Search).
- Within a test suite try to further group the test cases into meaningful sections — going on the Sign Inflows example from above, you could have a section just for Sign In, a section just for Sign Up (both can have additional subsections for authenticating with Facebook or Google), a section for Forgot Password functionality and so on.
- Write simple test cases — easy to write, easy to read — figure out the simplest possible style (don’t over-engineer them, don’t go overboard with formatting/markup) so that you can use without affecting clarity and coverage and stick to it.
- Keep automation in mind — even if you don’t have automation plans from the start, write the test cases like you do. This will help down the road when automation inevitably gets taken into account. This means tests need to be detailed enough and with sufficient verifications in place so that they can be easily automated.
- Tests in the same suite don’t need to have the same verification steps over and over again — it’s fine if you only describe the steps needed to reach a certain part of the app in the first test case from the suite. The other test cases, since they’re grouped, will be executed once you’ve already reached your destination.
- Make tests follow logical flows. The first test should cover the logical start for a particular functionality or feature. The last test should cover the logical end. All the tests in between should follow suite in a logical manner. You don’t need to keep revisiting the same sections and verifications over and over in your tests (even if inside the app you would). Redundancy is not needed here — just make sure you cover all your bases once. Everything above that equals wasted time and resources.
- Maintain your test cases — this is of capital importance — always do test case maintenance and cut out everything you don’t need anymore and make sure everything else is up to date. Having a recurrent time of the release cycle set aside for this helps ensure that your speed and accuracy don’t get throttled by poor test cases.
While all this sounds right, there’s a huge difference between knowing what to do and actually doing it. Make writing and maintaining good test cases a habit as early as possible, or you will literally never get another chance to do it without creating overhead for your team.
6. Bug reports
This is the bread and butter of any QA team. The way your team is seen by the client and the other local teams is determined by the quality of your bug reports. Trust me when I say that quantity, while not negligible, is so unimportant compared to quality that it isn’t even worth mentioning. It’s Quality Assurance, not Quantity Assurance, after all.
Make sure all the bugs you file follow the same quality standards that your project does. Keep your bug reports concise but comprehensive, complex but not complicated. But more importantly, make sure they’re found on time.
Investigate to the full extent of your ability — find repro steps, attach files, screenshots, videos, crash logs, device logs, test data — make sure that the development team has everything they need to be able to reproduce the issue and fix it. That may mean doing most of the legwork. If you mind doing the legwork, though, you’re not where you’re supposed to be.
Remember that most tracking tools allow you to create other types of issues, besides bugs. Make sure you take full advantage of these and create tickets for everything. This helps you stay organized, and it helps the client team know what you’re up to.
Your job is to provide timely, actionable and accurate information –this should quickly become your mantra.
7. External dependencies
Basically, figure out what you need in order to minimize the time you spend waiting. This is mostly technical stuff, like:
- Would your project benefit from having CI/CD? If yes, do your best to get it implemented.
- Is your app client-server? Then get a proxy tool to be able to test requests and responses and monitor network traffic (Charles, Fiddler, Wireshark to some extent).
- Can you get a test/staging environment to test backend services there before they get deployed to Production?
- Is your app an iOS app? Get the full range of devices and OS’s to make sure you have good coverage. The client doesn’t want to pay for them? Then at least get a Mac and run your tests in the XCode simulator.
- Could you get more bang for your buck by running more tests at the same time? Get a workstation that can handle several VMs running in parallel, and there you go.
These are just some examples. Every project is different and comes with a unique set of challenges, but the main thing to remember here is that there are always ways to optimize your day to day tasks. Just keep your eyes and your mind open and don’t be afraid to ask for stuff. You may have a hard time getting an additional headcount, but, in general, the hardware is more readily approved.
8. Internal dependencies
You need to have a good understanding of what kind of internal structure we have within the company and how you can benefit from working closely with them. Talk to HR, Admin, your Community and Delivery Managers or Directors, even other teams for different parts of your project if that’s the case. See what kind of knowledge you can gain from those conversations which could help you lead your team in the most efficient way possible.
I’m fortunate to be a part of a growing project which has still not reached its peak and got to the point where there are several QA teams involved, each with its slightly different practices, procedures and ways of working. This means that I had the opportunity to see what works and what doesn’t several times over and see the same thing that worked wonderfully for one team fail miserably for another. Of course, there are many other things which can be commonly shared and work beautifully. What I’m saying — look outside your box and spend the time to get to know how other projects function. If you like something, try to adopt it in your team. It may work, it may not, that’s less important. What’s important is that you’ll be more experienced at the end of it, regardless of the result and you’ll be better equipped for the next challenge. Know what others in your position are working on and find how they tackle challenges!
9. Risk management (for team members)
Risk management is a tricky thing to do. Regardless of whether you’re looking at project risks, team risks or individual risks, it’s not an exact science. Some things are easier to control than others, but you have to accept as quickly as you can that you will not be able to keep all the plates spinning at the same time. At least not at the same speed.
This is particularly true and applicable to the members of your team. While for a project you can assess risk based on metrics and progress and burndown charts, and you can manage it through thorough planning and milestones, you can’t do the same for your team. This is an inherently ambiguous area in my opinion, and you need to learn as you go. So hope that everything will go smoothly, but prepare for things to get worse without a moment’s notice.
The best advice I can give here is to get to learn your team members. Notice I said learn not know because learning is more powerful than knowing. Knowledge can grow stale, become outdated — learning is a continuously refreshable process. Spend time with them and try to figure out what makes them tick. Keep it informal, keep it light, give them a pat on the back when they deserve it and focus on building a relationship at first. The good thing about starting a new project is that things aren’t hectic yet. So focusing on performance is not essential yet. Take that opportunity, because it will be the best one you’ll get, to nurture the bonds that will keep your team together and that you can build upon once you get the point where you need to start growing.
10. Growth and scalability
If you managed to complete most of the items up to this point, that means you’re floating. Your goal, though, should be sailing and moving forward. And in order to do that, you need, through your effort, to grow the client’s product, which, in turn, will grow your team naturally. This is the consulting mindset that I talked about earlier — identify how you can help your client and prove your and your team’s worth with every occasion you get. That will build trust, and the client will find it natural to push more and more work and responsibility to your team. Once you reach that point, the sky’s the limit. Make sure you bring on board team members that fit in both in terms of technical know-how and personality. Always make sure the people you bring don’t create friction within your existing team, and everything should go smoothly.
To summarize, figure out what your client wants, determine what they need, even if they’re not aware of it, plan ahead and always keep a clear head and a consulting mindset.
And when things seem not to come together, remember there’s a community here for you. The most important advice I can give is don’t be afraid to ask for help. There’s only strength in having a support system in place and a wealth of knowledge to be shared by those who have done this before.
Latest posts by Flaviu
- No One’s Going to Speak Your Mind for You - May 30, 2019
- 10 Things You Need to Do to Kick Start Your QA Team - May 1, 2018
- A/B Testing for Mobile Apps at Scale - June 30, 2017