When it comes to being a successful software tester, there is one important trait that makes all the difference: understanding what needs to be done now and what can be delayed. The ability to prioritize becomes an important attribute for success at a people level, at a process level, at an activity level, and at a communication level.
Ask anyone in the software testing industry what it takes to be a successful tester and they’ll likely say strong analytical skills, robust debugging skills, and solid written and oral communication. Having been in the testing business myself for more than fifteen years, in my opinion, there is one important trait that makes all the difference, whether you are a testing executive or an entry-level engineer: understanding what needs to be done now and what can be delayed.
We could define this as the principle of doing first things first, or, as a process, of evaluating all tasks and ranking them in their order of importance or urgency—in other words, setting, keeping, and, when it makes sense, adjusting priorities.
I recently wrote about techniques to set priority, including working under pressure, coping mechanisms, and differentiating between importance and urgency. If we specifically consider these techniques for software testers, the ability to prioritize becomes an important attribute for success at a people level, at a process level, at an activity level, and at a communication level. Let’s look at each of these in greater detail.
Prioritization at a People Level
A tester probably has the highest number of interaction points on a product team—more than even a designer, analyst, or program manager. The tester interacts not just within the core team of the developer, business team, build engineer, and deployment engineer, but also with testers from other teams, executives and stakeholders, and end-users, making him the most connected person within a team.
Although communication channels have become very sophisticated, given the limited time, a tester has to prioritize his contacts in each project to ensure he has the right rapport with the right set of people. This prioritization may sound self-centered, but it is essential to the best interests of the quality of the product under test.
For example, at a client level, I’ve often had to focus more on the current set of clients we’re working with, whether it be meeting them for lunch, inviting them to our office, etc. This does not mean I would not be excited to meet people I don’t work with directly at this time, but if I were to prioritize, the current set is top on the list.
Similarly, I find my testers spending the most time building rapport with the current team they are working with, and especially with the developers on the team. Again, while the entire team is important for them to establish a relationship with, the marriage between them and their current set of developers is what they prioritize the most, which I strongly believe is the right thing.
To give another example, even in people allocation to projects, prioritization is important. We have a few projects where the testing needs are on and off. However, when testing is needed for those projects, we would ideally need the same resources to work on them for the sake of product, domain, and process knowledge. For such situations we have a pool of people who can be assigned to any project, but when the projects they are subject matter experts on need them, they will be allocated based on priority.
Prioritization at a Process Level
Test processes is one area where testers need to exercise prioritization very strongly. It’s often difficult for a tester to change from a set norm—for example, if the team has been working on a specific process all along, such as creating a test strategy, followed by test plans, then test cases and scripts. A process of doing things has to be critically looked at in every release and reviewed to see if it aligns with the current developmental and market needs.
In most cases today, a test strategy’s value is under question. Even if the value is mandated (sometimes as part of the quality audit), relevant sections such as entry and exit criteria, risks, and mitigation strategies should be made a priority, rather than other sections that may be very difficult to define up front. To give an example from my experience, we have been seeing the need for more innovative test processes and solutions, not because of a lack of coverage in the traditional testing techniques we have been adopting, but more because of increasing end-user expectations in terms of product quality. Innovation in what test processes we use is becoming inevitable.
While this is a no-brainer, the challenge is balancing all these newer processes with the existing ones within the limited time on hand. Specifically, we wanted to use crowdsourced testing on a project. Putting together a crowdsourced testing process is not a very difficult task in itself. You may ask, “Can’t the crowd testers just work in parallel with existing testers? What is the need for any prioritization here?” The challenge is around who will look into the issues reported by the crowd testers. Do developers have time to attend to them? Has anyone vetted them to ensure they are not dupes of issues that in-house testers have already reported? With no answers to those questions, it seemed that the crowdsourced effort would bring in more chaos than value if used on an ongoing basis.
That said, we could not rule out the need for this supplemental testing process. Instead, we prioritized our existing traditional testing processes over crowdsourced testing. We then worked with the client to take up a quarterly huge bug hunt event involving both internal and external testers over a weekend to catch up on crowd feedback. This selective execution strategy centered on prioritization brought in better results, with an ongoing focus on core test processes.
Looking at it from another angle, on all our testing assignments, we use a test optimization matrix to prioritize our focus on devices, platforms, open source software, and browsers to determine which will give the most value in surfacing defects. Any time we need extra coverage we believe cannot be accomplished internally, we bring in the crowd to help expand the test scope. In our prioritization strategy here, we use two core principles in determining the test optimization matrix:
- Functional issues are more dependent on the OS rather than on the device size or screen resolution
- User interface issues are more specific to a device size or screen resolution rather than to the OS, and they have the following trends:
- Different devices with the same screen size and OS version would give identical results
- Devices with different screen sizes but identical OS version would give different results
Prioritization at an Activity Level
A tester’s plate of activities is overflowing. From the core test execution effort to defect management, end-user analysis, competitive analysis, empowering others on the team to own quality, and taking on out-of-the-box activities such as bug hunts, today’s tester probably wishes for more hands and time to accomplish tasks. The best we can do is prioritization, whether this means selecting an optimized test suite to use, creating a prioritized test matrix (including support on devices), or setting the right priority on bugs so that triage teams can make the right fix decisions.
As testers juggle priorities on an hourly basis, some do it consciously and some do it without even realizing. However, making an effort to be conscious of prioritization will enable you to make better decisions, so it’s a good idea to be aware of considerations such as the time and cost constraints of the product team, end-user expectations, and competitive positioning. When testers are able to prioritize their activities in terms of test coverage and defect management along these variables, over time, they’ll be able to bring in maximum value not limited by these constraints. They’re also likely to find a new appreciation for the business aspects of the product, empowering them to make educated decisions rather than random choices leading to the release.
In my team’s process of prioritizing our test efforts, functional testing is certainly weighed more than nonfunctional efforts, and we bundle test automation frameworks to take on functional and other test areas, such as accessibility and security, to achieve a prioritized yet enhanced test coverage. For example, in all our projects we have ensured test automation framework integration with test case and defect management systems. This helps maximize a tester’s time for core testing activities as opposed to reported activities that can be safely automated. We are even exploring ways in which the tester can use technologies like augmented reality, with gestures like a thumbs up or down to record test results.
Prioritization at a Communication Level
Here, the prioritization the tester achieves has some overlap with the prioritization at the people level and at the activity level. However, given the importance of communication to a test effort’s success, I am considering this a category of its own.
Because a tester has the most touch points in a team, he obviously communicates a lot, through speech and writing. He may be imparting a training session to a junior tester, collaborating with a developer, or in a discussion on end-user scenarios with the business team, or periodically he may even be presenting the quality health index to executives and stakeholders to help them make release decisions. Consequently, it is important for the tester to prioritize what, when, how much, and how he communicates, depending on whom he is interacting with. For instance, while it is good to have detailed test reports to support a test effort, an executive is not going to have the time to read through those reports fully. The tester should be able to prioritize the data to give only the relevant pieces of actionable data they need.
Because testers naturally spend so much of their time communicating, it’s an important area to apply the principles of prioritization so that we can balance our activities, showcase our efforts, and ensure the right product calls are made on time. Using effective communication tools and having a focused agenda—both in meetings and offline conversations—helps ensure prioritized communication.
Testers have a lot of responsibilities, and usually, we can’t do everything to the best of our abilities. The smart ones prioritize in order to optimize the varied facets at play. Testers who practice conscious prioritization should see a positive impact in their career progression, the quality of the product, collaboration with the team, the product’s market acceptance, and, most importantly, their own work-life balance.
