Day 1: Status Quo
It’s wonderful how magical moments can happen in the workplace. In our case, our journey from a “conventional” QA testing team, to one of the most advanced and effective Automated QA teams in the country has been fascinating and work-life changing!
Like most engineering teams, we had a disconnect between developers and testers that has somehow become an accepted dysfunction over the decades. This seeming impossibly divide was solved by our QA team; and they changed our world so significantly that our production defects have dropped to near-zero for all projects, and our output per sprint has been significantly increased. Not only has our quality become top-notch, but we save significantly on our profit as a direct result of the improvements enabled by our QA team; as well as our client’s experience with us.
This is our story.
It’s Thursday afternoon and our Quality Assurance Engineers have gathered around for another of their weekly QA Tech Sessions. These QA-specific sessions are run over-and-above our usual Global Kinetic internal tech sessions. Where the company sessions cover all areas of the business, the QA sessions were specifically created to develop our testers’ technical skills, encourage knowledge-sharing, increase awareness, and enable us to become better engineers overall.
For this session, Mark Stares, aka. ‘Staresy’, an experienced Global Kinetic software developer turned project manager, has been invited to showcase a few lessons around Unit Testing to help our testers better understand how developers approach the testing of their own code.
As he steps through code to demo his project on the projector screen, QA’s start scanning and interrogating his code ferociously, line by line.
Questions are sure to be raised. And they are.
“Where are your tests for scenario X?”,
“…and what about special characters?”
Staresy suddenly realizes he is lacking some crucial tests, mostly because his development team, and developers, did not instinctively think about them. These checks may be intuitive to some, but quite common to overlook in daily work and in positive testing scenarios.
Fortunately, Staresy is a seasoned Global Kinetic resident and understands that this isn’t something to be defensive about. He simply notes and acknowledges the issues so that he can address them at a later stage.
As the session continues, more questions are posed around testing and quality; and a deeper understanding of the code, product, and more potential test strategies are revealed. The QA team realizes where the disconnect with the developers are, and how development processes are hampering their ability to ensure quality. A QA person states: “This is partly where our test coverage matrix comes into play.” At that point everyone realized what we had been missing from our approach to development testing.
For us, this interaction where the previously warring factions of dev and test align for a common team goal was unusual, as it is in many organizations. Typically, this is not how all software engineering teams behave. Like most software teams, there has always been a divide between developers and testers. Software developers often looking down on QAs, and company management believing testing is a menial, less important job, not deserving of the type of salaries that developers get. We knew that we need to work as a cohesive team, that we need to automate, that we need to have the team take responsibility for its collective output; and that this will not only be technical, but also cultural in nature.
The importance of having developers working closely with QAs.
Looking at where we are now, our QA tech sessions have enabled a significant shift in how developers and QA are working together within teams. The team has increased its cohesion, their like-mindedness, focus and attitude towards quality which makes these sessions essential and useful.
We achieved QAs and developers brainstorming together, raising ideas to optimize and improve the subject; being engaged and solving problems together. We love how our teams could grow or be restored from something so demoralized and dilapidated, to astounding, bubbly winning teams that everyone wants to be a part of.
So how did this all come together? How did we get it right? What about automation? What about DevOps?
Transforming a department or a business unit is not an easy feat. We determined the key foundations we needed before we could even begin rebuilding.
- Good leadership
A leader to helm this journey who would be aligned with our vision, with ample experience, and with expert understanding of the QA world, modern automated testing, as well as traditional manual testing. - Buy-in from the whole company
Without assistance and support from Global Kinetic’s upper management, transformation and change would have been ridiculously painful, if not impossible.
All teams, tools and processes that QA interacted with had to be able to accommodate and be open to changes, and to assist whenever possible.
From junior team members to lead engineers and project managers, all areas would require constant communication to be in line with the vision, and to also understand how everyone will reap from the long-term benefits.
As we progress through this multi-part blog series, we will walk through our journey of discovery, challenges, and successes of (re)building one of the most outstanding and progressive QA teams in South Africa.
Click here for the next episode.

Pingback:Episode 3: A QA Odyssey – Rebuilding - Global Kinetic
Pingback:A QA Odyssey:- The Global Kinetic team's digital and cultural transformation (Final Episode) - Global Kinetic