Episode 2: A QA Odyssey – A word from our Head of Technology

A word from our Head of Technology

---

This is the second episode in our series on our QA journey. To go to the first episode, click here. 

I wasn’t always Global Kinetic’s Head of Technology. This story starts when I was still a developer in one of the development teams. Rewinding to earlier times, our tech sessions didn’t exist at all. There was ongoing friction between QA’s and developers across multiple teams. Miscommunication between various departments were common and it was generally unappreciated to be a QA.

It seems that testers have always had the short end of the stick when it comes to being seen as adding value. Since the noughties, the software industry evolved with methodologies and ideas such as Agile, DevOps, CI/CD but the QA space seemed to have been left behind, or rather the ‘traditional QA and manual tester role’ was left behind without a clear path to be taken along with the rest of the industry.

Due to the advancements in processes in the rest of the teams, QA’s were struggling to keep up, never mind getting out of the starting blocks. Amongst other things, the QA sign-off process was a major impediment to full sign-off of the sprint. Testers were often seen as the bottleneck during each cycle and were often blamed for production issues, delayed releases and broken processes.

This was ‘the norm’ for years and it kept happening. As a team member outside of QA it was awful being part of a team where only one subgroup are seen as being responsible for delivery issues.  Every issue one way or another pointed to a lack of quality. Be it process or development. Perhaps others were glad they weren’t part of QA, and the situation was unfair to the QA people.

Eventually I moved out of my development team to a tech lead position with oversight across teams at Global Kinetic, and this allowed me to step back, identify the problems and help fix them. My Tech Lead position provided a broader outlook into what was happening throughout the company, across all teams.  At the same time, we had also decided to improve our DevOps maturity. Although I was not assigned to the QA department as such, I was working very closely with the QA Tech team and learnt that what was happening to my previous team, was also happening in most other teams too.

Fortunately, Global Kinetic knew this and had been struggling with solutions to this problem while keeping everything else operational and maintaining momentum. The creation of the Tech team may have been one of the main underlying contributing factors to the successes of our transformation. A dedicated team of tech leads with the purpose of constant innovation and amongst other things, clearing hazards and smoothing the path ahead for the company was essential to our success.

It was extremely difficult to figure out where or how to start fixing things in our QA space, but we had identified the following problems: silos, technical challenges, lack of leadership and direction, culture and lack of progress.

 

Silos

A common practice was throwing things over the wall to QA after a unit of work was completed by developers. There was little to no assistance from developers and they were often annoyed whenever they were questioned by QAs.

For some reason an aura had formed around developers creating a notion that they were superior to QAs. An organized hierarchy may maintain structure and respect throughout, but within delivery teams, self-entitlement and egoistic behaviour has no place amongst peers. This mentality drove QAs further from the team, but fortunately, tech leads were busy formulating our DevOps transformation during this time.

Technical Challenges

Traditional QAs had great abilities and were knowledgeable with testing methodologies and processes, but struggled practically against living agile projects, specifically as DevOps processes started accelerating the rate at which developers could get code out.  It was clear that it was impossible to keep up with the pace of change with manual end-to-end tests.

While we could partially fulfill CI/CD pipelines, optimization was impossible with the bottlenecks and chaos in the QA stages. In addition, this called for test automation, and there was a major lack of process and technical skills surrounding automated testing.

QAs, traditionally not coders or developers, were very uncomfortable with things that could have easily improved every aspect of their process such as coding, pipelines and tooling to assist with automated tests and reports. This was partially an underlying cause of QAs not having the confidence to voice their opinions and not being more involved in technical discussions.

Lack of Leadership and Direction

Even a brilliant leader will cave in with no support structure, incorrect process and no compass. Even though we had a brilliant QA Lead, the role continuously struggled alone with maintaining a traditional QA process in a landscape where processes around QA was changing significantly.

Having no space, time and support to make improvements meant being forced to apply duct-tape to all the issues.

Culture

The general attitude towards testers was clearly a problem.

Lack of Progress

Brilliant engineers want to hone their craft. Unfortunately, the QA team wasn’t working toward a goal of improvement and were doing the same thing over and over. Their lead didn’t have the time to grow the team because of the stress that the DevOps transformation was putting on them, leading to people wanting to leave to get a fresh start.

Acceptance and Enabling Change

Identifying the source of problems:

There was no sugar coating the situation. The QA department was being choked to the point of desperation. People were very sensitive during this period with some people who were fixed in their old ways, and others frustrated by a perceived lack of support from the rest of the team. Potentially changes would have had a disastrous effect.

To minimize any unforeseen damage to the teams, we were inclined towards being analytical and cautious; to tread carefully and observe how to tackle the situation and root causes of problems.
By implementing small iterations of trial and error we could introduce and execute the right change at the right amount.

The importance of managing change:

We knew we needed to change how things were done; both technically and culturally. Having Global Kinetic’s C-suite support in embracing this was key. Turning the team into a success story seemed impossible and would have been destined to fail without the support from top management or if it didn’t align with the company’s goals and values. The transformation also required buy-in from the entire company; especially from project managers and leads. We had to ensure everyone was on board.

Rebuilding

In the next episode, we discuss how we went about changing culture and technical challenges into a winning integrated team. But what exactly were we changing, and how would we resolve the cultural and technical problems we faced?