There is a lot of focus, and rightly so, on testers getting to know their client’s business to help them test more effectively. In fact, some companies will only look for testers to join them that already have the required specific domain knowledge e.g. those in the investment and pension industries.
However, as testers do we understand our own business? Do we know who our customers are, and what they need from us? Just as important, have we stopped to consider what we need from them?
What type of business is testing?
Conceptually there are two main types of business: manufacturing and servicing i.e. there are companies that make ‘stuff’, and there are those that provide a service. It is the difference between the construction company that builds your new home, and the law firm that handles the deeds and mortgage for it.
So which one suits testing best? Well, do we make/produce anything that would be used by our client on a day-to-day basis? The answer is “No”. It is the technical teams that actually build the system that will help the company make or save money in their business. From the developers that write the code, to the engineers and system administrators that put the hardware together for the new system to run on. Even the business analysts could also be included in this group: they write the specs/requirements from which everything else propagates from. Fundamentally, they all have one thing in common: they’re all able to point at something and say, “I did that.”
As testers, we’re not able to do that. The documentation that is written and tools that are built will rarely be used in a wider context in support of the business or system as a whole. So that puts testing in the servicing bracket and makes us, as individuals, service providers.
Testers as service providers.
So, we provide a service. But what service should we be providing? All testers would have an opinion on this, and most would be valid, but this is where we go wrong. We spend too much time looking inwards to determine what testing should be performed, status reporting, bug priority etc. We need to start looking outwards, and finding out what our customers need/want from us. Good testers are usually open and engaging by nature, so this shouldn’t be too arduous a task. To do that, we need to know who our customers are.
If you work for a consultancy firm, then your employers customers will be the companies they have been contracted by to complete a piece of work for. However, even at this level the negotiations would have been between directors or senior managers i.e. people. It’s not the organisation (company) that we should be focusing on, but the individuals (customers) we work with. They may even work for a different company, but they are still our customers. E.g. you could be working as independent testers for your client, who is having the system built by another company.
Not only do our customers include the people we work with on a daily basis, but also those that have a vested interest in the project we are testing on. This goes from the end user right up to the steering committee: they will all be affected by the testing that we do, or not as the case may be.
The following diagram is an indicative list of the type of customers a tester has:
A lot of effort is expended on a project in documenting requirements for the new product and trying to ensure it meets the needs of the client/customer. However, relatively little time is taken to find out what our customers’ requirements are on the testing to be performed and more importantly the output from it. The likes of Google, Amazon or Facebook have their own testing requirements which might be considered unorthodox but are well known and work for them [i] [ii].
On most of the projects I have worked on, the test team has dictated the strategy to be followed, with little external input. This is often written with terminology not easily accessible to other project team members. The document then tends to gather ‘dust’ somewhere on the company’s network.
We sometimes forget to whom our output is going. When bug reports get written, have we considered the developer reading it. Have we given them enough information and in a format they understand to replicate and fix the bug? When we are planning our testing, have we considered the project manager trying to make sense of the results from our testing? Does it give them the information in the right format, especially if it has to be passed up the managerial chain?
Talking to our customers
How can we improve the service we provide? How do find out if we are providing the right service from our customers perspective?
The first step is to draw up a list of the people that you think are your customers. Then the next step is easy. Go talk to them, and do what you do best: ask lots of questions.
But what questions should we be asking? “Where do we need to improve?”, “Is there anything else we can be doing to support you?” might be good starting points. But the other questions you ask would be specific to your customer. Here are a few ideas:
- Developers – What information do really need from us in bug reports? What terminology should we be using in the bug reports? Is there anything we can do before we start testing the application?
- Project Manager – What information do you need from us? What format do you need the information in? Who will this be passed on to?
- Stakeholders – What do you really care about in the project? What parts of the system are mission critical? What do we need to do to give you confidence in the testing being performed?
If we understand our customers’ needs and wants, then we will be able focus our efforts more effectively and efficiently. We also have a better chance of being engaged by the other teams, which would reduce the them/us syndrome that still affects too large a percentage of projects. Finding out from the developers what information they really need to see, means they can get bugs fixed quicker with a higher ‘first serve in %’ to borrow a tennis analogy. If we know what information needs to be included on our test reports, we can structure our testing up front to suit, reducing the need to massage the data to fit the needs of the project manager.
Testers are customers as well
Going back to the house building analogy, it is unusual for the roles to be simultaneously reversible within a customer/supplier relationship. However, testers are in a symbiotic relationship with their customers. Without documentation, code etc. we would have nothing to test nor anything to base our results against. Without a project schedule, we wouldn’t know when the system or functionality would be due for testing. Without the testing we provide…. Well, there are countless examples that make the headlines where something hasn’t been tested properly.
So, we are a customer as well as a service provider. As a customer, what do we need from our suppliers? We would all have our list of requirements and, depending on the relationship you have with your suppliers, it could be pretty long! However, the item at the top of 99% of our lists would be: information. We have all had an experience where we have not been kept up to date on what is happening on the project or we have not been made aware of a key architectural component in the system that has a direct bearing on our testing.
The dreaded word! This is not a proposal on creating even more documentation, but agreements that have been reached should be written down somewhere/somehow. It may be that your test strategies and test plans should be revised to include the extra information. If there are standard documents being used within the company, then this would make an ideal location to record the requirements of both parties. Otherwise, documenting it separately will be needed.
Whichever option is chosen, the important point to remember is to write it using terminology all parties understand. We need to ensure our customers feel they own the process as well, and documenting their requirements in ‘test-speak’ would make this task a lot harder.
We also need to remember that the relationship we have with our customers is not set in stone and will change over time. So however we have decided to manage our relationship, it will be a living document. We’re not going to get it perfect first time round: both we and our customers will overlook some detail which is going to occur later in the project or on a future project.
Aiming to improve our service
Without understanding what our customers’ need and want from us, we cannot expect to improve the testing we provide to them. To do this, we should try and do the following:
- Identify who our customers are.
- Ask ourselves what we need and want from them.
- Find out when is best to talk to them.
- Compose a list of questions to ask.
- Meet with your customers.
- Write your respective requirements in user-friendly language and get them signed off.
- Decide on where best to store them.
- Keep reviewing them at regular intervals and update as required.
By treating everyone as a customer, it forces us to change our perspective on how we should interact with our colleagues. To achieve this we need to look at changing the way we work. Going back to the building analogy, the builders and engineers may not have much interaction with the client and may not provide much guidance during the project. It is the architect that would normally have the greatest interaction with the client, giving suggestions based on the client’s requirements, giving alternative solutions, and would give guidance throughout the project. In some cases they can also act as the project manager. It is this level of interaction that we should be aiming for with our customers by being more than just the tester on the project. We should aim to be the test architect on the project by listening to our customers and providing the solutions and guidance to their testing needs.
About the Author
Iain Bright has been testing for over 10 years. He started in a UAT team in the financial sector before moving to Ireland. Since then he has worked on a variety of projects in different sectors both as a System and User Acceptance Tester and is currently a Team Lead at Spencer Stuart in Dublin.
Why does Iain still test? He enjoys working with people; rising to the challenges that testing brings; and just as importantly finding bugs before anyone else does.