I started my career as a tester before I became a developer. It gave me the foundation to understand the intimate relationship between testing and developing new products. Like many aspects of IT, every step of production and deployment of products has become complex. But at the same time, many people have come to view testing itself as a commodity.

Don’t misinterpret what I am saying; testing is critical. But manual testing by itself can be done by almost anyone in the world; some labor is cheap, and crowdtesting services are making it easier for companies to outsource these tasks.

You need to up your game to provide critical value to your organization, including meeting the demand for comprehensive, rapid automated and continuous testing. Today’s businesses are adopting DevOps and continuous delivery and demanding more releases with higher quality (not just finding bugs in JIRA), so it's important for testers to constantly upgrade their skills.

With that in mind, here are four steps you can take to build your career and make yourself (and the test team) more valuable to your organization. By leveraging the right resources, including developer and application performance management (APM) tools, you can play a bigger and more collaborative role in producing higher-quality output.

Step 1: Make DevTools Your Friend

Many testers actually test websites. There are many key performance indicators here to consider, but one of particular importance to mobile sites is size.

My favorite example is Pepsi. Their mobile landing page for the 2014 Super Bowl forced my iPhone to download 434 images and 20 megabytes’ worth of content, which took about fifteen seconds. As you can see below, Pepsi’s current website is still rather heavy. Opening Chrome DevTools reveals some bad metrics: 433 roundtrips, 14.5MB in size, and many HTTP 403 errors.

With the tools we have these days, there is no longer any excuse for an implementation like this to end up in deployment. Testers can level up their contributions by finding and offering solutions to situations like this, rather than simply creating bug reports.

The majority of testers are primarily executing manual tests, but many testers say they are afraid of using “tools a developer would use” to achieve top metrics. Most testers are not familiar with the terminology around JavaScript, CSS, XHR, Java, .NET, PHP, Nginx, node.js, Android, or iOS, and because they don’t speak the same language, they fear that they will not be taken seriously by developers if they present this new set of test results.

This is why testers should take advantage of the built-in browser diagnostics tools that come with Firefox, Chrome, Safari, and Internet Explorer. Click on the Network Tab and start executing your manual tests. After every click, check the information in the status bar. It will tell you how many roundtrips it took to load that page and how many bytes had to be downloaded.

If you see more than a hundred resources and 5 megabytes or more in page size, report that test as failed. If you let this build move on to the next testing phase (or into production), chances are very high that this web application will crash under load.

Next, click on Network and the Start Capturing option. From then on, all activity in your test will be recorded, and you’ll also get to see the overall number of items and size in the status bar.

Step 2: Perform Basic Software Architecture Checks

This is definitely a much bigger step than step #1, but it is not as challenging as you think. Look at the following screenshot. Even if you don’t know the internals of Java, .NET, PHP, or whatever technology is used by the application you are testing, reading and understanding these high-level architectural metrics is easy.

From the metrics captured for these functional tests, you should notice that 171 SQL calls and 33 web services is clearly questionable.

Getting to such a view is actually quite easy if you use some of the better APM tools on the market. They should automatically capture this level of detail for the application you are testing.

Step 3: Perform End-to-End Test Case Sanity Checks

When you execute a manual or even an automated test, you usually do not test a single URL. You typically execute several steps as part of that test. You should definitely perform an end-to-end sanity check on each action—not just those that seem like they have a problem—because very often the steps that lead up to a problem are the actual root cause. To give you two examples:

• The login assigned you with the wrong user roles, and therefore subsequent requests fail as “unauthorized.” Knowing what actually happened during login—even if it seemed fine at first sight—gives you the true root cause of the problem.
• Adding and removing items from the shopping cart didn’t update the cart and kept state information in the user’s session object. This results in wrong sum totals for shopping carts, but over time also causes high memory usage as these objects are not freed. Observing what happens in these seemingly correctly executed cart actions is important and enables testers to understand the root cause of failing actions later on.

If you use a tool that can capture every single interaction you make while testing an application, you will end up capturing full visits and all user actions. Then you can explore every click end to end and perform sanity checks based on a variety of metrics—number of objects allocated, number of SQL roundtrips, total shopping cart sum, etc. The screenshot below is taken from an APM product and shows a user visit and all the captured actions.

Finding a solution that captures all visitors and user actions makes your life as a tester significantly easier. From this high-level analysis, you can drill into the more technical details.

Step 4: Share, Collaborate, and Learn with Developers

Don’t keep these new insights to yourself. Instead, start sharing this data at your daily standup or sprint review meetings. If you come up with wrong conclusions in front of developers, don’t be discouraged. Use it as a starting point to find explanations together. This will help both sides learn about these problem patterns and how to spot them—and even more importantly for developers, how to prevent them.

With many diagnostics and APM tools, you can also export all the data you have captured into a single file. You can then simply attach that file to the ticket instead of attaching too many screenshots and giving textual descriptions about the test case and the problem encountered. This is no longer necessary with the evidence you just collected.

Level Up

To really level up your testing game, you need to start thinking like a developer. That way you can share a common language when you are collaborating to produce a new product or work out issues with existing applications. When dev, test, and ops work together rather than just passing problems around, you will not only increase your own value, but also improve your organizational efficiency.

Also be sure to share your successes with others. This will build your profile in the testing community and help others to improve their game, too. DevOps has made agile development possible, and continuous testing has, in turn, enabled DevOps. Testers who “level up” can turn the fear of being outsourced into opportunities to make outstanding contributions.