One of the initial challenges faced by a QA lead or a manager in any department from product planning to development & testing revolves around figuring the right composition of the team. The composition would depend on multiple factors like overall budget, tentative timelines, planned date to go live, approximate experience required in potential team members and domain competency to ramp up the project. If you have 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 & downs. The brighter side was the learning at the end of each day and those learning 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 which I used while setting the goals for the test department.
Unless and until the project executed by you is very unique (either in terms of functionalities, scale, web design trends, programming language being used, etc.); there is a high possibility that you would be able to find valuable learnings within the organization or outside the organization. You could look for projects of a similar scale, domain, & technology to inculcate the learnings 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, 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 & execution of other activities related to testing. Plus, you need to be vary of the latest software testing trends upcoming in the industry, one such software testing methodology which is being popular right now is the Shift Left Testing.
Every activity that is planned during the course of any project will (or should) have a tangible/measurable outcome associated with it. While planning the activities, the strategy that my team & I followed is attaching ‘goals’ with each activity. There could be short-term goals and long-term goals. The division of goals can be something like 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 and you wish to perform a thorough cross browser testing to evaluate how well you web-app works when accessed through different browsers and operating systems. In that case, the short team goal (as far as cross browser testing) is concerned would be to perform functional & non-functional testing on most popular/widely used browsers. LambdaTest offers you latest browser versions of Google Chrome, Mozilla Firefox, Safari, Opera, IE, Edge and Yandex running on various operating systems to perform manual and automated cross browser testing.
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 combination of different browsers, operating systems & devices. This should be a ‘long-term goal’ at the project level. LambdaTest can help you with thorough validation of cross browser testing by providing an ecosystem consisting 2000+ browsers(modern as well as legacy browsers) supported by various operating systems. Here is the complete list of browsers of LambdaTest.
While setting goals for 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 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 organization’s plans. In a nutshell, the defining goals for your test department should be set on the following lines:
- What are goals that are internal to the team?
- What are the goals that align with the goals at the department level?
- 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 short-term (quarterly), mid-term (half yearly), and long-term (yearly) basis. It is important that you associate ‘output/deliverable’ associated with every goal.
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 & 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 in case you are unable to fill the positions, you should hire testers who can be good fit for the project (and the organization). Team size definitely has a huge impact on the overall goals set by your team; hence 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 & 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 couple of people who have hands-on experience with the ‘shortlisted automation framework’ is important since they can drive & 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 right experience, expertise, and attitude in the team so that the team composition is balanced since the project deliverables depends a lot on these factors.
Irrespective of the size of the project, every task planned during the project execution will have certain level of risks & 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 delayed shipment of test samples, delayed software deliverables from development team, etc. into the risk mitigation plan.
Every risk is associated with an outcome and you should always have a Plan ‘B’ ready (also called as the Backup plan) in case there is a slippage in the deadlines. As a test lead (or someone who is leading the test team), you should motivate the development & test teams to develop 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 & test teams.
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 flat hierarchy, hence the number of approvals from different executives would be few in number. The advantage with such an approach is that you can focus on core testing activities, rather than spending time on coordination related tasks.
Talking about startup, let me inform you that LambdaTest offers a unique pricing plan for all startups offering a heavy discounted pricing.
Back to basics, the situation can be completely different for a big enterprise/multinational company. Hence, you may need buy-in from multiple stakeholders which can be time-consuming and in 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’ as you set up goals for your test team or develop a test strategy.
Many organizations (irrespective of their size) are shifting to Agile methodology where people & 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 & test team. These teams no longer work in a silo which reduces the turn-around time of finding bugs through testing.
If your organization is using 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 & development team to stabilize the features and once done, you can share the learnings with the key stakeholders (including test leads from other business units) within the organization. This task would help you to build more inter-team & intra-team synergies and would result in cross-pollination of skills (and learnings).
Though there are plenty of tools to record pass/fail rates, code coverage metrics, etc., 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.
In the points that we have discussed so far, ‘project deliverables & 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 ‘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, learn some new automation tools such as LambdaTest, something that can 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 testing, using the selenium webdriver or any alternative to that, study of different testing tools (automation and script based), and exposure to testing communities like OWASP (Open Web Application Security Project) & 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 & 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 necessary competency/skills required for the project, the tester can play more than role, which would not only create a positive environment in the team but would also help you with having a great utility player on board as well.
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 or a couple tester in the team. You may have to come up with a different testing strategy in order to save cost or there is really no requirement to build a test team (considering the scope & size of the project).
If your test team has only a solo or a couple software testers then you should keep them motivated at all the times. As the work pressure could be immense for them. Your major responsibility would be to conduct regular meetings & clearing the roadblocks so that they can stay focused on the job assigned to them.
When you only have a maximum upto couple testers, then these tester should themselves be an advocate of testing through workshops, talks, etc. They should understand 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, Blossom, etc. 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.
To set up goals for test department, a well-balanced team is very important for the successful execution of any project. Depending on the type & 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 & 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 house all these resources could be an expensive bet. My advice to you would be to opt for a scalable & reliable cross browser testing solution on the cloud. You can use LambdaTest for manual testing and automation testing for validating cross browser compatibility. LambdaTest would help you with more than 2000+ browsers to test from. Your test team members who are well-versed with automation frameworks like Selenium can utilize the capabilities of LambdaTest cloud to build scalable test solutions.