Implementing Modern QA: the keys to moving from legacy to Agile
Para acceder a post original click aquí
(This post was written by Eran Vaks, HPE Unified Functional Testing QA Leader)
In the modern QA world, agile development is becoming more and more widespread among traditional large enterprises, and automated testing has already taken over. Testers today are transitioning from software QA to a collaborative, interactive approach. In this approach, testers are quality advocates influencing both operational and development processes, and geared towards preventing defects rather than finding them.
Today’s enterprise QA team is no different. As the Hewlett Packard Enterprise United Functional Testing (UFT) automated testing software team has adapted and integrated into this type of cross-functional and modern role, we’ve had to prepare and plan ahead in order to successfully move to agile development and continuous integration. To do this, we first had to define what we wanted to achieve. Then we implemented our methodologies using automation, transparency and made sure we had close coordination with development. In parallel, we learned how to create the culture change to overcome the challenge of running geographically distributed teams in various locations such as China, Vietnam, Ukraine and Romania. In this article, I will focus on the first steps and challenges we faced, and provide you with a few tips for entering the same agile pace.
Implementation: Moving Towards Agile
One of the ways we achieved this goal of moving towards agile was to implement early feedback and early treatment. Early feedback means getting new release content from developers, and providing quality feedback as quickly as possible. We also want to provide early treatment to validate the fixes and close the content earlier in the lifecycle—to help improve quality and meet customer expectations. This is important so that the content is fresh in the minds of the developer. If this process happens a few weeks/months later, it will take more time to understand what and how to fix what’s needed.
First Step: The Nightly Build
For us, implementing our form of modern QA means using automation and transparency. The first task was to create a pipeline to automate the build and deploy processes of the test environments. We create nightly builds, enabling us to run unit and integration tests quickly and efficiently on the latest version of our applications. With our nightly builds, we ensure that our QA team can come to work in the morning, (instead of wasting time creating an up-to-date environment). The team can focus on and test the latest builds that were created overnight. In addition, developers can make sure that their code is built correctly and that they don’t check in broken code or ‘break’ a QA environment.
The nightly build mechanics and the option to mass deploy dozens of environments for the R&D and QA teams are fairly straightforward. Once we have a stable build, we use a Jenkins server to handle automated builds and integrations. We create jobs that pull the latest code from the main repository, and deploy and run automated acceptance tests on our nightly machine. We then receive a report regarding the build stabilization, and if it passes the automated tests, we are able to execute the mass deployment job.
Our Main Resource: Our People
Moving to Agile is not just about the machines; it’s also about our people. In the past, the developers created a release while QA tested the previous release. Dev was always one sprint ahead. Now we work on the same user story in the same sprint, and QA has to be prepared to work on multiple user stories from A-Z as part of the same sprint.
Our sprint planning involves deciding the user story scope together with rest of the Agile team. We use daily scrum meetings to track our progress, and we’re able to determine what each user story will handle and what type of effort will be involved at every step.
This is illustrated in our Sprint Planning Template below. The template is divided up per day and into two parts: one for Dev and one for QA. The template helps us break down user stories into manageable parts, and helps us track progress by updating the status of those stories. We use the template in every sprint during the sprint planning process, with a separate color for each story, so that it’s easy to track the progress from Dev to QA. For example, the U.S. has the same color (green) for both Dev and QA, and we see here that the U.S. starts development on Monday, finishes development on Wednesday, and starts QA on Thursday.
The Sprint Planning Template
Working with Globally Distributed Teams
A major challenge for us is working with teams that are distributed globally in various geographical locations. We want to have the same user story in the same region, but sometimes QA in one region may have to test something developed in another region. We resolve this by having daily cross-regional ‘Scrum of Scrum’ (SOS) meetings with all regional QA leaders. These meetings are well-designed to handle virtual teams such as ours, and help sync and create alignment among procedures and with all team members.
In addition, to facilitate communications, we use HPE Agile Manager forAgile project management and Kanban to see who is handling which tasks. This helps us naturally drive focus and transparency throughout the development lifecycle and across the different regions.
HPE Agile Manager’s Kanban Task Board
When is it ‘Done’?
One of the major challenges a large R&D organization faces is how to determine what defines ‘done’ for a user story. This of course varies by organization, but for us a “done” definition means that a user story doesn’t have any known high or critical defects.
Once everybody is aligned to that goal, we can determine how we are ‘burning down’ the features that we need to release. Because HPE Agile Manager lets us link every defect that we find to a user story, we have the ability to know the exact status of each user story and can better scope it, determine whether we need more resources, etc.
This process is illustrated in our ‘Sprint burndown’ concept below, which we use in Agile Manager to monitor progress. Here we see the ‘Remaining Effort’ vs. how many days there are in the sprint. As the user stories move toward ‘done’ status, the remaining effort moves down in relation to the number of days. So for example in day 9, we managed to move about half of the user stories to done. Over time, we actually managed to surpass our planned (ideal) effort with our actual (remaining) effort.
Sprint Burndown3 Methods for Reducing the Number of Defects
There are many ways to reduce your number of defects. Here are three practical methods we use to do so are ‘coffee breaks’, Acceptance Tests Plans (ATPs), and sharing test plans to create development accountability.
1. Coffee Breaks
Coffee breaks enable a QA rep and a developer to work together at the developer’s station for around 10 minutes, and go through the main in-development workflows and features. In this way they can align together and set expectations to prevent critical defects from leaking into the main code repository.
2. Acceptance Tests
When we get a new user story, we want to make sure that the quality of the product’s “main path” is good before we start to drill down with test cases. We have about five running ATPs that cover the main scenarios of the new user story, and we use these tests to determine whether each user story results in a ‘pass’ or ‘fail’ outcome. The main paths are tested (for example, user login or registration). When these basic workflows pass, we move to less common ones.
3. Sharing Test Plans
The last tip is to share in advance with development what QA is going to test and validate. This helps prepare the development team, and enables them to check the specific scenarios that QA is going to focus on before these are deployed – thus creating accountability on the developers end for delivering tested and quality code. When a developer knows what QA is going to check, the developer can validate the scenario before committing the change.
It’s not just scrum meetings or automation scripts that will create change for QA today. Large enterprises need dedicated change agents, and the ability to show the end developer and QA the value in moving to Agile or DevOps. An extensive cultural change is needed to drive distributed teams. These changes include:
- Meeting and coaching the different teams involved
- Aligning these teams together in a rapidly-moving environment
- Presenting and getting their acceptance to move forward with the adoption of the new agile culture