How are you charging Testers work?

Questions
#1

Hi all!

Hope someone will be able to answer me this question, at least in big picture.
Am not interested in you telling me how much is your company or you charging your Clients your work (I know you are not allowed to say that in the first place) but more about which system are you using.

Am curious how is your company charging your work to Clients?
Are they charging it per hour like they do developers work or are tester’s in a package or developer’s charged hour or per project or something else?

Also, how are you selling tester’s work to Clients?
Charging developers work is not a problem since they can see their progress and work being done, while have heard a stories that some Clients are saying “We dont need testers”, “we will test on our own” or similar just because they dont know what is a job of a tester and what is their role on a project.
Many clients appreciate tester’s work and they do not have problems with it, but there are still some Clients that are saying similar things or are refusing to have a tester on project.

Another thing I am interested is how many testers per projects you usually have?
The best answer would be the ratio of developers to testers on a project and the length of a project.

And my last question, on how many projects are you assigned to at the same time?

Any of the answers or any additional information/tips will be very appreciated.

Best regards!

3 Likes
#2

Hi Luka,

I work for a semi-international IT consultancy (primarily in DK, CN, PH, CZ). Most companies I know like this charge by the hour (time & material) or by fixed-price contracts for the whole delivery. Other companies sell independent IT contractors - in that context the consultant (in whatever role) is generally by the hour.

Estimation wise testing work sometimes is a percentage of the delivery, similar to project management being an (sic) overhead etc. Different rates might be available depending on the seniority of the consultants added to the task (junior, senior, principal) also depending on location (onsite, off-site, offshore).

Context switching luckily sets a limit on how many projects I can jungle at a time :slight_smile: But do consider the “law of rasberry jam”.

Wrt the ratio between testers and dev… Consider the difference between “modern testing principles” where the ultimate preferable is no testing specialists and contexts that rely heavy on UAT and subject matter experts for testing (eg: public sector work flows). Each end of the spectrum has merit. Even when the client refuse to pay for testing.

Here’s some links to get you thinking:



/Jesper

2 Likes
#3

Hi Luka

I’m a freelancer and charge on a £x per day basis, with the smallest unit usually being a half day, though for ongoing work and existing clients I might just charge for a small unit of work e.g. £x for an hour’s testing a new form on iPhone X or some other device they don’t have.

In terms of selling tester’s work to clients - clients either get referred to me by other clients who’ve used me (referrals really are the best form of business!) or clients find my website as they’re interested in finding a freelance software tester, so they already know they need some testing, the info on my website may further convince them they need a tester and then when they get in touch with me, I then get the final chance to sell them on the value of testing.

I’m often the only tester on a project but sometimes work with other testers on a project, usually if I’m working with a test agency, where they might have a big project to work on, requiring several testers.

And finally, the number of projects I’m working on at the same time varies - sometimes it can be several projects on the go and sometimes one project only.

Hope this all helps.

1 Like
#4

Context software development as a service. Time and material basis, sometimes we work on allocations say 20%, 50, or even a 100% of a testers time for that month/period.

Fairly low ratio of testers in my view, example on the 20% rate above that’s jumping into a project for one day a week when there may be 3 or 4 developers full time on it. Currently PM and Tester on one project, test lead on 3 others and supporting tester on a fifth project, usually though its just leading on two or three in parallel which is my preference.

Building quality software requires good testing, sounds straight forward but yes it is something that you need to work with your customers and partners to help them understand and see the value in having professional testers involved. Once they get this, there is normally an alignment that it does not really make sense to make it optional.

Developers also do a lot of testing particularly on the known risks and on the verification and assertion side of things, testers tend to go beyond this and focus a lot on the unknowns, specialised in discovery and investigation and bring out things that even with great developers could be very humanly/naturally missed.

1 Like
#5

A separate challenge is that there are many companies still selling very standard scripted testing, automated or otherwise. This produces a lot of documentation and evidence of testing, the scripts can often be given to a less skilled resource for checking through.

Its a very different testing model to those focused on close team collaboration and the discovery and investigation side of testing but it is a model a lot of non-testing companies are familiar with and even at times ask for.

Its important though in my personal view, if you being asked to provide a much lower value approach that you know will cost the customer more in the long run that you stand your ground on delivering good testing and help the customer understand that value.

1 Like
#6

Thank you all for your answers, I appreciate it!

The biggest reason why some people do not want or think they dont need a tester on project is because they are not educated enough (or at all) what is a job of a tester and what having a tester brings to a project…
All Clients that do have a tester on a project are happy with my work and see a value of it (developers as well).

We a testers we provide them detailed bug reporting with each deploy, details documentation of software, QA part of testing, “Client Support” and we (try to) do automated testing scripts but due to lack of people and too much work, so far main focus was on manual testing but want to change that now with a search of different approach to testing a software and having a better presentation of testers work toward client so they appreciate it even more and to give them better service.

Though your comments raised me another question - are you giving your automated tests to a client with a documentation so they can use them as well?
So far we would mostly show a demo to clients so they know why and what we are doing when we say automated testing scripts but so far I didnt think of sending scripts to them for them to run scripts.
(Am talking about projects which are still in developing stage)

@jesper thank you very much for links, will definitely take a look at them!

1 Like
#7

I could see that work and not work too. The consideration would be around intellectual property (ownership) of the scripts. Also if both teams use the same scripts what would the second run give you of learning?

#8

I see what you mean there…

Ownership of scripts is not a problem I think, since believe (but might be wrong) Client is (at least the part owner) the owner of a code we write for their application.
They actually have an access to all code (at least in our cases) since they are the owners of Git Repositories we use to deploy all code - both the applications, scripts, sql queries and everything else…

That is how we are using automated scripts - to help ourselves to test the application, to do regression testing with scripts and to do smoke testing with scripts which is why it never came to my mind we should share the scripts with the Clients since believe it is our job to run them and write them.
But this forum post made me a question if we should share with them scripts just so they have even better feeling of what it means when we say Automated scripts and to have better feelings why we are writing them and what they bring to the table.
Was thinking it more as another possible selling point toward client.

Just have in mind that am working in Software developing company where we are developing a software from scratch to finish and we are doing it all in house (wireframes, design, developing and testing) so we are mostly working with Clients that are not so technical.

Have just watched this video from Keith Klain " How to Talk to a CIO About Software Testing" and really liked it, he made some excellent points there.

1 Like