Working as a QA at Atolye15

We could say many things about Atolye15, but to start off; I’d rather go ahead and mention how it feels like to work in a constantly learning and improving team. The most important part of the IT industry is to keep up with the latest technologies and continuous improvement. Keeping up-to-date with latest technologies also opens the gateway for investors to pay attention as well. You feel this vibe when you take a step in at Atolye15. You work with a team that is flexible to come up with the best solution to the problems that occur.

The QA process is fresh but it moves on forward pretty steadily and easily. The common taboo of “Why do we need a QA anyway?” The question doesn’t apply here. There is absolute team work with the developers and it makes it very easy to develop a common language. To prevent any bias from the team, it is beneficial to provide the team with solutions. You are not expected to act as a developer of course, but notifying developers of a solution or a cause for a problem with a common language; it works miracles.

Spotting bugs and saying it’s OK or not is not the only job of a QA in the team. It is to find answers to make the system better and gain different perspectives. This is where you drop the duty on testing and focus on “Quality”. Combining both is a concrete way to increase product quality.

Agile Testing

We could definitely say that Atolye15 totally makes the best of Scrum Agile Methodology. The main reason behind this is not a %100 bug-free system, it is rather to notice and prevent high-risk problems before going live. This might be tough for the testing process at times. We can still solve it with teamwork real quick. Once you get to know people in the team, see how they develop and learn the system, you begin forecasting potential problems.

Testing Process

There’s a common conception that QA’s are needed mostly at the end of the sprint. On the contrary, you’ll always have something to do from the beginning of the project, to the very end. Scenarios are generated for all tickets at the initial days of the sprints. Identified problems are discussed with developers and project managers and checked on. Developers start the development phase while the scenarios are being planned. There may be grey areas for both sides during the development phase. The solutions and actions to be taken are found by the help of daily calls or spontaneous meetings. Since we move on forward with Branch-based development, stories / features are assigned to related branches and as soon as the development is over, QA’s take their turn. Only the related branches are controlled on this phase. In case of having another problem, it is checked in the staging environment. If there’s still a problem there, we create them as bugs and they are checked in their own environment as well. If we as QA’s make sure that the job is well done, the branch is submitted to the client.

Whole system is checked before live on the Staging environment and for this, we work on the automation. We pick scenarios that are important for the project and can easily be tracked via the E2E test set. We keep working on these for their automation.

The tools we use

The planning of the scenarios, tracking of stories and running the scenarios are made using Xray on Jira. We benefit from Gherkin Syntax on writing the scenarios. That way we can pass forward the scenarios to the developers for their use on Cucumber. In this grammar structure, there is a common language that is used that is understandable for all. You can count these as the main tools that need to be used. In addition to these, apps like Selenium and Postman should always be handy at all times. We also benefit from our curiosity and our ability to at least read and understand the code itself.

Unit Test

Developers deeply care about testing. They run their own tests as a part of the development phase as well. If there are errors on the tests built by Cypress, the related story is not included in the system. This immensely elevates the code quality.

I wanted to briefly share my thoughts on our work system and principles with you all, hoping you’ll enjoy the reading. If you are interested and you like what you’ve read so far, you can always check our open positions and see if you’d want to work in a team like us!

Until next time, take care!