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:

• Identify the right champion with strong technical foundations and good people skills,
• Communicate efficiently and consistently. It was important to ensure the right message was relayed to everyone to align and anticipate changes.

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:

• To give the entire team insight into how each functionality is being tested on the different levels,
• Understand the effort that goes into adding test coverage, allowing us to plan better for our sprints,
• Avoid duplication of code on the various levels and reduce unnecessary effort,
• Detect bugs and blockers early in the development lifecycle and improve quality
  Enabling testers and developers to collaborate more.

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.