6 Ways Testers Can Add Value (Other Than Functional Testing)

Even with the increased adoption of automation, functional testing holds its importance. Most software applications need to be tested by humans in order to validate and investigate each feature and their interactions.

Unfortunately, many testers spend their time doing functional testing and do not come out of this cocoon. The reasons could be lack of skills, not knowing how to code, fear of the unknown, or limited knowledge of the testing landscape.

Paraphrasing Cem Kaner, software testing is all about discovering quality-related information to assist stakeholders in making informed decisions. There are multiple ways to discover information in addition to functional testing. Here are six actions that have helped me add more value in my projects.

1. Review every message

Testers usually go through the requirements documents, have a discussion with the stakeholders, and then design their tests to be executed on the product. But we all know that there are multiple scenarios that don’t get covered by the test cases and still crop up during usage. Most of them get covered by the development team, but some of them are a surprise to everyone.

The development team can help by making a list of all the messages coded into the product, including the error, info, and warning messages. This also acts as a good check of the test coverage in terms of messages displayed by the system. If the test team has never seen a message that is going to be displayed to the user, the team can then go back and understand which scenarios would display the message.

Once when I received the list of strings, I immediately noticed that an entire section of strings were totally new to the testing team. On reviewing, we discovered that it was from legacy code, and even though we no longer supported that feature, we had some part of the code committed. It should have been removed, as there was no impact on the product.

Based on the application and how it is built, it might be easy or difficult to get the list ready. But if you think of this exercise as a way to help the testing team test better, the stakeholders should agree on finding a way to get the list of messages ready. Going forward, try this approach and get a reality check on your product understanding and test coverage.

2. Perform a UX review

Many product teams build fast and then think of stabilizing the code after reaching a set of customers or a certain growth metric. In the initial phase, releasing quickly generally takes precedence over releasing right. As multiple developers get involved, there might be a high chance of inconsistency creeping in.

In the process of stabilizing the product, focus on getting rid of any UX inconsistency. Perform a UX review of the whole application. Start with icons, text, actions, features, and key flows and bring in personas and the thought process to perform a full UX review. Also think of the touchpoints for the users. How are you handling them? Are there any garden paths in your application? There are exercises to help test your UI skill set at https://cantunsee.space/.

When we performed the UX review within our company for a highly used product, we found patterns of inconsistency and could easily relate them to the different decisions we took as a team—releasing a feature in a hurry, feature development outsourced to a different team, features with outdated plugins, and so on.

3. Do a competitor analysis

It’s a shame that a lot of testers are stuck in silos and have no clue about other companies’ products. Read about your competition through fact sheets, web seminars, demos, media news, and blog posts, and then list the features and analyze the strengths and weaknesses against your own product.

Check with your product teams about if you can get access to other companies’ offerings, and ask how you can assist in competitor analysis. When performing a competitor analysis, focus on multiple quality criteria like usability, performance, security, and accessibility in addition to functionality. A simple dashboard highlighting who scores better across the features and criteria could be handy.

4. Look for opportunities for tooling

Tools are a boon for those who know how to use them effectively. They can save a lot of money and time, and complement testing to a large extent. As a tester, you should have a wide knowledge of the systems involved and the processes being followed.

Apart from automating functional checks and using tools to create test data quickly, there are other ways you can use tools, like detecting patterns across logs, replicating production data, mocking functions, taking backup of certain user actions, and triggering actions based on rules. It is also not necessary to buy proprietary tools to achieve most end goals. It could be a simple hundred-line program that takes a screenshot of the application based on a trigger in the log.

Sometimes it might not be obvious to everyone how useful certain tools are to do a particular activity until you demonstrate the value, so look out for such opportunities.

5. Think of risks that could cause ‘nightmare headlines’

As described in the book Explore It! Reduce Risk and Increase Confidence with Exploratory Testing, by Elisabeth Hendrickson, one way to prevent disaster is to think of possible bad news headlines related to your product or project and test for those risks. Testers are good at thinking of probable disaster scenarios, and this skill can help the development team avoid such bugs while writing code, saving time and effort up front.

This would be a fun game to play with multiple stakeholders, and it gives everyone confidence that risks are taken care of. When we conducted this game with one of our teams, some headlines thought up by tech support and management team gave a different perspective to the testing team—we would have never thought of those tests without this nudge.

6. Spend time with the customer support team

Due to continuous usage of their product, the testing team might be biased toward certain behaviors. But what appears to be an expected feature to testers might actually be a burden for users. You can listen to customer support calls to learn about customers’ pains and confusion using your application.

For one of our products, when we complained about a feature and its usability, the bug was rejected. When multiple customers started complaining about similar usability issues, they were fixed with high priority. This experience gave us a lot of credibility in the organization, and we were later invited to multiple discussions about usability decisions.

The customer’s voice is the real data you should be paying attention to, and you can use this data to advocate for making a difference in your product.

These six actions can be easily combined with functional testing, and they add an immense amount of value. Try out these tasks in your testing work and let us know your experiences.