Written by Jeff Hughes with Petr Vlasek
It’s 2020 and the shift-left testing battleground is heating up, again. Vendors that claim to have shift-left testing capabilities may be falling short and here’s why. To be truly agile and shift left your teams of developers and testers need independence.
First, they need independence from external services and systems that may delay their testing. Service Virtualization (SV) provides that first level of independence needed to test components that are unavailable or too costly to regularly access. Service Virtualization is a game changer and any company that is serious about achieving Continuous Testing has implemented an SV solution. There are a number of companies that provide Service Virtualization including Broadcom, Micro Focus, Parasoft, SmartBear…to name a few. But, there’s another level of independence needed in order to really shift-left your testing.
Removing the testing bottleneck
Shift-left testing also lies in achieving independence from a single group of stakeholders that could be a bottleneck to achieving your goal of creating better software, faster. For example, you may have a small group of developers who are experts in using Service Virtualization. But, maybe they are the only ones that possess the skills to create and implement virtual services for the testing of your applications. If a virtual service does not meet the testing team’s needs for a particular test, then it must be modified or one must be created from scratch. This means more delays in testing, especially if the testers have to wait for someone on the SV team to create or modify the virtual service.
While SV tools are a lifesaver, they need to be used by a larger audience so that testing can progress unimpeded. Without this next critical element of sharing virtual services, you’re really not able to achieve true shift-left testing. If only part of your team knows how to use a tool, then the other part of the team is left waiting to finish their work.
Shift Left Tools That Everyone Can Use
What if the capability of service virtualization could be broadened to include a larger group of users? What if the creation, modification and maintenance of virtual services could be made available to testers and developers alike? And what if the tool could be adapted to the tester or developer based on their skillset and comfort level and be accessed from the cloud? Bridging the usability gap between testers and developers is the key to enabling the entire team to develop, test and release software on your terms. So, what does a true shift-left service virtualization solution entail?
BlazeMeter Continuous Testing (CT) was designed to allow your broader testing and development teams to take part in the testing process. Having access to the right tools, data and virtual services is vital. For example, one key component of this solution is the use of the Model Archive (.mar) file found in service virtualization solutions and within the BlazeMeter platform. The .mar file provides the definition for a virtual service and how it should respond to a query. Through BlazeMeter Continuous Testing a developer or tester could spin up a complex virtual service.
Developers can still use in-code tools like Wiremock or CodeSV and push the snippets of code to the BlazeMeter Asset Catalog, which is part of the BlazeMeter CT platform. Testers and developers can also define virtual services via import of specs like Swagger, .har files or via a traditional recording. The result is that everyone is happy – developers can still keep using their in-code tools and testers can use whatever API to test with and both can contribute together on the same set of virtual services.
Developers can also control virtual services from IDEs (Eclipse, IntelliJ and the upcoming MS Visual Studio) via plug-ins – that helps them to stay focused on their work, but manage virtual services as needed by their development and testing needs.
There is no need to wait for anybody from your CoE to provision a virtual service. A developer or tester can go and pick which virtual service they need. This is another aspect to the second level of independence and true shift-left – developers and testers can freely (and anytime) use virtual services created, even by the CoE – there is no need to wait for some project life cycle stage where your CoE gets involved and finally focuses attention to the project needs. If a virtual service is in the asset catalog, the team is no longer dependent on the other group.
We created the Asset Catalog of virtual services to help teams quickly identify what assets are available and provision them easily when needed. The Asset Catalog enables collaboration and the ability to choose to run a test using code or as a Mock (virtual) Service from BlazeMeter. A developer can continue to develop virtual assets using code. A tester can create virtual assets using the BlazeMeter interface. We connect the “localhost world” of developers and their IDEs with the “cloud world” where the same virtual assets can be hosted on provisioned endpoints and consumed by other teams. The result is no more isolated islands of uses.
The ability to do tests in code is a prerequisite for shift-left testing, but to bring shift-left into real life and achieve that second level of independence, you have to have flexibility and collaboration capabilities so teams can quickly (as well as gradually) adapt the shift-left model into their daily jobs.
True Shift-Left Testing
Shift-left testing means testing earlier and more often during the SDLC. Having a service virtualization solution is certainly a prerequisite to shifting left and a good start towards continuous testing. But, if your testing team is hampered by a limited ability to modify or create virtual services, then your continuous testing efforts may come up short. BlazeMeter Continuous Testing is the only open platform that allows you to share virtual service across testers and developers where both teams can build these services with the tools that they are comfortable using.
If you’re looking for better collaboration and utilization of your testing resources, then BlazeMeter CT is the answer. We bridge the gap between testers and developers to help you achieve true shift-left continuous testing.
For more information and to start testing please visit BlazeMeter.com
Jeff Hughes is a product marketing engineer for Broadcom. He has over 20 years experience in technology marketing with emphasis on testing, application development, security, Cloud and network technologies. Jeff joined CA/Broadcom in May, 2015 and provides marketing support for Test Data Manager and Service Virtualization. He is the author or 11 books on technology and marketing along with numerous ebooks and white papers. He has been a speaker at global conferences and trade shows and has been a regular presenter at CAWorld for the past three years.