Kristijan Oberling: QA is much more than software testing

People often have misconceptions about what QA really does. They mostly think it is a person who simply tests software. However, that's not the case. According to Kristijan, a tech enthusiast who is deeply into automation, the QA role is way more intricate and complex than it seems.

Kristijan is our QA specialist, involved in the entire project lifecycle, contributing from the project's initiation to its delivery. He takes a proactive role in early development, spotting potential issues andestablishing effective work processes to prevent bugs.

Having been with the company since its early days, he has witnessed its growth up close. This not only gives him a deep understanding of the EFD dynamics but also allows him to flourish in a direction that aligns with his strengths. Through years of dedicated work, Kristijan has established himself as a go-to expert for ensuring quality in every phase of software development. His commitment to QA excellence makes him an indispensable member of our team.

Quality Assurance vs. Quality Control

Quality Assurance (QA) plays a crucial role in upholding software quality by setting standards and implementing processes. While Quality Control (QC) is an integral part of this role, it also encompasses what is commonly known as software testing.

- When it comes to developing specific features or software, we follow a well-defined process. We kick things off by establishing requirements and carefully reviewing them. Development kicks off only after requirements are clear. Development adheres to predefined quality standards. Once a feature is developed, a tester steps in to examine how everything has been implemented. It's important to note that QA takes place before the actual development, while QC verifies that things are executed correctly. QC is an inseparable part of the broader QA process, he explained. 

“QA focuses on preventing bugs, while the tester (QC) focuses on detecting them."

From kickoff to delivery

Still, the common misconception is that QA only comes into play at the end of a project, simply clicking through things. In reality, it is the opposite. QA is involved in the process right from the start, pinpointing potential errors before development kicks off. Moreover, after development is completed, it suggests improvements for the next project. 

- By analyzing bugs, we identify their causes and implement measures to prevent them from happening again. As the solution takes shape, QA transitions into the role of a tester. This highlights the expansive nature of QA, demanding proactivity and good communication with various stakeholders such as developers, PO, BO, external systems, etc. Ultimately, end-to-end testing is conducted by QA, and they must have a precise understanding of the entire system - from where data originates to where it is stored, how it is displayed, and beyond. QA is deeply embedded in the development process, Kristijan said.

The QA responsibility extends beyond solution delivery.

- Sometimes, bugs will appear after the solution has been implemented. This is inevitable, as certain issues cannot be predicted before actual usage. Clients typically report them shortly after deployment, but also at a later stage. QA takes responsibility for inspecting potential errors, forwarding them to developers for resolution, and re-evaluating after the fix. This systematic process ensures that everything operates as intended and that hotfix changes can be smoothly released live, he noted.

QA: A blend of tech know-how and personal traits

- First and foremost, I would say that QA is not as narrowly specialized as some other positions. In addition to technical knowledge, it is important to be communicative and proactive. One must have an eye for detail, be meticulous, composed, patient, persistent, think outside the box, suggest changes, etc. When I say patient, it's because it's a demanding position, sometimes not taken seriously enough, so a person may find themselves in a situation where they have to push through some proposals, ideas on how to improve quality. 

- Understanding the work of others is also necessary, he continued. It's easy to say, "you did something wrong," but it's not easy to say, "okay, I understand, let's see how we can solve this". Also, you should have an eye for detail. From a technical perspective, one must have at least the basics that developers have and understand how the product works. Developers are often specialized in a certain part of the system, while QA must know the entire thing, including other systems it connects to in order to effectively test, emphasized Kristijan.

In addition to putting oneself in the shoes of the end-user, you need to  understand the client's wishes and needs well, reconciling both sides.

- Anyone can be a tester, but QA is the one who must ensure that things are done correctly and that bugs are prevented. Sometimes changes in processes are proposed to development or product owners. We first propose changes within our own team, through retrospectives in Scrum. We define action points and determine who needs to address them. If we agree, we change team procedures. If we see that something is bigger than the team itself, we propose changes at the company level. That is actually the biggest challenge of my job. QA simply has to ensure that things are done well, he concluded.

Product insight: A key to QA effectiveness

Being with the company from its early days, even before it became part of the Swiss Emil Frey group, he understands how most of the company's products function.

- From the beginning, I have been involved in building most of the products, in various roles. I participated in development, testing, and the implementation of dev processes. That is why I find it easy to navigate through most of our products. I started as a game developer and 3D designer. Over time, the company increasingly focused on the automotive industry. Years ago,  in the role we referred to as Operations at that time, I got lots of knowledge and experience - from databases and technical aspects to maintaining web content. During that time, we started providing customer support. The first such support was for the Lead Management solution we developed for the Geneva Motor Show 2017. I am proud of the fact that I was the first support person in the company. For sure all that knowledge and experience helped me become an efficient QA, he said.

QA in action: Core responsibilities

QA is not just about finding bugs it is about actively shaping high-quality development. Still, when it comes to bugs making their way into production, the responsibility lies with the entire team, emphasizing the importance of collaboration in the development process.

- Quality is our main responsibility. We need to ensure that software development follows good practices so that software does not leave the door with serious defects and that there are no critical mistakes. Again, there is a distinction between defect detection and good quality practices in software development. There can be various reasons for slip-ups. Maybe a developer misunderstood how something should function, maybe we didn’t know enough about the business domain, or we simply made a mistake. It's not an individual but the entire team that shoulders the responsibility, given that functionality goes through a development chain that involves a lot of people, Kristijan said.

"QA needs to ensure that software does not leave with serious defects and that there are no critical mistakes."

- QA responsibilities include preparing documents, analyzing bug results, improving process development, and, where feasible, simplifying processes. What QA exclusively owns are the test cases. These are the blueprints outlining how a functionality should operate and what user behavior should yield. We plan, write, and maintain these test cases. Root cause analyses, or bug analyses, are also exclusively within the QA domain.

- While QA supports a lot of documentation, it's not directly responsible for all of it. This includes product documentation describing how specific features work. It also collaborates with developers to support technical documentation. These practices are standard in the industry.

"In addition to writing test cases, planning and maintaining them is equally important."

Striking the right balance between manual and automated testing

- We pay close attention to ensure that testing is carried out exactly where and when it is needed, especially as our product portfolio expands. We are using a blend of manual and automated testing. Why? Relying only on automated tests can limit adaptability, as they strictly adhere to programmed instructions. Manual testing plays a crucial role in identifying specific cases that could otherwise be overlooked. For sure these two approaches complement each other. In our company, QA also participates in performance testing, Kristijan said.

Introducing automation posed some challenges, he said. It wasn't feasible to automate everything at once; it had to be introduced gradually. As not every tool is suitable for every situation, various tools have been used over the years. The latest tool, introduced at the start of the year, has proven the most successful. It benefits both QA and developers.

- After the proof of concept (POC) phase, we began introducing it to teams. In collaboration with scrum masters, we allocated time every week to train 1-2 people on the team. QA played a pivotal role in implementing changes to the dev process to accommodate test automation. Ultimately, we successfully integrated the automated testing tool into all teams, gradually introducing automation throughout the development process. This was achieved steadily but with a sense of accomplishment, he noted.

The power of a cross-functional development team

The company has established an efficient working model by organizing different roles into well-balanced development teams.

- Our cross-functional development team consists of developers, QA experts, DevOps engineers, Scrum Masters, and others. This allows for better connection among team members, promotes collaboration, and allows for flexibility in our work. Making requests for changes or assisting a colleague is much easier. After experimenting with various team structures over the years, we have found that the current one is the most effective. This is why I prefer working from the office. Communication and collaboration is smoother when we are in the same location. It’s easier to approach someone directly than wait for a response in a chat. Finally, our team is exceptional, even in high-stress situations, he said.