Alone in battle - How to survive being the only tester in a startup

Alone in battle - How to survive being the only tester in a startup

Congratulations! you have joined a startup as the only tester. Now, take a cold glass of water and let's talk about the challenges you will face and how to survive to tell about them.

When I first joined a startup as the only tester I had no idea what I was getting into. Yeh sure, you hear about the long hours, the technological challenge, the fast pace and the lack of clear requirements (And sometimes consistent agenda) but the truth is that nothing can prep you to the real deal. When I got into it I could sure use some advice or an article like this one, so consider this my two cents to the future generation of frontline testers.

1. Get to know your surrounding and the way things work - I remember the first few weeks, you come into these guys greenhouse with an Idea of how things should work (or how they worked just fine in the last mega company/ corporate you worked in). There were written specs, documentation and requirements, there were technical documentation owners, there was a clear "Owner" of each aspect of the process and the tickets (If there even is a management tool) had more to them than just headlines. You look at all of this chaos and you are super pumped to share your wisdom and insights on how to make their work process more effective and what is the "Right" way to do things. Hold on, take a deep breath. Acknowledge that before you came there was already a work process. A good one, a bad one - it does not matter because it worked for them. Before you give them a side viewer advice try to extract what is good and needs to be optimized and what can or needs to change. The way you present things can make the difference between being useful to being annoying or condescending. By learning your surroundings, the human material, and the current work process, you can better understand which tools can suit your needs best, what dev process or quality process insights can be implemented and how much documentation is "Just enough" to do your job (If any).

2. Get to know the product - Most chances are that the fast startup pace will shorten your training time and the lack of documentation will make it harder for you to learn the product, it's features and architecture. Insist on what you need and put up a red flag if there is something you are missing. Don't be shy, ask questions!

3. Manage your time and define clear short and long-term goals - What do you want to achieve? what are your assignments for the next day? the next week? the next sprint? how do your personal goals fit in the companies roadmap? Try to understand that you are entering a reality where everything is a high priority and you need to understand in which order to attack each task and milestone.

• Sprint planning and time estimations - Make sure that your time estimations are correctly taken into consideration while planning future sprints. Why? - Because it is the guideline for the number of assignments that will reach you in the next X amount of time. You need to have control over it because otherwise you will drown in the tickets thrown at you and you will not deliver the (unrealistic) expected results.
• The way you receive your assignments-  What is the way you will manage your tasks? is there a management tool? (Jira? TFS?) if so, understand what is the best way you can manage and track your sprint content board.
• Delays in time estimations and unplanned changes - Make sure you are updated in time about changes in priority and make sure you deliver updates in time about your own blockers and delays. Communication is the name of the game.
• Ask for clear task priorities - what are you suppose to work on right now? later on today? tomorrow or is it nice to have?
• Initiate a regular one on one meetings with your manager -  Talk about how you are doing compared to the expectation? where you can improve? give your own open feedback, discuss how your personal goals fit into the company's roadmap. What is the priority of the things expected of you?
• Actively participate in daily meetings - what did you do yesterday? what are you going to do today? what can be improved? are there any blockers? communication is the key to a productive process.

4. You are not the only owner of quality - Let me sum it up for you. The responsibility for releasing a bug-free and high-quality product/module/feature is on everyone who "touched" it. Now go on, and spread the message. The managers need to accept this responsibility and make sure that the developer tests the feature before it reaches your desk. They did it before you came so there is no reasoning to stop doing it when you are there. Now lats elaborate. Psychologically, when you know someone will test the feature after you, you will invest less time and effort in your own testing. It is a lot easier to let the final bottleneck to take the heat or be your bug-gate keeper, but we are not the only owners of quality and it would be pretentious and unrealistic for us to think so. One cannot know everything and how everything works, and as a matter of fact, a lot of the defects and critical issues I find in my everyday routine is a result of me debriefing the developers and understanding which areas of the code could be affected from the changes made. In my case, I truly work with very responsible and talented devs that are highly test-oriented. That incorporated with test-driven development process makes my life a little bit easier.

5. Giving confidence is not your job - I'm risking here to look like I'm re-writing Michael Bolton's words, but it is not our job to "sign on" or give confidence of the product to our stakeholders or customers. Let's leave that to the sales and customer success team. Our job is to find out what works, what doesn't, how does it work and what is the way to reproduce it. Don't expect that from yourself and don't let other to expect that from you.

6. learn - What I'm about to say probably will not come as a surprise, but, a startup is the best place to touch and learn technology hands-on. Architecture, software products, tools. You get to choose technology and implement processes and integrations. There is no "System" department to come and set up our processes and desired software, sometimes there are no pre-prepared environments and you will need to personally set up a local DB, git branch env or architecture. This is your chance to touch and feel technology hands-on. It is true what they say, that from this particular aspect a month in a startup equals to a year in a big company. It is also your chance to open up, to shine, to take responsibility and initiative without being held back by bureaucracy or corporate culture. (No offense to the corporates). A startup is a great place to grow professionally. Ones you prove yourself, and the company grows you can proceed to be a team leader or aquire additional skills and professional value.

7. Enjoy it! - There is nothing like the startup vibe. Ones you get used to it - you can't live without it. :)


I hope this article will help those of you that are about to enter a startup, and I wish you the best of luck!