This is the story of how I joined a startup as the first QA Engineer in the company. 

My name is Bruno Medley, I’m a software tester, and I joined Codacy in March of 2018. The main difference between this company and the ones where I had previously worked is that it was my first startup. It was also the first time I was the first and only QA Engineer on a team.

Before coming to Codacy I worked in large telecommunication corporations, national and international, and other big companies. All of them had enormous structures, comprising hundreds of engineers and with lots of standardized processes in place. So, when I started there the QA practices were already in place, and I knew specifically what to do. 

Codacy was different…

Quick leap into the past

In my previous job in a large company, I was quite comfortable. Maybe too comfortable, and that was one of the problems. 

I was hired to lead a small team of QA Engineers in a project with a very demanding “project manager”. I later found out that three colleagues had already failed and been fired from the same position I was now in. A couple of years later, I was leading a team of 11 QA Engineers in a very big and political company: loads of meetings and reports, and not really improving myself or making the impact I wanted on the team, or the work I was doing.

Fortunately, I was able to change to a new project and started working in performance testing, before developing the automation track in the company. 

Still, things were taking a long time to happen. Every small step was a struggle, and I was finding myself reading about all of these new and exciting companies.

I understood that I needed to change and I felt confident enough to start looking for new challenges. Codacy was a perfect fit, and even though I was really out of my comfort zone, I knew I needed to just go for it. 

Onboarding and the first week at the job

A couple of months later, I was starting a new job at Codacy with 30 employees, as the first QA Engineer of the company with the main goal to create a QA team from scratch.

I got there early and I was received at the door by Whiskey, our office dog. Paulo was my assigned buddy, he showed me around and helped me with basically everything from “where is the bathroom?” to “where can I find the WiFi password?”.

Having a buddy is super helpful, especially in the first weeks because they will help you with: 

• Explaining how the office equipment works
• Introducing you to other people in the company, and involving you in social activities like having lunch
• Sharing insights on how things are done in the organization and any “unwritten rules”
• Helping you get through the first “awkward” week
  

My main objective for the first week was to understand and gain knowledge on: 

• The structure and the dynamics of the people in the company 
• The development life cycle and processes in place
• Status of QA processes if any
• Identify the major risk 
• Hang out with people and ask questions
• Create a performance baseline

Listening and observing 

Despite the fact that I was full of energy to change everything and start a revolution, experience has taught me that things don’t work like that, change takes time, people are averse to quick changes, and historically, revolutions don’t work if people don’t accept them. 

First, it is important to gain knowledge by the power of observing and listening, then identify the positives and keep them, analyze the risks, and also adapt to the new reality. This way you’ll start gaining respect and trust from your peers – remember that people don’t know you! 

So I focused on asking questions and listening:

• What do you think you’re doing great?
• What kind of tools do you use?
• How is your typical day-to-day work?
• What is your main concern?
• What is your expectation about what a QA should do?
• If you could solve one thing right now regarding quality, what would it be?

By doing this across the company, talking with key people, and compiling that information, I was able to get a baseline to start working with. 

Equally as important during this first week, was to start building relationships with the team. Keep in mind that there were no QA processes in place, probably most colleagues were having a first experience with QA and the rest of them had bad experiences in the past. If you’re also going to affect their workflow directly, change by itself is hard, don’t turn it impossible by being an anti-social moron, keep a positive vibe and address it in a way that you’re there to add and help “We all are QA”, not to police and accuse. 

Performance Baseline

Probably one of the most important tasks you should do in the first week is to create a baseline. 

Just from asking questions and listening to engineers and other stakeholders, problems start to emerge, so I wrote them down, compiled the information, and learned:

• Status of QA processes
• Major risks 
• Stakeholder expectations

The next step was to create a short and long-term strategy. For this, I wrote a document and presented it to the engineering and product teams.  

The objective was to have everyone on board, and again, start earning trust from my peers. By doing this, everyone felt integrated and heard because of the previous conversations we had, and when I presented and discussed the strategy, it wasn’t a big surprise and everyone was up to date. 

By having people on board, it was easier to back up the decisions I was about to make.

Stakeholder expectations 

Different people with different backgrounds and interests see the world differently, this is also very true regarding quality assurance. You ask three different stakeholders about what they think quality should be, and you probably have three different expectations. And to make things more complex, you also have your own vision. 

Managing this is not easy but it’s possible. I hear comments like: 

• “We should test manually”
• “We should automate everything, no manual tests are required”
• “No testers are necessary. With enough unit testing, we are OK”
• “What are you doing? Do you even test?” 

I try to understand the reason behind each specific expectation or comment, as I can probably take value out of it, and understand that probably the stakeholders that you’re talking with don’t have the knowledge of testing that you do, and at the end of the day what they are really saying is that they want a stable working product.

Make sure you listen and work towards solving those expectations. Even if you’re taking a completely different approach and route, explain your short and long-term vision plans to your team so that everyone understands and is on the same page. 

It is crucial that you have your direct manager on board with what you are planning to do. He is going to give you the empowerment you need to overcome the first struggles (and believe me, struggles will happen), and he is going to defend you or unblock stuff when you need to. So be transparent with your manager, align perspectives and communicate -I found 1 on 1 to be really helpful. 

Short-term strategy

Based on the findings on the baseline, it was easier to create a short-term approach. The main objective was to have quick wins, focus on the major risk identified, and add value the faster I could.

My approach was to create a regression e2e, running continuously, that would cover the critical paths of our application. By doing so, I would be covering most of the critical components and preventing outages from happening in production. 

Additionally, I needed an integrated, stable environment, that would be as close to production as possible. 

To achieve this plan, I had to:

• Explore testing frameworks that would support UI testing in multiple browsers and API testing 
• Investigate the best approach to implement the framework keeping in mind that it had to be reusable, scalable, stable and maintainable
• Investigate how to test async services
• Create a proof of concept running locally
• Expand the test suites to cover all the critical paths
• Make it run in parallel 
• Run on the CI service

As a result, the tech solution was composed of:

• Java for writing code for the framework and tests
• Maven for the “build management tool”
• Selenium for the UI testing
• Add unique, stable and descriptive IDs to identify the elements in the website
• Rest Assured for the APIs 
• Testing for testing framework
• Extent Reports for reports
• Owner to manage properties
• CircleCI for CI
• And last but not least, Codacy to review my own code 🙂

The main reasons why I chose these tech solutions and not others, were mainly because of my knowledge of some of the tools, because they were free, there is nice support from the dev/testing community and a lot of information on the web about them, and they are also kind of the standard in the industry, so proven to work. 

Hence, this tech solution allowed me to implement the plan above, it works but it is by no means the best or the worst, it is just a solution; don’t take this for granted, do your own research to see what it works for you and what doesn’t. 

There is no universal truth or simple answer on how you should approach the implementation of QA in a company. The answer is, it depends. It depends on the culture, on the moment the company is in, on the way people work, if they and I had failed experiences with QA in the past or not, if the coworkers have experience or if it is the first time working with QA, and so on.

Take time to listen and observe, create a baseline and risk assessment, develop a strategy, implement that short-term strategy, keep improving and interacting with what you already have. You will be fine. 🙂

Part 2 coming soon.

If you haven’t tried Codacy yet, please free to try Codacy out, on cloud or on-premise.