Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How a Professional QA Lead Sets Goals for Test Departments

DZone 's Guide to

How a Professional QA Lead Sets Goals for Test Departments

Big or small, short or long, every project needs a testing team, and every testing team needs a competent, goal-driven team lead.

· DevOps Zone ·
Free Resource

One of the initial challenges faced by a QA lead or manager in any department — from product planning to development and testing — revolves around figuring out the right composition of the team. The composition would depend on multiple factors like overall budget, tentative timelines, the planned date to go live, approximate experience required in potential team members, and domain competency to ramp up the project. If you have had to lead a team before, then I am sure you can relate to these challenges. However, once you have the "ideal team composition," the bigger challenge is setting the right goals for your test department.

When I was first given the charge of leading the "testing activities" for a crucial project within my organization, I went through multiple ups and downs. The brighter side was the learning at the end of each day and those lessons have been helpful for future projects, not only within our group/department, but also within the organization. I am going to share with you some pointers I used while setting the goals for the test department.

Internal and External Lessons

Unless and until the project executed by you is very unique (either in terms of functionalities, scale, web design trendsprogramming language being used, etc.), there is a high possibility that you would be able to find valuable lessons within the organization or outside the organization. You could look for projects of a similar scale, domain, and technology to inculcate the lessons from the test lead of that project.

In cases where you are unable to get similar projects from within the organization, look for similar references from outside the organization (testing-centric journals, the Internet, speaking to domain experts (at an abstract level) from other companies, etc.). The whole intent is to avoid or reduce the effort involved in reinventing the continuous integration wheel so that that time can be utilized for planning and execution of other activities related to testing. Plus, you need to be aware of the latest software testing trends in the industry, such as Shift-Left Testing.

Defining Short/Long-Term Goals

Every activity that is planned during the course of any project will (or should) have a tangible or measurable outcome associated with it. While planning the activities, the strategy that my team and I followed is attaching goals with each activity. There could be short-term goals and long-term goals. The division of goals can be short-term goals, long-term goals, team goals, and goals at the Business Unit (BU) level.

For example, if your team is building a web product, you may want to perform thorough cross-browser testing to evaluate how well your web app works when accessed through different browsers and operating systems. In that case, the short-term goal — as far as cross-browser testing is concerned — would be to perform functional and non-functional testing on the most popular/widely-used browsers, including Google Chrome, Mozilla Firefox, Safari, Opera, IE, Edge, and Yandex.

You can relate this with progressive enhancement for cross-browser compatibility, where the basic functionality is delivered on the latest and most widely-used browsers and improvisations or expansions to legacy browser versions come at a later stage. Once the necessary functionalities are verified, cross-browser testing should be performed on a combination of different browsers, operating systems, and devices. This should be a long-term goal at the project level. 

While setting goals for the test department, it should be necessary to keep the big picture in mind and align these features with goals at your organization level as well. When setting goals for your test department, it is important to set goals that are not highly audacious and are practically achievable. Keep your higher management looped in as well; that way, the goals you set for your test department/team can align the goals as per the organization’s plans. In a nutshell, the defining goals for your test department should be set on the following lines:

  1. What are the goals that are internal to the team?
  2. What are the goals that align with the goals at the department level?
  3. What are the goals that align with the goals at the organization level?

Depending on the timelines of the project, you should have goals divided into a short-term (quarterly), mid-term (half-yearly), and long-term (yearly) basis. It is important that you associate the output/deliverable associated with every goal.

Team Size and Domain Competency

You don’t need the same count of testers as you have for developers. Having the right team composition is important for the successful execution of any project. This is applicable while setting up goals for the testing team as well. The team composition is based on factors like project timelines, budget, competency requirements, and many other variables.

Depending on the complexity and nature of the project, you should have the right mix of team members who have the right experience and expertise. While setting up the team, you can approach members who have proven project experience (within the team/the organization), and if you are unable to fill the positions, you should hire testers who can be a good fit for the project (and the organization). Team size definitely has a huge impact on the overall goals set by your team, so make sure that you have the right team size. For projects of shorter duration, many companies follow a "lean-team policy" where expert testers are a part of the team so that deadlines are met and less effort is spent on ramp-up and project coordination activities.

Based on the type of the project, you should shortlist the right tools for automation so that testing can be more foolproof. Having a couple of people who have hands-on experience with the shortlisted automation framework is important since they can drive and motivate the junior members in the team.

In a nutshell, while building the test team, you should ensure that the team is neither too big nor too small. Have people with the right experience, expertise, and attitude on the team can allow the team composition to be more balanced since the project deliverable depends a lot on these factors.

Risk and Deadline Analysis

Irrespective of the size of the project, every task planned during the project execution will have a certain level of risks and assumptions associated with it. As a test lead, you should do a thorough SWOT (Strengths, Weaknesses, Analysis, and Threats) analysis and come up with a risk mitigation plan. For example, if you are working on a hardware product, you should add risks like a delayed shipment of test samples, delayed software deliverables from the development team, and other risks into the risk mitigation plan.

Every risk is associated with an outcome and you should always have a Plan B ready in case there is a missed deadline. As a test lead (or someone who is leading the test team), you should motivate the development and test teams to create a culture of collaboration and instill the importance of detailed testing in the minds of developers. This requires a huge shift in the development mindset and is only possible by having workshops, meetings, etc. with the development and test teams.

Adapt According to Your Environment

The approach that you follow for a startup (early stage or growth stage) will be quite different from the approach you follow for a multinational company. It also depends on the team size and scale of the organization. Normally in a startup, there is a flat hierarchy, so the number of approvals from different executives will be few in number. The advantage of of such an approach is that you can focus on core testing activities, rather than spending time on coordination-related tasks.

The situation can be completely different for a big enterprise/multinational company. In that case, you may need buy-in from multiple stakeholders, which can be time-consuming and in the worst scenarios, discussions can result in a deadlock. It is crucial to consider these factors when determining your bandwidth for the release.

You need to be fully aware of yours and your team’s bandwidth based on the work culture for setting up goals for a test department. As a test lead, you should be adaptive to the overall culture in the organization and parameters like team size, team expertise, project deadlines, risks, etc. You cannot have a one size fits all approach as you set up goals for your test team or develop a test strategy.

Wearing Multiple Hats

Many organizations (irrespective of their size) are shifting to an Agile methodology where people and interactions are given more importance than processes. The key advantage of the Agile approach over the traditional Waterfall model is the improved level of communication between the development and test teams. These teams no longer work in siloes which reduces the turnaround time of finding bugs through testing.

If your organization is using an Agile approach for project execution, you might need to wear multiple hats where you may also need to play the supporting role to the Scrum Master. You should identify a piece of work that is done well and has greater value at an organization level. You should push the test team and development team to stabilize the features and once done, you can share the results with the key stakeholders (including test leads from other business units) within the organization. This task would result in a cross-pollination of skills and knowledge.

Though there are plenty of tools to record pass/fail rates, code coverage metrics, and more, you should not shy away from using the traditional excel spreadsheets to record the same. This may be helpful in some projects and your responsibility should be to share the learnings with your team members. If you are following the Agile approach, you would definitely be doing sprints/regular standup meetings. Being a test lead, you should try your level best to fit the testing tasks into the sprint cadence as you set up goals for the test department.

Competency Development

In the points that we have discussed so far, project deliverables and deadlines have been associated with each task involved in development, debugging and testing. Though you need to set goals to ensure that project timelines are met and a quality application/software product is shipped to the customer, there are many other factors that you need to consider while setting goals for your test department. One of them is the competency development of the test team.

Based on the experience domain knowledge of each team member, you should come up with a detailed plan with goals where respective team members can explore complex areas of testing, and learn some new automation tools to help in building their overall competency. Some examples of competency development could be exploring automated cross-browser testing platforms for validating success/failure on browser compatibility testingusing the Selenium Webdriver or any alternative to that, studying different testing tools (automation- and script-based), and exposure to testing communities like OWASP (Open Web Application Security Project) and security frameworks like ASVS (Application Security Verification Standard).

There might be many testers who are into black-box testing, but they would have an inclination towards automation testing. This kind of approach would be helpful for them to explore their interests, thereby making them more knowledgeable and self-confident.

I usually have a one-on-one discussion on every quarter with each individual tester who works under me. This discussion helps me to understand their interests and to realize whether they are happy with the type of testing they are responsible for.

Once a tester develops the necessary competency/skills required for the project, the tester can play more than a role, which will not only create a positive environment in the team but would also help you with having a great utility player on board as well.

What if You Only Have a Small Testing Team?

The major advantage of having a team of multiple software testers is that you can find the flexibility of getting the work done by another tester if one is unable to do so. However, things would look completely different when you have a solo tester or a couple of testers in the team. You may have to come up with a different testing strategy in order to save cost.

If your test team is small, then you should keep them motivated at all times, as the work pressure can be immense for them. Your major responsibility would be to conduct regular meetings and clear the roadblocks so that they can stay focused on the job assigned to them.

When you only have a maximum of a few testers, then these testers should themselves be advocates of testing through workshops, talks, etc. They should understand the importance of testing in the members associated with the development team so that more & more members understand the importance of quality!

As a test lead, it is your responsibility to showcase the tester’s work to the higher management through visual aids like charts, Kanban boards, Zenkit, and Blossom. Rewards can also play a major role in keeping the solo tester motivated towards the job. It is your job as a lead to get the best out of the tester by keeping him more involved in the job.

Conclusion

To set up goals for the test department, a well-balanced team is very important for the successful execution of any project. Depending on the type and complexity of the project, you should allocate the right number of test resources for manual testing and automation testing. The senior members of the team should not only showcase their technical know-how, but should also be responsible for motivating and supporting the junior members of the team.

For a web product, manual testing alone may not suffice since you have to verify the functionalities on many devices, browsers, and operating systems. Setting up an in-house verification lab that houses all these resources could be an expensive venture. My advice to you would be to opt for a scalable and reliable cross-browser testing solution on the cloud. 

Topics:
quality assuarance ,software testing ,qa and testing ,testing ,devops ,leadership ,goal setting

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}