A QA Odyssey:- The Global Kinetic team’s digital and cultural transformation – Final Episode

Episode 4: What we have learnt, Tips and Recommendations

In the previous episodes, we discussed why we decided to radically alter our QA processes and how we work. We discussed the importance of having the right leadership approach; and how we rebuild our QA competency. If you have missed these, click here to go to the first episode.

And… back to leadership

The primary responsibility of leadership is the creation of an environment that enables a successful culture. Our journey could not have been successful without the correct leadership; in both the QA test journey, as well as the company’s drive towards a DevOps culture; from the highest level of the business. In addition, members were given freedom to realize their potential as individuals and as a team. Support both in terms of culture and softer issues, as well as technical skills, enabled our journey.

Tip 1: Invest time, persevere, and don’t give up

As many breakthroughs we had, we still ran into challenges. Sometimes achieving or solving one thing would introduce a new set of challenges. But we learnt to be familiar with this cycle. If we did not put in all the effort into revamping the most troubled group in the company, we would never have achieved what we did as a team – as a company.
There were so many times when we could have just given up and say this was a lost cause. But we forged ahead, and carried each other through as long as there was a glimmer of hope. One way or another we just kept pushing through. There was a vision and a goal before this journey started and that vision spread and remained as our guide whenever we lost our way.

Tip 2: Step back if you need to move forward (again and again)

Often, we’d run out of ideas or hit a brick wall when faced with insanely challenging situations. As with coding, it is quite easy to be lost in your own code and struggle to troubleshoot an issue that may be obvious to someone else. Sometimes taking a break, stepping back, or finding a rubber duck helps create a new perspective on the issue.
Often the source of the problem is elsewhere, you fix that and then realize you were looking at, or were trying to fix, the wrong thing. Sometimes we try so hard to fix something in our department when the solution actually involves fixing or updating a problematic process in another department.

Tip 3: Pay attention to everyone – care for each other

As Tech Leads, avoiding human interaction is just impossible. We’re faced with clients, different personalities, and people from multiple departments asking for advice and help. Perhaps only experience will allow one’s intuition to mature well enough and be at peace with the realization that everyone is different; how all the lessons learnt throughout our careers will allow for a more justified respect and empathy towards our peers.
For many introverts in the industry, this might be a more difficult skill to master than any technical ability. One of the many reasons why caring for each other is a core value of our company. Everyone is different, we all have our own tolerance levels towards emotions, abilities, and other human things, which is why it is important that we allow ourselves to adapt our communication and teaching methods for everyone.

Tip 4: Learn from previous mistakes – but also learn from the successes

Even during retro’s, it is easy to just remember and list the bad things. Always remember to also note the good things. Just because something was done well, doesn’t mean that it should be forgotten. Bad things are left open to get fixed and improved on. It should be similar for the good things as even a working process can be improved and made better. Everything, even optimized processes should remain open for change.

Tip 5: Spread the culture to other areas

Enable the QA team to spread the inclusive culture of automation to non-QA members in their teams.

 

To conclude our series, we’ll end off with an interview with Mike and Denisha who enabled and captained this journey. 

1.  How did you change the culture from having QA seen as outsiders, to having them as inclusive members in their teams? How do you think that happened, and did you use any tools?

Mike 

We didn’t really introduce any new tooling because most of the overhaul was towards shifting positive mindsets and attitude. All we had were 2×1-hour sessions per week to start sharing knowledge, ideas and rants. Those two hours a week made an insane amount of difference IMHO.  

Instead of being isolated, they found a way to bond and really feel they weren’t alone as others had the same struggles or were solving similar issues and they had others to help them tackle challenges. 

We had a brief period where things were noticeably falling apart. It was when we started getting ridiculous excuses to skip these sessions, so we dodged that bullet and made them compulsory, unless there was a reasonable excuse not to attend. 
Early communication helped get the point across to upper management and PM’s to assist in keeping the momentum going so thanks to them for that. 

Denisha 

I think the introduction and standardisation of the new automation frameworks that Mike and I built, contributed to this. While building these automation frameworks, we bounced our ideas of each other and regularly put ourselves into the shoes of a tester.  

When I ask the QA team about what they believe is the main contributing factor to their success, they say it’s that ‘bridge’ between development and testing which Mike and I built. They feel that they are now heard and have a strong link with their developers. 

I believe the investment of time is also a defining factor. There is a lot of time dedicated to training and most importantly, listening to the team. 

2. What steps did you take to get the QA guys technically upskilled; and what were the challenges with this? What was easy?

Mike 

We had to cultivate the mindset of learning. Once we had, we were able to re-evaluate where the issues were with the current tools. We had (still do) continuous evaluations on why or how we use the current tools if we needed to drop them or keep them. More often than not the tools were being misused or people were not trained enough to use them. 

From a developer’s POV, QA’s were really intimidated with coding, hence why automation was dragging, and it stayed that way because of no support/advice.  
It was more about kick-starting that. Once the group got fed a little help with coding and had a nice structured process and environment to allow continuous learning through code reviews, they just ran with it. QA’s LOVE stringent quality measures. Although not perfect, they’ve built up a culture around giving constructive code reviews. 

Also, we played around with learning platforms like our Dōjō (based on Moodle) and tried to create side projects to get familiar with tools and learn the tech surrounding the technologies QA uses. 

Practicing what we preach or eating our own dogfood also played a big part, i.e. automation frameworks like Groot, Rocket and Loki really helped with upskilling, because they were conceptualized and born in-house, so developed, maintained and used by the QA’s themselves. 
A lot of upskilling and learnings are owed to these frameworks because simply working with them covered most if not all aspects of the tools our developers use through a typical release cycle:  
Jenkins pipelines, Git, SonarQube, Artifactory, Docker etc. 

Some of these ideas really worked well but it was super difficult to maintain and keep momentum. So, finding a learning/fun and productive balance is still difficult.  
A lot of ideas still get thrown around and even when at times the leads decide on the ultimate direction, everyone still has their piece of contribution towards it.  

I believe once everyone decides or agrees on a path, it becomes easy/easier from there. Even if things don’t pan out well, there is no blame involved. 

Denisha 

A big step was to change the mindset of the ‘traditional tester’. Traditional testers feel restricted to certain technologies or tools and have a fear of getting involved in the developer world.  

An example would be a static analysis tool such as SonarQube, which is predominantly used by developers to measure code quality. As testers, we began to apply this tool in our automation code. It was a stepping–stone into empowering them to start thinking and working like developers. 

We also needed to revisit the basics of Git and apply coding standards to our automation scripts. Here we introduced a code review platform that enabled us to keep a close eye out on each other’s code commits and recommend best practices. 
It’s important to mention, it was not all smooth sailing. Initially we disliked this code review platform a lot! But with time and patience, we slowly started to understand the value. Producing good clean code became second nature. 

Now we love it and can’t imagine doing code reviews without it! 

Lastly, we needed to adopt the DevOps culture and integrate our automation pipelines as part our developers’ continuous integration. This was our biggest accomplishment. Not in a million years did we ever imagine their code would depend on our code during deployment. It may sound exaggerated, but it’s truly how we feel. 

3. What technologies did you implement at the end of the day? 

Mike 

Apart from the frameworks the QA’s created, one main key was revamping how we documented and collaborated through XWiki.  
It may have been intentional or coincidence that we introduced it at the same time the whole company was going through a transformation, because our previous documentation collaboration platforms have not been successful at all. 
Then there was the decision to switch to a single communication platform, in this case Teams. 

These were instrumental in ensuring our communication and collaboration was as efficient as possible. Just using these tools made quite an impact in bridging silos across departments, team members, teams and the company. QA’s probably now have the busiest and most active channels in Teams. 

Denisha 

We implemented new frameworks for Web, Mobile and API testing. These were built using the latest automation technologies and best practices in the international market.  

The new XWiki platform allowed us to document more efficiently and more religiously. It evolved into our go-to place for anything we need in the QA space. 

We produced fully scripted pipelines for continuous integration. We are now on par with our developers in this area. 

4. Anything else you want to mention?  

Mike 

Same thing as always. We’ll just keep moving forward. Learn, improve, repeat. 

Denisha 

During this journey, I learnt that it takes time and a lot of mistakes before you build a successful team. It’s important to give employees the attention they deserve to become better at their jobs.  

I truly believe this would have been impossible without support from upper management, and the open-minded culture we have at Global Kinetic. 

---