I started my career working for an enterprise, but after a while I changed my path and started working for CodeScene, which is still a startup. I thought it would be fun to share my experience of working with these two types of organizations. But I'll also share my thoughts on why I believe everyone should have a startup experience. Coming to CodeScene breaks all my stereotypes about the IT world and the way it works.
Imagine having a large corporation that already has a huge number of satisfied customers, has been in business for decades, and is slowly entering the maintenance phase. In certain iterations, it means updating existing features and adding some minor ones, but the main idea of application is finished. Yeah, I thought the same as you, that sounds really good.
On the other hand, imagine another situation where you have a project with a fantastic idea that has to start from scratch. When you work for a startup project that is breaking into the market and expanding its brand, you get involved in many different areas - everything from marketing to testing. You get to experience the whole journey.
We are growing together
For me, a startup means that we grow together, as a team and as a company. As a Test engineer, I try to take on a bigger perspective. My responsibility is not only to test that the feature works but also whether it's user-friendly.
Is the message in the functionality clear enough? Is the flow good enough? What is my opinion regarding this?
Your voice is stronger
When I first started working for an established corporation, I was very pleased to work for a client that has already built a name and a reputation. All the processes in an enterprise are well defined down to the smallest details - from delivery methods to the rhythm of the work. You just jump into an already established system.
Working for a startup is often quite the opposite. Through teamwork we are establishing the system together. You have more opportunities to participate since it is still not a large system that has all the details in place. You have more freedom to propose new things for implementation, new ideas, and new ways of working.
For instance, if a new automation framework is available, you can try it out. There are no (often very boring) restrictions that also often mean you need to restructure your whole code and follow only one working principle. Our QA team at CodeScene can follow the latest trends in Test Automation. We are currently replacing our Selenium-based end-to-end tests with Playwright.
Company best practices evolve as the company changes. Each of us is involved in inventing the new "rules" for the next iteration.
From the Test Engineer perspective, I try to always have an even bigger picture and advocate orderly processes - what is most important to have automated, what has the highest priority, document the purpose of the automation script, and then move into the process of writing the script. All this with the aim of better organization within the QA team, clearer monitoring of progress, and finally faster bug detection on the most frequent flows performed by our users.
Everything happens very quickly
When I worked for the enterprise, we followed an Agile methodology. However, coming to CodeScene, I quickly adapted to a new way of working. Our team is transitioning toward a more trunk-based approach. We have short-lived feature branches and sometimes several releases in a single day.
The first week, I was extremely amazed and had a lot of questions, and one of the questions was, "Ok guys, you don't have daily scrum meetings, how do you survive?".
Trunk-Based Development for QA means that there is extremely good automation coverage, and that by adding new functionality, test automation should ensure that most functionality works as expected. The final idea is that tests will be triggered for every pull request(PR) that goes to the main branch to confirm the stability of that PR.
This requires good automation setup, very stable tests, very relevant tests, and daily maintenance. As I mentioned, things happen very quickly. Quality test automation helps us to be sure that none of the most important functionalities are broken.
Faster growth in career
In the end, both experiences make our careers richer and our horizons wider. But if you ask me, for fast career growth, it is sometimes good to jump out of all barriers and boundaries. Participate in writing and setting up the code structure and documentation, define and establish processes, and track product progress and growth. Do everything from scratch. And finally, look forward to each new customer together. This is an experience I would recommend to everyone.
