How to survive a Startup as the only tester

For the past year, I have been working as a QA tester in a start up and I have listed a non-exhaustive list of 5 things that have helped me survive in a world where everything is a high priority. This is written for people that work in software development, people that work in startups, and people interested into insights as to what it’s like working as a tester or people who want a glimpse into startups.

These things do not just apply to testers, they apply to everyone that wants to be more effective in their daily life. Understand the role of the tester in software development Here

1. Start your day the right way - Write down Goals and Objectives of the day

One of the habits of highly effective people is that they set their goals and objectives before they start their day. Imagine this, you get to your workplace and continue working on the task that you still haven’t completed yesterday. You get to your zen state of getting work done then suddenly “I want you to work on something else now”, how frustrating is this?

I have experienced the frustration too many times and getting into insanity, doing the same thing again and again and expecting different results. It was time for change.

Set the table, write down your goals and objectives for the day. New scenario: You get to your workplace, sit down and write down a few not so detailed notes - what happened yesterday? What could have been improved with what you could control? What is my goal for today? What am I supposed to do now and is it aligned with my goals? Is this priority?

Here is an example:

  • What happened yesterday? I am progressing on my tests for “Release X” and found bugs (YES!) These bugs are cosmetic issues and this means I can continue with the testing today.
  • What could have been improved? From the cosmetic issues that I have found, it was not added to the specifications. Next time, the specifications will be improved and that this should be brought up in the stand up so everyone in the team is aware of what happened.
  • What is my goal today? My goal today is to “complete” the testing for Release X. This release will benefit the business in Y and this is what drives me.
  • What am I supposed to do now and is it aligned with my goals? I will complete the remaining test cases that have yet to be done for Release X. Once I have completed that, I need to have a few meetings to discuss specifications for the tickets for the next sprint.
  • Is this priority? After a talk with my manager, there is an issue that requires immediate action. I will jump on this and continue with my goal for the day once this is done.

These questions I ask myself covers a reminder of what I did yesterday, reflection on what could have been improved, the motivation as to why I’m doing this, and making sure I am doing the most important things everytime.

2. There is always something to do - so do the most high priority task

One constant blessing while working in a start-up is having too much work. You should never have a moment when you tell yourself “What am I meant to do?”. Imagine telling a colleague “I don’t know what I’m doing” - to make it simple, do not say this.

The curse of choices, there are so many things to do. So you complete the tasks you have been set, now you have countless of other things to do. The question is “What am I meant to do now?”

How do you decide what’s priority? List down the list of the items you have to do, and rank them based on your current goal. Sit down with your product manager, test lead, test manager and then for each task you can give a simple ranking system. I like to keep things extremely simple and our team is not so big so the communication overheads are not so bad.


  • Critical - This is what you have to do now.
  • High - This task needs to be done to achieve our sprint goal
  • Medium  - This is a ‘nice-to-have’, you can do this after you’ve done your critical and high priority tasks
  • Low - This is not priority and do not do this now.

Once you have sat down with your manager, you will now have a list of things that you have to do in priority. Important - This will be your most important tasks during a certain time and you have to communicate with your team on a daily basis to make sure you are always doing the most important things. If you do unimportant things, a deadline for a project may be missed. In a startup, it is vital that you only do the important things as resources are always tight and the business might lose out on leads.

Remember: You are part of the development team, a function that is vital to the growth of the business. What you do will result in more and more people using your product and what you will experience will contribute to your personal growth. This is powerful - If you are not motivated (intrinsically) with what you do, It’s probably time to do something else.


3. Work in bursts

Sometimes, working in a startup can be overwhelming. You are shoved into the deep end, you do things that you have no experience of doing things before, and you have time constraints.  Imagine, you are working on concurrent deadlines, you have to set different parts of your day into doing different things just to make sure you can hit the deadlines. Suddenly, you are hit with another more ‘critical’ thing that you have to do and you will feel paralyzed.

When you are testing a complex product and a wild feature set, do it in bursts. The human mind has the ability to manage and adapt to complexity, but it can’t do it all at once.

What you can do is to do your work in bursts. What I do is get a timer, set the time to 40 minutes (you can do more, you can do less). In this allotted time, you will focus on work. Once the timer has finished, stand up, get water, and take a walk for around 5-10 minutes. Don’t worry about being unproductive for this time, you’ll thank yourself later.

When I started working in bursts, I began to see patterns and outlines. I thought about design patterns on how to make my testing more effective. Overtime, I managed to design a comprehensive test plan outline to account for certain types of releases.

4. Define: "It looks like it works"

Everytime I hear someone say “I tried it and it works”, “It’s working on my local”, or other things along those lines, I always have questions about what they mean by that. Fast forward to once the release is in the testing server, you try to do the same thing and suddenly you ask yourself “How come it doesn’t work, when I was told it does?”

I recommend to have a team discussion of what “It looks like it works” means.


  • What’s the “it”?
  • What part of the product are we talking about?
  • What did it look like?
  • Which requirement number was checked?
  • What type of requirement is it? Functional? Performance? Security?
  • When does it work? Operating System? Browser? Resolution? What other things where happening there?

Here is an example:


Team Member 1:  “It works”

Team Member 2 : “What is it? What part of the product? What requirement? Plus numerous other questions”


Team Member 1: The “Settings” button in the homepage. The settings button looks like it satisfies the design requirements set out on the requirements documentation. The environment that I tried testing it at Windows 10, Firefox v57.0.1 at 1920 x 1080 Screen Resolution.

Team Member 2: Great!

The point of this is to define what “It looks like it works” means as it is too ambiguous to just say the sentence. What I say “It works” will most likely not match someone else’s definition. You will have a team definition and everyone will be on the same page.

In the end, all you have is an impression of the product. No matter how well documented, you can never be completely sure that your testing covers all the scenarios. When you report to your senior about the status of the testing / product quality, you should mention how you tested, what was tested, and what was not tested.

5. Improve constantly - become a better tester

Finding a bug when you just released, should you be sad? Beating yourself up? Fear no more. So you don’t find a bug in the test process and it causes trouble for your users - A learning experience! Did you miss it because you were following a good strategy and what was found was an extreme edge case? Add it to your test scripts and move forward. These things happen. Did you miss a bug because your test strategy was focused on the wrong problem? Sit down with your team and discuss what happened and what you can do so it doesn’t happen again.

Excellent testers are always improving. Everytime you go through the development life cycle, the tester will gain insight into the product and get better in every way that matters for the next iteration. In the next iteration, the tester will become more effective and more efficient compared to before. The tester will suggest an improvement to the process, how certain issues can be prevented, and improving communication by helping in the definition of what the deliverables are for each stage of the cycle.

When you evaluate your process, look first at the quality of the people in your project. How do they think? What affects what they do? What can you do to enhance their effectiveness? Once you have answered these questions then evaluate your process.

Here is an example:

Let’s say you only have one tester in your team and he is constantly testing. He is expected to write out the test strategies, test plans, and test scripts for each release. For a particular release, the tester was unable to look at the acceptance criteria of a ticket and write out test scripts as appropriate.

Moving on to the later stage of the development process, testing. The tester finds a huge list of bugs and the project was eventually released later than expected.

Fast forward to the Sprint Retrospective, the tester suggests that there should be appropriate deliverables for each stage of the software development lifecycle. The tester felt that the bugs found would have been included in the test scripts but he did not have time to completely write them.

The Result: When the tester has no time to write down test scripts. The developer will write down his/her own test scripts, once complete will be reviewed with the tester to make sure that their goals are aligned.

Remember: The role of the tester is not to find issues, it is to ensure that the product quality remains at a high standard and never accept that something cannot be improved for the next iteration

Interested in what the role of the tester is in software development? Click Here

Happy Testing and Keep Improving!


  1. Hello superb website! Does running a blog like this take a massive amount work?
    I’ve very little knowledge of programming however I had been hoping to start my
    own blog in the near future. Anyways, should you have any ideas or tips
    for new blog owners please share. I know this is off topic however I
    just wanted to ask. Kudos!

    • One Man

      Hey there, it doesn’t take much time to main the website. I make it a rule that I do not spend more than 2 hours a week on writing content for the blog. The most important tip I can give you is to just do it 🙂 I contemplated for months before starting this but I’ve actually started doing it now and it has been great.

Leave a Reply

Your email address will not be published. Required fields are marked *