7 Things Awesome Testers do That Don’t Look Like Testing

If you’re supervising testers, or if you have testers on your team or in your organisation, you probably see them doing a whole bunch of stuff that doesn’t look much like testing…

  • That conversation you see them having with the developer, product owner or scrum-master. Not testing.
  • The time they spent researching a new emulation tool. That wasn’t testing either.
  • All that effort put into building and configuring environments. Not testing. Well, maybe a little bit of testing. But more like a preamble to the main event.
  • Oh yeah – and that presentation they did for their team to the department. You guessed it. Not testing.

Obviously testers are paid to test. I mean, the clue’s in the job title – right?

So why are they doing all this other, non-testing, stuff? And is it adding any value?

Let’s take a look and see shall we?


Prior to my illustrious career in the world of I.T., I worked in a number of other roles where talking was definitely not seen as a value adding activity. In a number of them in fact, it would have been seen as a value diminishing activity instead. You may be inclined to think likewise when you see your tester having one-to-one or one-to-many conversations within your team. But look a little harder.

Talking with, questioning, enquiring of and sometimes even interviewing developers, product owners, other testers and members of the team is a vital part of your testers work. Great testers will use this time to drill deep down into the work that’s being carried out establishing the what, how, when, why and whom of stories and on the results of those conversations, how they need to test.

Some testers don’t even need to touch the keyboard to find a defect. They’ll be able to do it simply by asking your developers the right questions.


Being able to have the kind of conversations that lead – if not necessarily to defects being identified or fixed before they even become a problem – to powerful insights, requires some effort up-front to build a decent working relationship. The wheels need to be greased a bit.

Awesome testers spend time developing their social skills. They understand that teams are complex systems and are wary of the intended and unintended consequences of their interactions with the system. They might even go so far as to treat it like another application under test, making small changes to their relational behaviours and observing the results.

Then they’ll go ahead and process the feedback to ensure they’re speaking to people at the right time, in the right place, with the right information to hand – to make sure they get the best results from their interactions.


Not all teams fix bugs on the basis of a conversation or a Post-It note. Sometimes your tester will need to write a defect report. They’ll need to know how to get the required information across in a clear and succinct fashion. Learning to write a decent report takes some effort.

Sometimes those reports will need to be a little longer. Your tester might need to write a strategy, or a test process or programme report. That report might get circulated both in and outside of the organisation and be seen with varying levels of interest by any number of stakeholders. Having the ability to write and communicate pertinent information in a compelling fashion is a skill. It takes some effort to acquire and develop.

Having a tester who is willing to invest the time and effort in learning how to write properly is a bonus, because they’ll not only write better, they’ll think more clearly too.


Of course, writing isn’t the only tool your tester can use to sharpen their thinking. They’ll probably have a toolbox full. If you poke around inside the toolbox, you’ll find some heuristics, mnemonics and creative prompts.

You’ll find your tester has many thinking hats and that those hats help her to approach problems from a number of different directions depending on the context in which she’s working.

Like your developers, the most important work is taking place inside of your testers head – long before they ever touch a keyboard.


Most human achievements began with a test of some description, so you can expect your tester to be enthusiastic in learning about the world around them. In a professional capacity, that’s likely to mean desires to learn about the organisation, the domain, the technologies, architecture and specifics of the software under test for starters. But there may be some other passions too.

One of the traits of great testers is a willingness to follow their nose. To pursue their quarry wherever it may lead. Sometimes the hunt will lead them some place amazing, and they’ll discover philosophies, insights and other valuables that will drive their testing skill to new heights. Other times, the hunt may take them down a hole from which they need rescuing.

Don’t ever quench their passion for the hunt though. Because when they find something good, it won’t only benefit them. It has the potential to make your team and product better too.


The best testers have learned to share their kills. To bring them home and divide them amongst the team. Above and beyond that, if they’ve developed their communication skills sufficiently they may be willing to share their learnings with the wider organisation, their local, national or international tech communities.

Turning what they’ve learned into blogposts, articles, presentations, workshops or other learning platforms, as well as applying their learning in the day job, just reinforces the value of their learning at a personal level – and helps to build up the people with whom they work.


If your tester isn’t looking for ways to improve the speed, scope and efficiency of their testing efforts on a daily basis – then you probably hired the wrong person. Increasing the breadth and depth of their testing will be a natural consequence of your tester wanting to learn more about the software, system and architecture under test – so of course they’ll want to build tools to help them do it.

The tools they build may not look like how you expect though. Your tester might leverage some existing platform or toolset, extending its capabilities or repurposing it to their needs. Or they might develop some customised data to be injected into the application for more effective testing. They may develop a script or a tool from scratch that helps extend their own testing skills, scaling them up so more testing can be carried out faster than ever before.

Their tools may not even be software related. The tools of your tester may well be more facilitative than hands on. Watch them though and encourage them to develop a toolkit that complements their skillset.

Testers should develop skills in many areas

It may not have occurred to you before that these are all skills that your testers can develop and that will serve them well in their testing efforts. Each one of them adds significant value to the project on which they work, your team, your organisation and when shared outwards – with the testing and tech community as a whole.

But not only that – they’ll benefit them personally. Each of these skills is broadly applicable not only in a work context but in life. They’ll help them to be a better person, a better friend, a better partner, a better human being. And because they’re so broadly applicable – they can take them anywhere they need them. From role to role, organisation to organisation.

They’re valuable assets. Testers should look for opportunities to acquire them, and to apply them whenever they can. I’ve listed a few starting points below. If you have some further suggestions I’d love to hear about them in the comments.

  • Talking – Karen Johnson delivered an excellent talk on The Art of Asking Questions at TestBash 2015 that exemplars questioning, interviewing and of course listening techniques
  • Relating – It’s not quite the same thing, but if you think about software testing from an anthropological or social science perspective – then you arrive at the work of Huib Schoots and John Stevenson.
  • WritingJames Bach and Jerry Weinberg have both had much to say about the practice and benefits of developing a good writing habit.
  • Thinking – John Stevenson has delivered a number of workshops and written an entire book on the psychology of software testing.
  • Learning – Check out James Bach’s book Buccaneer Scholar for more on the benefits of a constantly evolving and unbounded learning philosophy.
  • Sharing – There are various communities within which the sharing of tools, tips, techniques, approaches and thinking is rife. A great place to start is The Ministry of Testing.
  • Building – James Bach / Michael Bolton – have written a paper on automation in testing that anyone who aspires to develop and build testing tools or simply do more effective testing should read.

Systems, not Goals

One of the things folk tend to do around this time of year is think about their goals and targets for the upcoming year, and how well they did with those from the last year. I just did it myself in fact. Fortunately, they’re all in Evernote so it’s very easy to pull them up.

I had some great objectives for the last year. They were all mind-mapped out (I use XMind for this) and categorised into different areas – health, career, learning, reading etc.

Some of them I achieved. My health levels have way improved over the last couple of years, although I’ve typically not been very big on exercise.

Some of them I’ve failed at. I’d planned on submitting abstracts to lots of conferences this year, but that never happened in the end. I’d also set a target for 52 blog posts this year (presumably 1 per week, though the goal doesn’t really state this explicitly.)

If I go back to my 2014 goals, my track record for non-achievement gets even worse. Or better, depending on which way you look at it!

Pilates and push ups didn’t fare so well. Neither did journaling, moving house and ramping-up our investment in property.

So I can’t help but ask myself what the point is? Why bother to set goals when there’s a strong likelihood that a few days later I will have either forgotten or disregarded them?

Probably – not much. Fortunately though, over the last few months of 2015, I found a much better way of achieving the things I set out to do.

Systems, not Goals

Instead of having a specific target or objective, I try to implement a system for actually getting things done instead. I’ll give you a few examples of what I mean.


It’s important to me that my family and I have a relatively healthy diet. So instead of setting a goal for healthy eating and changing our diet completely – I just implement a few rules for the food we purchase, what we cook and how we approach mealtimes, and what we try not to have too much of hanging around in the kitchen. Those rules look something like the below:

  • Don’t eat anything that’s white or that can be made white – bread, potato, pasta, sugar, milk
  • Replace carbs with beans or legumes
  • Eat a high protein breakfast
  • Keep nuts in the house for snacking (if I have nuts, I’m less likely to eat unhealthy alternatives)


I hate going to the gym, so I just don’t do it. I don’t mind playing racket sports but it’s difficult to find other people to play them with at the times I want to play. So that doesn’t happen too often either.

I have a fitness tracker, which helps a bit because it means my activities are at least being tracked, and in theory what I pay attention to should improve. The problem is, it’s too easy not to pay any attention. So the system that works for me in terms of exercise is this:

  • Put on trainers, sweat pants etc so I’m ready to exercise
  • Use a running coach (an app on my phone is fine for this)

Exercise tends to be a bit of a hit and miss affair for me, but the system above is working currently. I’ve been out running more in the past few weeks than I did the entire rest of the year, so I’m doing something right.


I love to learn, so this is a pretty easy one for me. Still, I need to have some way of making sure that I’m learning the right things and that I’m doing it regularly. As such, I have a couple of systems to help me out:

  • Use Wunderlist (or a notepad, or whatever works for you) to track stuff I need to learn about
  • Set aside one day each week to learn new stuff
  • Turn off the TV and read instead

Wunderlist works great for tracking stuff that I need to do, and stuff I need to learn becomes just another list. Since I have my list and one day a week specifically set aside for learning related activities – it’s just a matter of choosing or continuing with something from the list. Whatever I have energy for at the time.

Turning off the TV is a more recent addition to my collection of systems. I’m not a big fan of the media generally and try not to listen to, read or watch the News for example (too depressing). Further curtailing my TV watching so it’s even less of a distraction seems like a natural next step.

Systems work better

I could go on and on. I have a ton of systems for achieving all of the things I want to do.

Personally, I think they work way better than goals for several reasons:

  • They’re actionable – systems like the ones I mentioned above are made up of specific activities and things that need to be done. They’re not vague, pie-in-the-sky ideas about things I’d like to do or achieve. They can be done right now!
  • They don’t specify a result – where diet is concerned for example, none of the actions I talked about were tied to weight loss, though that has been a natural consequence of eating more healthily. Along with more energy and an easier life in the kitchen.
  • I don’t have to think about them – having systems made up of specific activities and actions mean I conserve willpower. I don’t need to think about how I’m going to achieve my goals, I just implement the system and trust that it’s moving me in the right direction.

So here’s the thing. If you’re thinking about some things you’d like to achieve in the New Year… Rather than writing a list of goals, hopes or dreams – try to think about what activities you’re going to need to perform that are going to keep YOU moving in the direction of your goal. Being SMART might help. Or you can just break things down into systems like I’ve talked about above.

If your goal relates to business growth, try to make your system or activity a daily practice. Checkout our daily 90 minute plan here if you need some inspiration.

And of course, if you’re ready to really ramp things up – you can hit the Reply button for a free consultation.


Correlating Dynamic Values in JMeter

In previous posts I have covered:

If you’ll recall from that last post, the login script wasn’t working yet. The actual login request (i.e. the submission of the login credentials as a request to the server to initiate a logged-in session) was failing because we weren’t providing it with all of the information it needed.


In the Send Parameters With the Request section of the HTTP Request sampler, request login, above, we can see that there’s an AppActionToken that looks as though it’s been generated by the server, probably to uniquely identify the session. If we continue to scroll down the list of parameters, we’d see that there are a number of other tokens that are required in order to successfully login:

  • appActionToken = 1m8mf7N5vmsDvbmwR42h5gcGufAj3D
  • openid.pape.max_auth_age = ape:MA==
  • openid.ns = ape:aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvYXV0aC8yLjA=
  • openid.ns.pape = ape:aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvZXh0ZW5zaW9ucy9wYXBlLzEuMA==
  • prevRID = ape:MTFESk4zWkIwQzhSSjg5SlQ0SjA=
  • pageId = ape:Z2JmbGV4
  • openid.identity = ape:aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvYXV0aC8yLjAvaWRlbnRpZmllcl9zZWxlY3Q=
  • openid.claimed_id = ape:aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvYXV0aC8yLjAvaWRlbnRpZmllcl9zZWxlY3Q=
  • openid.mode = ape:Y2hlY2tpZF9zZXR1cA==
  • openid.assoc_handle = ape:Z2JmbGV4
  • openid.return_to =
  • ape:aHR0cHM6Ly93d3cuYW1hem9uLmNvLnVrL2dwL3lvdXJzdG9yZS9ob21lP2llPVVURjgmcmVmXz1uYXZfc2lnbmlu

In addition to the dynamic parameters, we also need to submit the username and password, which are currently hardcoded as can be seen below.


We could parameterise these also, but I’ll talk about that another time.

So how do we go about obtaining the correct values for these parameters, such that when we send them all, along with some valid login credentials, we get a logged-in session back from the server?

Well, the first thing is to figure out from whence they came. Experience has taught me that it’s usually (though by no means always) from the immediately preceding server response. So let’s go back to the results of our test and take a look:


The HTML response isn’t telling us much… We need to switch to text mode, and then take a look for the parameter name. Let’s start with the appActionToken parameter:


Voila! We’ve found the token, and the value. But if we run the test again, we’ll probably see a different one:


It’s a fair (in fact guaranteed) bet that we’ll find the rest of our parameters embedded within this response too.

So what we need to try and do is extract the parameters from the server response, each time we get one – and then pass it into the next request. Performance testers call this process correlation. JMeter provides us with the Regular Expression Extractor so that we can go ahead and correlate our parameters from one request/response to another.

The first step is to add a Regular Expression Extractor to the request login page HTTP Sampler, by right-clicking on it and then selecting Add > Post Processors > Regular Expression Extractor, thusly:


Next we need to write some Regex with which to extract the parameter.

If, like me, the idea of writing regex makes your toes curl with horror, don’t worry. I’ll share a special piece of JMeter goodness with you. It’s the only piece of regex I’ve ever really needed to know. And it goes like this:


Did you get that? I’ll repeat it just in case you missed it…


To use this regex and get the parameter we’re looking for, I reckon something like the string below should work:

name=”appActionToken” value=”(.+?)” /

Trying it out in the RegExp Tester view of the response, shows that it will indeed work, since the test came back with only one match:


The RegExp Tester shows me how many matches the regex pattern will create, what the match is, and the value to be extracted – 1, 2 & 3 below respectively:

  1. Match count: 1
  2. Match[1][0]=name=”appActionToken” value=”pmHS1gy9iYMSJOWBIPlCWZGq1SIj3D” /
  3. Match[1][1]=pmHS1gy9iYMSJOWBIPlCWZGq1SIj3D

What I’ve done here is, take the HTML response, and apply the simple bit of regex I described above, in order to capture only the string that we’re interested in.

<input type=”hidden” name=”appActionToken” value=”pmHS1gy9iYMSJOWBIPlCWZGq1SIj3D” /><input type=”hidden” name=”appAction” value=”SIGNIN” />

The “pmHS1gy9iYMSJOWBIPlCWZGq1SIj3D” bit, basically.

I’m not going to go into how the regex works, because that’s beyond the scope of this particular post. What we do need to do now is plug it into the regex extractor so that we can use it in the request login sampler.

Here’s how the finished extractor looks:


The important things to note are these:

  • I’ve given the Regular Expression Extractor a meaningful name – appActionToken Extractor
  • I’ve given the variable into which I want to put the extracted token a meaningful name (in the Reference Name field) – appActionToken
  • The regular Expression field contains our regex – name=”appActionToken” value=”(.+?)” /
  • The Template, Match No and Default Value fields are filled out more or less as per the Apache JMeter guide.

You can learn more about the Template, Match No and Default Value fields by reading through the online guide from Apache here. I’d recommend sticking with the defaults, but you may gain some mileage in experimenting with them.

Having extracted the value successfully and placed it in a JMeter variable, we now need to use the variable in the submit login sampler. We can do that by referencing the variable where the token was originally.

JMeter knows we want to use a variable when we place the name inside curly parenthesis with a leading dollar sign – ${variableName}, like the below:


With that done, we’re almost ready to go. Except, our script still won’t work because there’s those other 10 dynamic variables we need to correlate as well. Fortunately, the process is exactly the same for all of them:

Locate the variable in the preceding response – the request login page response in the case of our script.
Construct the regex to extract the variable – as discussed above.
Create a Regular Expression Extractor for each variable to be correlated.
Refer to the extracted variable in the subsequent request – the submit login page in our example, as discussed above.

Once you’ve gone ahead and done all of that, you’ll likely end up with something that looks like the below:


And, assuming that you’ve done everything correctly, running the test again will result in the desired logged-in response from the server:


We can see above the JMeter is logged in by the “Hello, jmeter” message in the response.

We’re done! Our login script is now ready to rumble. And having covered the basics, we’re ready to tackle some more advanced JMeter topics. So stay tuned for those…

Recording a Login Script with JMeter

Following on from my last couple of posts where I covered initial setup and use of the HTTP(S) Test Script Recorder, I’m going to build on what’s been done so far in order to develop a login script.

I’m assuming that you have a test plan setup more or less identical to the below, in which case we’re good to go. If you don’t – then I suggest you read through the preceding posts before continuing further.


The thing we need to do next is figure out what requests need to be sent in order to simulate a user login. We could try and craft them from scratch, but it’s easier to simply record what happens when I carry out a login and then modify the recorded requests to make them resilient and reusable.

To do that – we first need to make sure that:

  • The JMeter proxy is recording our requests
  • The browser being used is directing traffic to the proxy

Again if you’re not sure how to do steps 1 & 2 above, I refer you to the previous post. Assuming that your proxy is recording properly, then we can go ahead and click on the login button and see what happens:

2Once you’ve done so then, under the Recording Controller you should see some activity. When I wrote this, I saw the responses below:


Further examination of some of the recorded requests suggests they’re irrelevant to the task at hand. I have no idea what the request below is doing for example:


If I actually worked at Amazon I could probably go and ask one of the developers what’s happening here, but for the time being I’m going to assume I don’t need it.

Of more interest to me is the /ap/signin/… request:


I’m intrigued by the /ap/uedata/ request also, but I’ll ignore that one too for the time being. In the meantime, I’m working with the hypothesis that the /ap/signin/… request is the one that actually requests the login page from the server.

I’ve added another Simple Controller under my Thread Group. In order to test out my hypothesis I can move that request to the Controller and run it to see what happens. I’ll disable the homepage navigation (right-click on the Controller > Disable) as well, since we don’t need that right now. Disabling it will prevent any child requests from being executed.


I’ve also moved the HTTP Header Manager that was originally under the HTTP request, and placed it under the Test Plan instead. Every recorded request will be paired with one of these, but we only need one of them to act as a default for the entire test. All subsequent header managers can be discarded, otherwise they’ll just clutter things up.

Running the test confirms my hypothesis, since I observe the following result:


I’ll rename the request to something more meaningful and add a Response Assertion to check for some text (“What is your e-mail address?”), so we know the request is doing the right thing going forward.


Now we need to submit some actual login details. Again, the best thing will be to submit an actual login and see what the proxy recorder tells us about the process. I did that while writing this post and saw the responses below:


The /ap/signin request seems like it’s probably the one doing the work, and closer examination shows that the request contains the username and password I used to login with.


We can move that request up into our Test Plan as well, so it looks like the below, adding an assertion to check we’re actually logged in after making the request also. Let’s test for some specific HTML that we would only expect to see when we’re logged into the site. Something like “Your Browsing History” ought to do it.


All good. We can go ahead and run that now, right?


There’s a problem. Can you tell what it is yet?


The assertion has failed because JMeter didn’t get the page back that it expected. In fact, judging by the page we did get – it doesn’t look as though the login has worked at all.

Why not?

If I take a look at the request again, there’s a few clues as to why…


The request is sending a token along with the (currently hard-coded) login credentials.

It’s sending a bunch of other stuff over as well by the looks of it.


In all, there’s actually 11 dynamic variables that need to be correlated across from the previous server response in order for the login to be considered a valid request by the server.

It’s going to take a bit of effort to get all that sorted out… I’ll show you how it’s done in the next post.

Using the JMeter HTTP(S) Test Script Recorder

In my last JMeter post I showed you how to navigate to a web page and assert it’s the right one once you get there. Soon, I want to show you how to login to a web app, but before that it’s time to take a look at the JMeter HTTP(S) Test Script Recorder.

#Note – I’m assuming that you’ve completed the steps in the previous post.

The JMeter HTTP(S) Test Script Recorder is the new(-ish) name for what used to known as the JMeter Proxy Recorder. It’s JMeter’s utility for capturing requests that are initiated from the browser for subsequent analysis in JMeter. In order to successfully craft a login script, we need to know how to build our samplers so that the web app’s servers will accept them as being valid requests. The easiest way to get this information into JMeter is to record it via the proxy.

First let’s go into JMeter and setup the proxy by right-clicking on the Workbench icon and selecting Add > Non-Test Elements > HTTP(S) Test Script Recorder.

While you’re there, right-click on the Workbench icon again and add a Recording Controller via Add > Logic Controller > Recording Controller.


Now go into the proxy (HTTP(S) Test Script Recorder), which will look like the below. I’ve highlighted the areas that are important to us right now:

Port is the port number we should direct the browser to if we want the JMeter proxy to capture the requests.

The Target Controller is where we want JMeter to send the requests to, once they’ve been captured. It’s set to Use Recording Controller by default, and we’ve added a Recording Controller to the Test Plan, so I recommend leaving this field in its default setting.

Everything else can be ignored for the time being. Just hit the Start button. When you do, you’ll probably see the message below (unless you’re using JMeter 2.9 or earlier):


JMeter is telling us that it has generated a certificate to enable interception of HTTPS traffic from the web server. When we get around to trying to simulate a login carried out over HTTPS, you’ll need to accept the JMeter generated certificate in your browser in order to proceed. But we’re not quite there yet.

Before we can start recording you need to install Fox Proxy.

Actually, you don’t strictly need to do this – you could change the proxy manually and then change it back again once you’re done; but using FoxyProxy makes life slightly easier.

Open up your preferred browser (I’m assuming that’s either Chrome or Firefox) and download FoxyProxy by navigating here and following the instructions for the browser you want to use it with.

Once you’ve done that (and re-started your browser to activate the plugin), create some new proxy settings in FoxyProxy by opening up the main FoxyProxy window and clicking Add New Proxy. Navigate to the Proxy Details tab, and you should see a form like the below. Enter “localhost” and the port number 8080 in the marked areas.

Click on the General tab and give your proxy a name. I imaginatively called mine JMeter, below.


When you’re done, click on OK, close the main window and then activate your proxy settings by right-clicking on the FoxyProxy button in your browser tool/address bar and selecting Use proxy “JMeter” for all URL’s, where “JMeter” is whatever you decided to call your proxy settings.

Navigate to a web page in your browser then go back to the JMeter window. Under your Recording Controller you should see that JMeter has captured the requests your browser made when loading whatever web page it was you opened up. I used http://getfoxyproxy.org and saw the results below:


Your results may vary. Navigating to the amazon.co.uk home page produces a significantly different result:


There’s a few different things going on here. I’m not going to go into detail, but a quick scan shows:

  • / = the original page request
  • /images/I/314H9kBtfRL._SL150_.jpg = an image from the amazon site
  • /N4215/adj/amzn.uk.gw.atf;sz=300×250;oe=ISO-8859… = a call to a third party web application – Google Double-click in this instance
  • /gp/gateway-center-stage/ajax/get-content.html = an ajax call for further content from the Amazon server

And so on and so forth.

Most of this stuff isn’t relevant for our scripting efforts, though it will be when we come to actually analysing performance results. For the time being we can exclude it from our recordings by going back to the HTTP(S) Test Script Recorder and clicking on the Add Suggested Excludes button, which will result in something similar to the below.


Re-recording our amazon.co.uk request will generate a reduced result set, probably similar to the below:

Now we’re ready to start recording our login script. I’ll cover that in the next post.

Getting Started with JMeter

I’m delivering a JMeter workshop at Testbash soon, so I figured it was probably time to start doing some preparation for it. It’s only a half day workshop so I don’t expect to cover a huge amount of ground, but it should be enough to get people going with some of the basics.

I think the best way to start learning JMeter is to script a user journey through a web application; logging in, searching for and adding items to a basket, checking out, the usual stuff.

Some of the steps to achieve this are actually quite complicated once you start digging into the detail, so I’m going to split them up over a series of posts. This one covers navigating to a web page and asserting that it’s the correct one once you get there.

If you’re following along, the first things you’ll need to do before we actually get into the details are:

  1. Open up JMeter. I’m assuming that you’ve downloaded it and installed it on your machine. If you haven’t, you can download it from here. I use the word installed loosely since, as long as you have a Java Runtime Environment [JRE] on your machine, JMeter should work fine. If you have some problems with this step then they’re probably machine/environment specific; I recommend a quick hunt for the solution via your favourite search engine.
  2. Once JMeter is open – right click on the Test Plan icon and add a Thread Group via Add > Threads (Users) > Thread Group. Don’t worry too much about what a Thread Group actually is at this point; I’ll cover that some other time.
  3. Right click on the Thread Group and add a Simple Controller via Add > Logic Controller > Simple Controller
  4. Right click on the Simple Controller and add a HTTP Request via Add > Sampler > HTTP Request

A blank HTTP Request looks like this:


There’s a lot of stuff there that you don’t need right now. You only need to fill out the Name, Server Name or IP and Path fields so they look like the below:


Having done so – your Test Plan should look more or less like the below:


Notice that I’ve given my Thread Group and Simple Controllers meaningful names. It’s not crucial that you do that right now, but once your tests become more complex, it will be.

If we go ahead and run our test now (by clicking on Run > Start in the file menu, or the green Play button), we’ll see something has happened, but we’ve no way of checking exactly what at the moment. You need to add a Listener to show you what’s going on with your test. Do that now by right clicking on the Test Plan icon, then Add > Listener > View Results Tree.


Now click on the View Results Tree icon and run the test again. You should see a result like this:


A Response Code of 200 means our HTTP Request was fulfilled ok. Some of the other results may be of interest too, but I’ll cover those another time.

Clicking on the Response Data tab and then selecting the HTML view (in the dropdown just above the Scroll automatically checkbox) will render some of the HTML for us.


It looks kind of basic because JMeter doesn’t load the other page resources (images etc) by default. We can ask it to, but there’s no need right now.

By looking at the response we can see that the page we requested has been returned, but we need to add some kind of check to do that for us in future. We want JMeter to carry out an assertion on the page and verify that it can see what we think it should see. Probably the simplest thing to do at this stage is to check for something specific to prove we’re on the correct page.

In the HTTP response we can see the text “Your Amazon.co.uk”.


If I switch to text view in the response data and do a Search for the same text, JMeter finds it ok – which suggests to me it’s a good candidate for an assertion. So let’s add one by right clicking on the HTTP Request and adding an assertion via Add > Assertions > Response Assertion


Open up the Response Assertion and click on the Add button at the bottom of the page. This adds a new assertion pattern. To verify that our assertion is going to do the right thing, let’s start with a failing test. Add the word “TESTING” into the assertion pattern so it looks like the below:


Now run your test. It should fail.

Expanding on the failed response will open up the Assertion result, and you should see something similar to the below:


Now add the text “Your Amazon.co.uk” to the assertion pattern instead of “TESTING” and run your test again.


You should see a green result again in the Results Tree, indicating that the assertion was successful.

Congratulations. You have your first passing JMeter test! 🙂

Next I’ll move onto logging-into Amazon, which is significantly more complex. Stay tuned!

Ill Communication

Some people think that instead of focusing on “what should I say?” or “how can I get my point of view across?” (i.e. the content of your message), you should focus on the goal you’re trying to achieve (the mission) instead.

Some suggestions for mission based communications might include asking yourself:

  • What is the goal – how will things be different when communication has taken place?
  • Who is the audience – what do they care about right now and what do I want them to care about once I’m done communicating? Also, what might prevent the audience from caring about it?
  • How should I engage the audience – so that they care about what I have to say?
  • What does the audience need to see me do, hear me say, or hear others say about me in order to care about my message?

That’s ok advice, as far as it goes. Clearly the guys below might have benefited from it… They’re talking about a baseball team – where player Who is on first base, player What’s is on second, and player I Don’t Know is on third base… In case you’re wondering. 🙂

Abbott: I say Who’s on first, What’s on second, I Don’t Know’s on third.
Costello: Are you the manager?
Abbott: Yes.
Costello: You gonna be the coach too?
Abbott: Yes.
Costello: And you don’t know the fellows’ names?
Abbott: Well I should.
Costello: Well then who’s on first?
Abbott: Yes.
Costello: I mean the fellow’s name.
Abbott: Who.
Costello: The guy on first.
Abbott: Who.
Costello: The first baseman.
Abbott: Who.
Costello: The guy playing…
Abbott: Who is on first!
Costello: I’m asking YOU who’s on first.
Abbott: That’s the man’s name.
Costello: That’s who’s name?
Abbott: Yes.
Costello: Well go ahead and tell me.
Abbott: That’s it.
Costello: That’s who?
Abbott: Yes.
Costello: Look, you gotta first baseman?
Abbott: Certainly.
Costello: Who’s playing first?
Abbott: That’s right.
Costello: When you pay off the first baseman every month, who gets the money?
Abbott: Every dollar of it.
Costello: All I’m trying to find out is the fellow’s name on first base.
Abbott: Who.
Costello: The guy that gets…
Abbott: That’s it.
Costello: Who gets the money…
Abbott: He does, every dollar. Sometimes his wife comes down and collects it.
Costello: That’s who’s name?
Abbott: Yes.
Costello: Well go ahead and tell me.
Abbott: That’s it.
Costello: That’s who?
Abbott: Yes.
Costello: Look, you gotta first baseman?
Abbott: Certainly.
Costello: Who’s playing first?
Abbott: That’s right.
Costello: When you pay off the first baseman every month, who gets the money?
Abbott: Every dollar of it.
Costello: All I’m trying to find out is the fellow’s name on first base.
Abbott: Who.
Costello: The guy that gets…
Abbott: That’s it.
Costello: Who gets the money…
Abbott: He does, every dollar. Sometimes his wife comes down and collects it.
Costello: Whose wife?
Abbott: Yes.

This goes on for some time. You can watch the full sketch here, if you want to.The conversation above is obviously an exaggeration, but we’ve all had moments when we’ve communicated at cross purposes.

When you’re communicating, it’s good to know what you want to say, and how you think you should say it; to have a plan. But as Helmuth von Moltke says, plans rarely “survive first contact with the enemy.”

Or as Mike Tyson puts it –

You have a plan up until the moment you’re punched in the face.

To communicate effectively you need to be able to adapt to the changing needs of your audience. If they’re not understanding what you’re saying to them, it’s time to step back and reassess how your message might be expressed differently, so that they do understand it – and so that you achieve your desired goal.

As I’ve mentioned previously, I’ve found the teachings and philosophy of Non-Violent Communication to be pretty helpful with that, but there’s plenty of other places to start. Dave Thomas’s recommendations for agility below for example. I’ve adjusted them slightly to illustrate my point.

  • Find out where you are – Process what has been said so far. Consider your relationship to the person you’re speaking with. Observe non-verbal cues (posture, movements, eye-contact etc).
  • Take a small step towards your goal – Start talking
  • Adjust your understanding based on what you learned – Stop talking. Start listening.
  • Repeat

What’s important during communication isn’t just your goal as a speaker. It’s much more important to pay attention to the feedback loop you create during your communications. If you’re not listening to what your audience is telling you, either verbally, or non-verbally – then it doesn’t matter how well planned your message is, or what your goals are. You ain’t going to achieve them.

Words That Sell Software Testing

Some time ago I decided to re-write my About Me page so as to incorporate some lessons learnt from research into sales, marketing and in particular – copywriting. While doing so it made sense to look for words that would lend weight to the message I wanted to convey. I turned to the book Words That Sell for inspiration and as a result, developed my lists of Words That Sell Software Testing below:

Technical words that dazzle the listener or reader with the cutting-edge possibilities of a product or service:

Sets the standard

Cerebral words that appeal to the head and that carry a tone of maturity and competence:


Words that *work like magic* to win customers, appealing to a listener/readers elemental needs – a bargain, a fleeting opportunity, the urge to belong etc:


Words with negative qualities:


Feel free to take another look at my About Me page to see if you can spot where and how some of these words have been used.

In addition to marketing pages on my own site, there’s some other areas where I might think about using this kind of language:

Applying for jobs

I can envisage several scenarios when during some kind of job application process I might use some of the words above. As a headline on a CV for example, when you’re basically looking to communicate your special sauce, a few technical or cerebral words could work wonders.

<Your Name here> is a skilled, pragmatic software testing professional seeking to collaborate with superior project teams to help them set the standard for high performance in the <industry you’re applying for a job in>.

Or when talking about how a specific objective was achieved during a previous role:

<Your Name here> delivered powerful and rigorous testing which led to continuous and reliable production releases.

Communicating testing information

When communicating test results to developers, I might choose select some of the negative words to underline the impact of bugs or a poor user experience:

The users found the interface confusing and the booking process difficult.

Judicious use of some words that sell might also be used in test planning documentation:

Our mission will be to test continuously throughout the project, helping to support the development effort and maximise the teams delivery capability.

Talking about testing

I might also choose to throw a few words into conversations about software testing. For example when responding to an argument against software testing such as “testing can be done by anyone”:

The issue isn’t whether testing can be done by anyone, but how much value the testing adds to your project. How can we revolutionise the testing in your organisation so that your team can deliver a superior product?


I agree with most of what you just said and would simply add that yes – substandard, wasteful and misguided testing can be done by anyone.

The keener-eyed reader will have noticed I threw in some Neuro-Linguistic Programming (NLP) at the end there too. If you’re interested in learning more about that, stay-tuned for future posts.

Why bother to learn Words That Sell?

Marketers, well – good ones anyway, believe that products and ideas are sold to the heart, not the head. When applying for a job, when sitting in an interview, when reporting a defect or set of test results and when talking about testing – I’m basically trying to sell someone my ideas about how things should or have been done. Understanding the needs and motivations [worldview] of the person(s) I’m communicating with will go a long way towards helping me pitch my ideas successfully. The next step is using words that appeal to their existing worldview.

I believe the words I’ve selected above appeal to a worldview that considers powerful, continuous, rigorous and professional testing to be a vital component of successful projects. Hence when talking about testing, I use those words to align my message with their existing set of beliefs.

Trying to change the worldview of someone who thinks testing is unnecessary or wasteful is a different matter entirely, hence the introduction of NLP. But that’s a battle for another day.

In the meantime, perhaps you can think of some more Words That Sell Software Testing… Or perhaps some more examples of how they might be used? If you do – I’d love to hear about them in the comments section below.

Elevator Pitches for Testers

In case you’ve been living in a cave somewhere and don’t know what an elevator pitch is – it’s a way of communicating an idea, product or service and it’s associated value proposition in a short period of time. The name comes from the sales concept that it should be possible to deliver a sales pitch during a brief, chance meeting – during an elevator ride for example.

It’s been observed by various folk within the software testing community that testers haven’t historically been very good at communicating their own value. When commenting on a blog-post the other day it became apparent to me that some of us still aren’t.

I think every tester should be able to tell people exactly what they do and how it adds value, whenever they need to. It occurs to me that practicing an elevator pitch for your testing services is an excellent vehicle for doing this.

I thought of a few examples below.

Exploratory Testing Elevator Pitch

I combine a number of testing activities (test design, execution, reporting etc) into one multi-threaded process saving you/your project/your team both time and money. I’m able to do this because I’ve studied hard and taken the craft of testing software seriously. As a result I’m able to apply critical thinking, advanced testing skills and the kind of judgement you get with lots of training and lots of experience of solving hard problems in real world scenarios. I’m also an awesome communicator and coach, so I can transfer these skills to other people too!

Developer in Test Elevator Pitch

I write automation scripts that exercise your product code, throwing lots of data at your system while blending real-world with edge and corner-case scenarios. By working alongside your development team while doing this, and by posing the kind of questions nobody else thought of or are too afraid to ask – I can help to ensure your team is building the right product, building the product right, and that your product is ready to ship when your business needs it. I’m pretty well up to speed on CI/CD engineering too, so I can help you to develop and maintain your build pipeline if you need me to!

Performance Tester Elevator Pitch

When you release your new web app, the last thing you want is for it to fall over as soon as your customers actually start to use the thing, or the next time your marketing team decide to advertise a Black Friday deal in a prime-time ad break. I can help you to load, performance and failover test your application and architecture ahead of time so you know that’s not going to happen. While I’m doing it I can also check for security issues that your developers may have forgotten about. And the best thing? All the tools I use are open source – so no licensing fees!

If you’re going to think about using an elevator pitch – you should try to make sure you cover off the bullets below as a minimum:

  • What is the objective? – You could use an elevator pitch in a variety of circumstances: to defend the testing role for example, or to try and expand your remit in a project or organisation, or possibly as an opening statement on your CV or in an interview.
  • What do you do? – What problems do you solve, how do you help people, groups, projects etc. Think about what you most want the person you’re talking to to take away from your statement.
  • What’s the USP? – What’s your special sauce, the thing that makes you or the service you provide stand out from the crowd?
  • Is it exciting to you? – If your elevator pitch excites you, it will show. And hopefully some of your enthusiasm will be transferred to the person you’re talking to.

If you want to go for something more advanced, try finishing up with a question – to further engage with the recipient(s) of your pitch. Something like “so how does your team handle [performance/automation/exploratory] testing?” might work for example.

If you want to get really special – you could try adding some words that sell software testing…

GiottoPress by Enrique Chavez