Shifting Testing in Agile Teams to the Left
Shifting Testing to the Left for Fast and Efficient Deliveries
Do you work on an Agile team? Do you have a quality engineer or developers on your team who test?
If you’ve worked on an Agile team, you know it can be easy for team members to fall into the trap of leaving testing to the last day or two of a sprint. This could happen for a variety of reasons, some of them being, “Our development environment is always down so I never have time during the day to test the functional changes” or “Code is pushed to the QA or Dev regions on the last one or two days of a sprint which does not give quality engineers sufficient time to test.” I came across both experiences during the six years I was a quality engineer. I once worked on a team where the QA or Dev environment would be down for the entire day and we would not be able to test any of the code deployed. These experiences lead me to a simple solution: Run your tests against the locally hosted environment initially, before any code is deployed to the QA or dev environment!
There are many aspects of testing to consider, and they apply whether you’re just starting your Agile journey or if your company’s Agile practice is already matured. In my almost six years of quality engineering experience I’ve come across four main points that your Agile team should consider when developing a testing strategy:
- Design the scenarios early.
- Review scenarios with the team.
- Write the test automation early.
- Involve the whole team in the testing of all of the scenarios.
Let’s break them down one by one.
Design the Scenarios Early
If we shift our mindset to designing scenarios early, we are able to identify all pertinent use cases for the end user earlier as well. Designing the scenarios early for each story is crucial to successful delivery. One suggestion is to design the test scenarios as soon as you plan what stories you will be bringing into the sprint.
Review Scenarios With the Team
Book the test case design time on everyone’s calendar within a reasonable timeframe of when you believe the test case scenarios will be completed. After reviewing the scenarios during your team meeting, add or modify any of the existing scenarios as needed. Wala! You are done with the first task. Mark it as closed and burn down those hours!
Why review scenarios with the team? Well, we want to ensure the whole team is on board with how we are validating the quality of the product. Also, the review sessions bring up edge cases or scenarios that a quality engineer may have not thought of, which improves the overall test coverage for each individual story. Ultimately, it is the team’s responsibility to deliver a high quality product to the market so having team involvement in this process is crucial. When I started inviting all my team members to the test scenario reviews, I was able to get the perspectives of both frontend as well as backend developers, tech leads, product owners, and sometimes scrum masters. When I involved the whole team I gained a broader understanding of the overall technical architecture for the product we were building and a better understanding of how to test it while it was being built.
Write the Test Automation Early
Writing the test automation early is also crucial, especially if you have multiple stories and your team has not matured in the frameworks you are using for testing. If you have a quality engineer on your team, they should be fully aware that sometimes stories will be delivered on the last one or two days of your sprint. In the modern agile workplace, it is common to have multiple developers to one tester (i.e: five developers and one tester per team.) In most cases, the quality engineers feel a greater responsibility to test multiple stories in the span of two to three days. How can we best alleviate the pressure of writing test automation so the whole team can deliver a story on time?
Here comes the one-two punch, ready? Get the repos built locally for each code base that will be delivered! Confused as to what I mean about getting the repos built locally? Well, let me break down this process for you:
- Write out the test scenarios within your framework that will need to be covered during the feature delivery phase of each project. If you have a framework already on your team, some of these steps will already be covered within the project.
- Do you have a user interface that is exposed to your customer? If the answer is yes, my suggestion is to build this environment locally. Chances are, a teammate of yours is actively working on the suggested repository. Pull down the code they are working on and get to work!
- Build the UI locally. On the project I’m currently working on, this can be done through a simple npm install and npm start. If you’re not using npm, just follow the README.md to build the UI repo for your specific team.
- Once the UI is being hosted on your local port/URL, point the URL of the test environment you are currently using and change the URL to your locally hosted development environment.
For the example below I will be referring to a specific scenario that a quality engineer would develop based on a personal website I’m building:
Given I navigate to the test excellence page
When I select on the Chapters link
Then I should see the Chapters page
And I verify the content of the Chapters page
Screenshots of process below:
5. If you see the window shown above, you can see that it’s pointing to my locally hosted region and now the only part left is to start running the tests!
6. During this first test I am selecting the Chapter Contents section and then validating the contents of the Chapters page. In order to eliminate flakiness in our tests we will need to add unique selectors for important elements within our web pages.
7. When I inspect the page, I should see at least one unique selector for each element that I would like to select on the page.
8. In this example I have added a unique selector for the Chapters navigation link. Screenshot of unique selector for Chapters content below:
With this approach, there is no limitation with starting test automation as early as possible in the development cycle.
Involve the Whole Team
In order to reach the highest levels of quality that our customers expect for our applications, we will need to train our entire teams on our testing practices. I would encourage that you host team workshops so the other developers on your team can understand the best practices for quality assurance. Additionally, point them to resources such as Test Automation University by Applitools for additional educational resources. Once training has been given to all of the developers, encourage each one of them to take up a new testing a story that they haven’t developed for each sprint. This process will allow for team members to adopt quality engineering practices and become advocates for high quality standards within their own organization!
Are You Ready to Shift Left?
By keeping these practices in parallel, you can limit the amount of tech debt that could potentially arise when submitting a pull request for any of the work done. Foremost, this approach also eliminates the need to be reliant on test environments such as Dev and QA. Not only are we shifting testing left with our quality engineers, but all team members will become responsible for executing tests sooner in the development process. If you have any additional questions, feel free to contact me at the links provided below:
LinkedIn: https://www.linkedin.com/in/evan-wiley
Twitter: @testexcellence
DISCLOSURE STATEMENT: © 2019 Capital One. Opinions are those of the individual author. Unless noted otherwise in this post, Capital One is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners.
