Introducing Shift Left Testing – Is It That Different Than BDD?
You have heard about Behavior Driven Development (BDD) and maybe even practiced it in one way or another. Now, there is a new concept called Shift Left testing and you aren’t quite sure what is it but it seems similar to BDD. So actually what is Shift Left testing? Is there a Shift Right testing approach? How do you practice Shift Left approach? No worries, this article explains all you need to know about this concept.
Early engagement of Quality engineers
Shift left as a concept started first in security testing as a testing approach which was supposed to provide early feedback about any vulnerabilities in software. It was of paramount importance for security teams to know early about possible issues that could be exploited during attacks. Therefore, an approach was agreed upon where control mechanisms must be implemented to ensure that vulnerabilities were discovered. From developers side, it was crucial to write testable code, implement unit test strategy which would catch any regression issues. But, also from the quality engineers side something had to be done. Contrary to the widespread model of quality control where testing starts when development is over, in Shift Left QA engineer’s engagement start at the design phase.
Quality Assurance in Design phase
The design phase in widespread model consists of creating documentation for the development start. Usually only business side team members, UI/UX designers and architects or developers are included in this stage. With Shift left approach we introduce also QA engineers in this stage. This will make sure that quality is embedded in the development from the start. We should provide our feedback on the business documentation. We should challenge the design or UX, the functionality of the software, etc. Quality engineer must also review the technical implementation in this phase. His assignment must be advocating for the best test automation strategy. What type of test strategy should be used: TDD or post development unit testing? Is integration testing required? In this stage QA engineer must share with developers how he would test the functionality. Based on this input the developers should write testable code.
Shift left testing in Development stage
The previous phase with implemented Shift left approach resembles the BDD the most. BDD also requires close collaboration between developers, business oriented team members and quality engineers. They all meet to ensure the common understanding of everything that needs to be done. However, in reality quite often after these meetings all three sides continue to work in silos. With Shift left they are “forced” to work together and collaborate throughout the development cycle. Changes should be pushed often and every change that could be tested in UI must be tested as soon as possible. Pair testing with developer my be of great help during Shift left approach. Any defect found in the testing process should be reported to the developers immediately.
Breaking the habit of testing after the development is completed
In widespread SDLC model we test the software after the development is completed. This makes team members work in silos. The developers complete work and move it to testing stage. While the QA engineers test this change, the developers start to work on next task. If we find a bug and create a bug report, put it in backlog we risk that the resolution is postponed. It may take long time for the developer to start working on it. Consequentially the developer must review the code before bug fixing which is time consuming. If the team uses the usual method of pull requests for code review than a day or two might be added before the issue arrives at retesting. Having several cycles of bug finding -> fixing -> code review might significantly slow down the delivery of software. Shift left alleviates all these problems by fostering collaboration between team members.
UI Test automation – BDD vs Shift left
With BDD test automation is quite simplified because all the test scenarios are prepared during the design phase. And the best part of it is that they are prepared by all team members, or at least that is how it should be done. The rest is just writing code that covers all the steps which is the easier part. In Shift left we can also utilize writing of BDD scenarios during the design phase. There is no such thing that would prohibit us to do so. The main difference is in the time frame for writing the tests. With standard use of BDD there is no such requirement that tests should be written in early stages of development. Moreover, most QA engineers would argue that automation tests should be written when the feature is stable. This may lead to test automation being postponed to one of the following sprints.
Is in sprint automation possible?
In Shift left the test automation starts as soon as the design mocks are created. The code is written based on our current knowledge about the functionality we are writing the tests for. We should be aware of the elements on the page: buttons, text fields, drop down elements, tables, etc. to write test. At the beginning we will not be aware of HTML elements we can use but that can easily be added later. If something changes in the requirements the tests must be changed. This is quite often a controversy which sparks additional discussions among QA engineers. Requirements change. The client is allowed to change his mind. The developers live in that world without ever complaining about it, why do we as QA engineers complain? The change in the test should take place at the same time during which the developer is implementing the change in the code.
Downsides of Shift left
Shift left is quite engaging and dynamic type of collaboration. It requires excellent time management for all the individuals in the team. High level of communication skills and team work is also prerequisite for successful implementation. Large teams may find it more difficult to implement because of higher number of correlations between the team members. However, there are ways to overcome that. Team members who are used to work in widespread SDLC model may develop resistance towards it at the beginning. With time they should also become aware of the benefits of Shift left.
Benefits
The benefits of Shift left are numerous. We’ve already seen that the feedback about implemented features is a lot shorter. When we report the issues directly to the developers as soon as we find them, they do not need to review their code before starting to work on the issue. They are acquainted with all the code because they are actively working on it. The group collaborates a lot better. The entire understanding of the business idea behind the software is more clear to everyone. In specific, the entire team understands the problem this software should solve and how is it going to be solved. The quality is in mind of all team members from the start. Tests are strategically planned and executed continuously. The developers and QA engineers worked together of finding all the edge cases for testing ensuring higher coverage against regression issues.
Further enhancements
With Shift left we move the testing to the left side of the SDLC, basically to early stages of development. However, we need to think about maintaining high quality of end product during all stages including the maintenance phase. To complement the Shift left with all the test automation practices in place we need an adequate strategy for testing in late phases of the SDLC. This is covered by Shift right approach about which we will write in a different article.
