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

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. 


Episode 3: A QA Odyssey – Rebuilding

Episode 3: Rebuilding

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. If you have missed these, click here to go to the first episode.

Changing culture is hard. In order to face the stigma that most software companies experience; the ‘tester vs developer’ mentality, we had to start evolving our processes such that it demanded more collaboration between a tester and developer.
We had to plan, ensure everyone has the correct technical skills, support everyone’s journey and finally, measure what we have put in place.

1. Coming up with a plan

When embarking on a modern DevOps strategy, the most difficult part of Digital Transformation will be changing the culture. There were two pre-requisites before our transformation could begin:

Our transformation was not meant to weed out or replace existing staff, but rather to provide guidance, training and growth in acquiring the necessary skills and knowledge to grow everyone with the direction of the company.

1.1 Eradicating the blame game

Our DevOps cultural transformation was pivotal in allowing our QA transformation. Essential to the success was to take the whole team on the journey, and to find which individuals needed more help than others. We ensured that the teams had the power to be involved in the process and to change things. Empowering and listening to individuals is paramount in transformation.

1.2 Taking everyone on the journey

Once the team had all their cards on the table and understood the need for change, skepticism starting to disappear, and the focus shifted to improving the positives and cultivating that mindset. Working together to discuss the more negative issues afflicting the team and the business was also essential.

1.3 Research and creating new direction, finding the right champion

Identifying key individuals and champions, who understood both software development as well as the role of the Software Development Engineer in Test (SDET) was essential to our success. In our case, this happened to be two complementary individuals.

We studied the history and future of QAs and learnt about SDETs and modern trends affecting QAs and test automation. We re-evaluated what and who exactly we needed to align with, and made tiny changes to what our QA people were working on; slowly moving them into automation.

2. Developing technical skills

The goal was to develop manual testers into automation testers. The QA field has evolved tremendously in the past few years and the need for automated tests and solutions has risen significantly. Global Kinetic recognized the need to keep up with these demands and to do this, we focused on developing our existing testers into a more technical role.
We also refined our recruitment process to introduce more technical entry criteria such as technical assessments and technical interviews. It slowly started to become easier as months passed because we had our goals defined. Our goal was to train manual testers into roles where they could produce automation tests within each sprint going forward. Consistency in our training sessions was essential to success.

Test automation only succeeds with an investment in a technically competent test team, and an acknowledgment that the world of the tester has changed so dramatically.
At Global Kinetic we realized that to succeed in our drive for test automation in continuous integration, training and development of our testing team was of high priority. We already had test automation in place, but our testers were struggling to keep the tests modular, easy to write, and easy to maintain. Most projects that were implementing the automation were not following the same best practices, coding standards and had not yet implemented continuous integration.

We identified that there was one main theme in this path to success, and this was ‘consistency’.
In addition, testers were in a comfort-zone of resorting to manual testing when their automation broke or needed maintenance. They did not have adequate coding skills and understanding of test methodologies and best practices; and scripting tests became mundane and not something that was adding value to the project.

We started standardizing a few things in the technical areas such as building brand new test frameworks in Java. This way our training initiatives would be focused on one specific framework and one language. Having this consistency allowed us to better structure our training lessons and become more practical.
We also implemented a Code review platform that allowed us to review every code change based on the standards and best practices we would learn in our tech/training sessions.
At around the same time, Global Kinetic rolled out a DevOps audit and metric tracking process that included items for the QA team to achieve. This strategy helped drive the team towards the goal of implementing test automation frameworks in their projects.

QA Custodians

The quality mindset in the project teams was starting to fall in place, but we still had some work to do within the QA team. We needed the testers to start becoming more aware of software testing trends, do more research and development into new tools and share this knowledge with each other. In a nutshell, we wanted them to become more accountable for their own career growth and enjoy what they do.

One way we achieved this was to elect a custodian for each stream in the software testing field. Some examples of these streams were “Performance Testing,” “Innovations and Trends” and “Security Testing”. Every week, one custodian would be randomly selected to present a topic on their stream.
This was extremely beneficial to everyone in the team and as soon as the word got out, even Mark Stares one of our senior developers was asked to present a tech session on how developers approach unit testing.

Besides learning about new trends and tools, the QA team started to gel as a unit, and presenting became second nature to them. They became more eager to learn and to share.
As much as this is our tried and proven recipe, there is still a lot to improve and learn from. But we are proud of how far we have come with shifting to a quality-driven mindset and collaborating more.

3. Measuring

3.1 Using QA Retros to QA your QA

Global Kinetic has a retrospective at the end of each sprint cycle where we evaluate what went wrong, what went well and discuss what they can improve.
As much as this was useful in each project, we realized that we needed a separate one for the QA Team. We needed to collate the experiences that each QA had in their project teams, across all the projects running concurrently. In our retro sessions, we discuss the challenges faced as QAs working in our respective teams, getting out automation in time, dealing with blockers such as environmental issues and talking about improving our soft skills when interacting with developers.

Our aim of these sessions was not only to discuss these areas, but also to enable a safe space where they can voice concerns and fears, and to bounce their thoughts or opinions of each other. What is rewarding about this time is that we started to notice each person become more confident, constructively vocal, and empowered to push the level of quality to new heights.
We overcame people conflicts in several ways, partly through making time to discuss issues during our tech sessions but also via TeamFirst, which we used not only for our retrospective meetings, but to also help us with early detection of conflicting behaviors between individual team members. Our Head of People would then be able to intervene or assist us with giving a heads-up to resolve issues before any implosions occur.

3.2 Create a Process-driven mindset

Besides measuring our journey in retros, we introduced an additional ceremony within our sprint cycles, we work through the backlog items on the sprint and discuss together with a team (Developers, Testers, BAs and PMs), all the possible test scenarios and determines which of those can be unit tested, integration tested or end-to-end tested. The idea of this ‘Test Coverage’ session is to get the team to think about the Test Pyramid approach before they start work on a feature. The aim of these sessions is:

What we noticed is that teams are understanding the value of testing, specifically unit testing. Most importantly, the developers and testers are working together towards improving the quality of their product.

Finally

In our next and final episode, we will be sharing tips tricks and recommendations that enabled us to do a successful transformation of our QA competency.

A QA Odyssey: Our team's digital and cultural transformation

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.

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.

WHAT IS A TESTATHON?

A Testathon is like a hackathon but for testers.

 

TESTATHON Cape Town

 

FRIDAY JUNE 24 the Global Kinetic Team got together WITH SOME OF THE WORLD’S TOP TECH TEAMS at the Testathon CAPE TOWN, SOUTH AFRICA and had a chance to work with THREE AMAZING APPS.

testathon-three-apps

Although not much more can be said about these three apps, the team's comments about the day, and the experience kind-of speaks out loud...

Here's what some of our team had to say....

 

Sandisiwe ~ I learned the importance of testing and testers, and the team work amongst the testers. Also learned how other testers approach to testing, and the different ways they test apps.
 

 

Hannes ~ It was a wonderful opportunity to work with the best QA's in Cape Town, sharing experiences and knowledge while having an awesome time. Will definitely go again!
 

Babalwa ~ The experience was completely awesome. Being in the same room with so many testers, of different levels of knowledge and experience, from all over Cape Town and even Johannesburg,  was eye opening and inspiring.

 

This event was created with the aim of connecting the testing community whilst learning from each other and enjoying what the testing community do best.

 
For those new to TESTATHON, or for those who missed out on this event here is a bit of what you missed:
 
 
  • Opportunity to NETWORK WITH THE BEST - Only the top 50 testers in a room. Never a more powerful networking opportunity.
  • MEET WORLD LEADING QA TEAMS - A great opportunity to hear how QA teams behind the world's leading apps work, experience a behind the scenes exclusive Q&A session.
  • LEARN HOW OTHERS TEST - A debrief held after each testing session, so attendees could learn how other's test.
Testathon Working
 
There were even prizes to be won, DEVICES, CONFERENCE TICKETS, CASH PRIZES AND MORE...
 
 
Some of the PRIZE CATEGORIES offered:
    • Team Prizes

 

    • Best QA

 

    • Best Security Bug

 

    • Best UI Bug

 

    • Best Quality Bug Report

 

  • plus 7 others
WANT TO ATTEND A TESTATHON?

Here is the world-tour-list: http://testathon.co/#world-tour-list

Nothing happening in your Country...?  Well If you’d like to have a Testathon in your city / country let the TESTATHON Team know where you are, and about any useful information in your location by going here: http://testathon.co/mycity/

HAPPY TESTING and See you at the NEXT event...!

Original content: https://testathon.co/ and https://www.facebook.com/testathons/ 

Global Kinetic - Contact us via our corporate website and let us bring your application to life: https://www.globalkinetic.com