I work with a tester whose background is in functional and test automation. They find themselves with a one-month target of doing something useful with performance testing of a webUI + APIs + database + data integrator -kind of a system, and are in need of advice: what they should read, learn and do to show they should continue after the one month trial?
What they have already done:
learned to use jmeter (one month before this opportunity opened)
read random articles
get access to test environment and pointers to two features that feel too slow with current amount of data
They report they would like a good foundational course that is just for the need they have, that would allow them to hit the ground running.
I have given advice and I coach them, to know they try to leave no online trace on socials which hinders the excellent opportunities to learning that a community like this can give. What advice would you impart?
Just from my memory, I don’t have a big performance testing experience but I’ve come across performance testing questions as part of my normal job several times. The courses I did back in the days are outdated by now and I don’t remember which one stood out as good.
Some random thoughts:
do learn the cool thing devtools can offer (even just the Network tab gives you valuable info, but there is profiling, etc.)
learn about perceived performance and the psychology of performance. My PO once literally asked me to find things that “feel slow” rather than were actually slow. I often refer to this article - I actually learnt the numbers by hard so I have them at hand in everyday testing. This has proven really useful.
do play with some load testing tool (JMeter, Gatling, K6 - whatever works for you) so you know what it can do.
learn the available monitoring tool. They can show you how long things take at the backend.
I suggest they continue working with the test environment and the slow features. What can they figure out about it? How far can they narrow down where the bottleneck is?
One of my best bug finds was by putting a system under load and simultaneously monitoring the error log - with very primitive tooling.
Things I would prioritize lower:
distinguishing all terms (“stress testing”, “spike testing”)
specific tools - for the general reasons you shouldn’t focus too much on tools. I answered many of my performance questions without a formal performance testing tool like JMeter or Gatling.
Setting up Performance testing consumes time & It requires precision and targeted areas in my POV. We can start small.
Performance testing shall be started from the areas of the application where it lacks performance not all of the application feature might need it. Second, if we are looking to automate web application, we have browsers dev tools to locate the latency in “timings” tab by inspecting it, how much API consumes time in downloading the request over server. If there is no log/monitoring tools are integrated. If the tools are integrated, i-e: Analytics tools - PostHog, DataDog, Grafana, K8s, they aid is analysis of performance issues. I can quote 1 example: i-e: We have a web application where performance hit all time low due to “high number of traffic on bonus round” on the platform. Thats the area where we should set up our load testing, using JMeter or any other tool.
As we know from testing principle exhaustive testing is impossible, same goes for performance testing, we just need to make sure what areas where performance testing needed the most in the application and what corrective measures can be taken.
The pair is off to a terrific start with their pursuit of JMeter and determination of slow features - this is already a very important step. How to truly maximize the one-month trial period:
Select one feature considered slow, create a basic JMeter test, and get some initial performance numbers from it. Don’t overthink it.
Take a focused course — Blazemeter Academy or QAInsights on YouTube are great and free.
Dive deeper — understand different types of load testing: stress testing, soak testing, etc., and start considering what exactly is slow (API, DB, UI?).
Present results graphically — providing crystal-clear visuals of before/after effect says much more than any amount of talking.
Dive in purposively and quietly — no need for public Twitter fame to learn from GitHub, newsletters and MoT content.
Performance testing is about posing the right questions and telling the story around the data. This tiny victory could turn into a big thing within months.
Its worth going a bit deeper into what performance risks they are looking at.
In many cases it can be single user performance risk which is a different approach and as someone else mentioned dev tools and things like lighthouse can be useful.
The data load or high volume of user testing tends to be a bit more rarer, I’ve been in banking situations where at the time it was deemed there was almost no way to simulate production usage but it is worth getting an understanding of the specific risks they are testing for.
One other element worth learning, flagging this for myself also as performance risks is not one of my own specialities is what the solutions could be to the problems they find.
Costs of the environment setups have potentially come down so much so in some cases it can just be a case of scaling environments to match the loads.
In other cases it could be code issues, if I was to specialise more in this area this is something I would like to understand better so I could adapt the testing towards these slightly different risks.
Open new instances of the same thing, in your app (ex: a new window) and observe the data on your task manager
Install
wsl 2
if you are on windows
After that install the
top
command to see what data it gives you. Use
htop
for better readability.
Read the user stories/requirements and come up with goals like
As an app user, I would like the web app to fully load within 5 seconds 95% of the time
As you start finding issues, Be aware of people issues Ex: The ui team could point fingers at the server team, and server team to someone else
For the long term, read
