Only and First specialised Tester in Company

Can you guys share your experiences as the lonely Testers in a company and how you manage and plan your work.Please suggest activities to get started if one is moving from a big company to a small one as the single tester of company.


The Dojo just happens to have a nice series about exactly that issue! See [].
From my experience, the first thing to do is educate yourself about the product that you are going to be testing. And then just jump in, start testing, and start logging bugs. Ideally, you would have access to someone knowledgeable, like a senior developer, who can make time to help you get up to speed. If possible, before you log a bug, run it by this person to check whether you are off base. But if that’s not possible, just go ahead and log them. Some of them will be invalid because you misunderstood something, but if you find even one real bug, that’s valuable, because before you started working, no one would have found it!


I second learning the software you’re testing. (I wrote the article @eliseb linked to - thanks!) Also, be prepared to do anything and everything remotely test-related.

I’m now quite decent at administering Team Foundation Server due to being the one to set it up so I could use the MS tooling for other tasks. I also maintain the integration tools for TFS and CA Agile Central, set up and manage a rather basic CI pipeline for the test automation I’m writing in tiny dribs and drabs (because my first priority is always testing the changes to the software by whatever means I can - usually exploratory with some scripted notes where I need to cover parts of the combinatorial explosion you get when there are a lot of configuration flags), update other documentation, maintain a team wiki… You get the picture.

When you’re the only tester in the organization, you need to be flexible. On the plus side, it’s rarely ever boring because there’s always something new to deal with.


I was in this position 2.5 years ago. I think the biggest thing I learned was it’s important to evaluate where the company is. Being the first tester, it likely means there’s no real process around testing, bugs, etc. I was surprised at how little time I spent testing, verses building buy-in for other changes to really drive quality, e.g.:

  • changing the JIRA workflow to match the workflow we wanted
  • getting everyone to write real descriptions instead of the one-liners or only titles
  • building a culture of quality, that the tester is not the catch-all nor the gatekeeper (had to keep pushing folks to at a minimum smoke test their code and make sure it did what they thought it did)

In other words, there were lots of little things that had to be done, and most of the items above, even though they sound small, were actually significant lifts since they required getting people to change their behavior.


I’d second what @ernie says. I spent a fair amount of time getting buy-in from others.

I found my first environment I was a tester and subsequent places there was a common theme. No one had time for testing. In some cases they were happy someone (me) was there to do all the testing. In those cases, I found helping others do a better job was one way to ensure quality. When the developers and analysts were under pressure to get things done, they made mistakes or missed things.

By doing things which made it easier for the team to do their job, the developers and analysts started doing better. Quality increased because I was taking the pressure of the team. Traditional QA was reports and metrics to tell management why the developers and analysts weren’t doing a good job. I flipped it and started reporting what they were doing well.

Rather than reports which pointed out all the things going wrong, I might look at WHY things were going wrong. For example, a JIRA workflow which didn’t really work for the team. Then I’d pick two or three things to improve. Freeing up the developer and analyst time to bake quality in.

It reminds me of the saying, “An ounce of prevention is worth a pound of cure.” Rather than pointing out what is wrong and spending a “pound of cure” to fix it, I’d focus on preventing the problem from happening again (an ounce of prevention).

I also found developers “were good at making sure it did what it was supposed to do” but as a tester I often found problems because “I was good at making sure it didn’t do what it wasn’t supposed to do.” So I turned this around. I would talk with the developers to understand what it was I was testing. As I had them explain “how it does what it is supposed to do” I would start asking questions about “how do I know it doesn’t do what it isn’t supposed to do.” This helped the developers realize when they left a defect in the application or they would explain why there was no defect. If they explained why there was no defect, I’d see if we could come up with a unit test or contract test that confirmed this. In some cases I’d have them demonstrate the defect was not there manually then ask if we could automate what they just did… so some other developer didn’t regress the feature.

After a while the developers would want to impress me by anticipating what I was going to ask about and already have a unit test to answer it. :slight_smile:

I always tried to make it fun. I never made them feel like I was challenging them. In other words, avoid the us (testers) versus them (developers) mentality. Instead, let them educate you so you can be more of a team player.


Well said. Now I want to work with you and I’m not even a tester any more.