It is something that many won’t agree upon. But my question is: who is your client? Who do you consider to be the one you’re working for? You might have two answers. First is: “My client is the user of the application I’m testing”. Second is: “My client is the [business line/project manager/company/payer] who is requesting the application to be developped”.
I’ve worked in several situations. Sometimes in outsourced testing teams where our customer were asking us to do test on their applications, eventually used by their own customers or their employes. Some other times for in-house IT teams where a business line was requesting IT department to develop in-house applications.
I’ve seen to many people – developpers, PM, testers – renouncing to argue with the payer, because you’re not supposed to bite the hand that feeds you.
Here’s a short story about this.
I was working as a test consultant in a company, explaining to our different pre-sales how we should talk about test and test automation to our customers. I was saying, that sometimes we should consider giving the right advice to our customer.
Never say that to my client
I took an example of one of my customer, wanting to do test automation to save money. Their testing process was outdated, definitely not working, and he has been told that test automation was the solution. I’ve explained our pre-sales that my approach was to open my clients eyes up on his company lack of maturity, and guiding him through a maturity process that will exclude test automation for a while, but leading them to affordable but sure ameliorations: people training, process simplification, test environment stabilization. That being said, none of these had to involve external working force – that meant, no sale for us at this time.
“Never say that to one of my clients“, said one of the pre-sale manager listening to that story. “Why so?“, I asked. “Because if one of our customer wants us to do work for him, we should never refuse such sale. If he figure’s out he was wrong, we still be able to sell him services to fix it. And however, maybe he would save money with test automation, no?“, he answered. “That’s probably why I’m not sitting on a chair as you are today“, I’ve conclude.
This guy was obviously not worrying about doing the right thing. Ones could say he was worrying about making more money. But if we want to give him some credit – let’s try – we may consider that he was believing his focus should be to fulfill his customer wishes. His customer wishes were to save money by doing test automation, but saving money would probably never happen in this context.
In any situation, my belief was and remains: as a tester, I’m working for the benefit of the product.
Is that different when I’m having another role than tester? Well, no.
I’m working for the benefit of the product, period.
If the payer is asking for something that won’t add value to the product, my role as an honest professional, is to demonstrate it and avoid such waste. If I don’t, because I gave up, because I don’t care, or because I want to make more money, then I’m not doing my job.
As a tester, are we always working for the product? Hmmm, please be honest. I’ll help you:
- We have to test that part first, the business requested it. It never fails but they don’t want us to go further before completing it.
- We must produce daily progression reports on test campaign, it is required by PM.
- Remove from reports and calculation tests that cannot be run due to lack of test data. We guaranteed 100% test completion and it messing thing up.
- This is bad UI/UX design but it is what has been approved by customer.
- Yeah, I know, but it works “as expected”…
Don’t tell me you never heard one of these. Out of context, surely it sounds bad. If we sometimes accept that in real-life situation, it is because we have placed the payer before the product and its user.
Please, work for the benefit of the product. Then you won’t have any doubt on who is your client.