Shift left testing in agile – how to implement it successfully?

Have you been part of a team where developers had to wait for a long period of time to get a feedback from QA? It happened to all of us that we notice there are some bottlenecks in our processes which are detrimental to the development process. The answer to this problem could be Shift Left testing. Shift left should provide your team with faster feedback about the feature in development. It should also provide you with better organization of your time as a QA engineer. Keep reading to find out what were the challenges in my team and how to implement shift left testing in quality assurance.

Bottlenecks everywhere you look

I saw the first red flag in our process when I noticed that new bug tickets were piling up in our backlog after each sprint. We were producing more bugs than we were fixing! Second red flag was finding out that developers push the tickets for testing without doing the basic testing. Third problem was, I was the only QA engineer in the team trying to test everything. But I was overwhelmed by the amount of bugs I found after each test. Automation of such features was blocked from the start for obvious reasons. The bugs I reported were put to backlog. Since the team had higher priorities they didn’t fix them right away. The bugs stayed there and the tickets spilled over sprint after sprint. Moreover, even when some bug ticket was solved it would move to code review where it would be stuck for another few days.

Thinking about Shift left testing approach as a potential solution

I did some research on Quality assurance subject and I stumbled upon an article about shift left testing. Immediately I started to think about possible implementations in my team. Of course, I was at first thinking about negative implications during implementation of shift left testing in agile. Possible downsides of it were obvious overhead in the amount of work. It was clear that this approach requires that the whole team works as a well oiled machine. Again I could not be sure that all the developers would be on board with this because a lot of them were accustomed to traditional development process and I sensed there would be some friction on their side. I sat down and created a presentation with a plan to show it to the entire team and hear their thoughts about it.

Shift left testing starts before the development

The presentation went fine. I received some questions and some valid points were raised. So we concurred that this would be a trial and work in progress because we might make mistakes in the process. The idea was to implement the process, review, adapt and repeat. Finally, I had their attention! We agreed on basics and how we will operate. One other thing I agreed with the team was to have discussions on the requirements. These were to take place as soon as the requirements were written. This also complied with shift left because we were able to catch a lot of issues even before the code was written. It saved us some time for rewriting some of the logic.

Shift left requires better time management

I knew I had to test all the tickets in progress as soon as there are some changes committed, prior to code review. To achieve even faster feedback I suggested pair testing sessions with developers on their local machines. Because this way we would be able to catch the bugs right away. This would also allow both developers and me to test our understanding of business logic we need to cover in the code. It was a valuable experience for developers because they would get testing ideas from me. In case they needed to refactor their code because of code review suggestions, they knew how to test it afterwards. I had to organize my schedule to have the test automation in place. I wrote the test automation based on what was known to me at the moment. It was obvious some technical debt would appear which I would pay later.

How to automate your work early?

The most essential part of the shift left implementation is to provide early feedback about latest development. Automated checks are the fastest way to get a feedback. The testing strategy should incorporate as much as possible short tests which can cover the most of this new development. Unit tests should be incorporated as early as possible, possibly before the development starts in TDD fashion. However, end to end testing in UI can also be added early. Many QA engineers would say that test automation starts when the system under test gets stable enough for testing. In shift left approach I wanted to have it as soon as possible. As soon as I was given design mocks for the feature that should be developed I started creating test in Page Object Model style. I knew which buttons, fields and other elements would be added on the page. The only thing I didn’t have at that time were CSS selectors, but I decided to complete everything else and add these later. Adding CSS selectors in the script at the end took just a small fraction of time and I could run the script shortly after all changes on the developer’s side were committed. I was happy as I was able to provide the test at the same day when the development was completed. Test automation didn’t lag behind the development.

Quality is a journey, not a final destination

Contrary to what I was thinking, the entire team was pretty much satisfied with this way of work. The developers enjoyed a lot this early feedback they were getting. They were engaged in bug fixing as soon as I report them any issues. Business analysts also liked the help they were getting from me with pointing out issues in the logic even before the development. I was happy because the backlog items started to get resolved and the amount of new tickets was significantly lowered as you will see in the results section. There was no ticket spillover to subsequent sprints. Everything was solved directly through communication with the developers. I managed to complete all automation test within the same sprint as the feature under test. However, there were still some things to be improved. Early feedback can be also achieved by implementing Test Driven Development (TDD).

Results

In the first three months of implementation new ticket creation was down by 57% according to my statistics. We improved the internal communication within the team and learned to function faster than before. Developers improved their exploratory testing skills. We were all much more confident when it comes to understanding of business logic. Automation tests were added to CI and ready to catch regression issues as soon as the feature became available in testing environment. And the best part of it was that the only thing we changed was the way we collaborate and that is the answer on how to implement shift left testing in agile software development.