Downloaded 13 times
Uploaded byBas Dijkstra
Deploy and Destroy Complete Test Environments
The document discusses the deployment and management of complete test environments through service virtualization, containers, and cloud technologies. It highlights key challenges such as limited test data and access issues, while advocating for virtualized test environments that enhance continuous testing and delivery. Various tools and case studies are mentioned, emphasizing the importance of scalable and on-demand test environments in improving the testing process.
More Related Content
Similar to Deploy and Destroy Complete Test Environments
Deploy and Destroy Complete Test Environments
- 1. Deploy and DestroyComplete Test Environments Service Virtualization, Containers and Cloud Bas Dijkstra bas@ontestautomation.com www.ontestautomation.com @_basdijkstra
- 2.
- 3.
- 4. Test environment impediments Systemunder test Mainframe SaaS dependency Backend system Mobile app No suitable test data Limited access Under development Access fees
- 5. The T-shaped tester:What about the T-shaped test environment? Under control 100% availability Scalable Realistic performance Suitable test data
- 6. Service virtualization System undertest Virtualized mainframe Virtualized SaaS dependency Virtualized backend system Virtualized mobile app Unrestricted access Unrestricted access Unrestricted access Unrestricted access
- 7. Service virtualization _Simulation ofdependency behavior _Oblivious to dependency implementation _Virtual assets
- 8. Virtual asset creation _Recordand playback _Based on specifications
- 9. Implementation considerations _Start small _Modeljust enough _Learn and expand
- 10. Testing process benefits _Testearlier _Test more often _Test more
- 11. Taking service virtualization tothe next level _Continuous Delivery integration _Containerization _Cloud
- 12. Test environments ondemand _Recreate exact same initial situation every time _Always available _Scalable
- 13. Test environments ondemand Build server commit Provision virtual test environment Deploy application under test Run tests
- 14. Server hardware Host operatingsystem Docker engine Bins / libs Bins / libs App CApp BApp A
- 15. Example: Hoverfly (SpectoLabs) _HTTP(S)only _Light-weight and open source _http://hoverfly.io
- 17. Example: Parasoft Virtualize _Supportfor many message types and protocols _Commercially licensed _Environment Manager _http://www.parasoft.com/virtualize
- 18. Virtualize + VSTS+ Azure commit Parasoft Environment Manager Simulated test environment Application under test AUT Parasoft SV Azure cloud VM Host OS Server On-demand test environment in the cloud
- 19. Organizational decisions $ $$$ $$ $ $ $ $ $ $ $$ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
- 20. Infrastructure OR On premise Inthe cloud
- 21.
- 22.
- 23. Example SV maturityjourney
- 24. Case study: education InfrastructureKnowledge Development
- 25. Case study: financialservices Infrastructure Knowledge Development
- 26. _ Email: bas@ontestautomation.com _Blog: http://www.ontestautomation.com _ LinkedIn: https://www.linkedin.com/in/basdijkstra _ Twitter: @_basdijkstra
Editor's Notes
- #3 Everybody is doing some sort of CD, or at least is looking into it
- #4 CD requires the ability to test continuously, every deployment should be thoroughly tested before being put into a production environment Test automation plays a big role in this
- #5 The ability to test continuously is often hard to achieve because of test environment impediments
- #6 The T-shaped tester is a sought after profile at the moment, very good in one thing (testing, automation) and skilled in myriad other things (analysis, development, …) Continuous Testing requires something similar: a T-shaped test environment. First and foremost it should be under total control of the team using it, but next to that it should have other characteristics as well..
- #7 One approach to enable Continuous Testing is through implementation of service virtualization, an approach that removes bottlenecks in test environments by virtualizing dependencies that are critical to the testing process yet hard-to-access
- #8 Characteristics of service virtualization
- #9 R&P: draw parallel to test automation: nice to get a first demo up and running (or analyse traffic where no specifications are known), but to achieve long term success it’s best not to rely on R&P too much. Instead, create virtual assets using request-response specifications. R&P also only simulated those situations that CAN be recorded.
- #10 How should you go about SV implementation? Start small, both in terms of number of dependencies simulated and behavior replicated. Model just enough to enable execution of desired test cases (all else is filler, remember that SV is an enabler for testing, not a goal in itself). Learn and expand.
- #11 So how does the testing process ultimately benefit from SV implementation?
- #12 So, we have seen that implementing SV can lead to great benefits for the testing process, but to make SV even more flexible and better integrated into the CD process, wouldn’t it be nice if we could treat our test environment in the same manner as our application under test?
- #13 By containerizing and distributing SV engines and their virtual assets, we can do…
- #14 So, what does an approach like this look like? Talk them through the picture. Build server also runs tests (unit tests), we’re talking about integration and end-to-end tests here.
- #15 Guarantees that an application will always run in exactly the same way, regardless of the environment it’s running in. This is what you want from your test environment as well.
- #16 Hoverfly, mostly focuses on record and playback functions by acting as a proxy, recorded traffic can be extended and customized programmatically Also supports latency simulation for more realistic performance testing
- #18 Tell a little about Virtualize as a tool Both EM and Virtualize engine can be deployed directly from Azure, EM can then provision simulated test environments on the fly
- #19 Talk them through the picture, focus also on repeatabiity
- #20 So we’ve decided that SV might be the way to go, but what decisions do we need to make? And of course money does play a role…
- #21 Where do I host the SV server / the virtual test environments?
- #22 Who is made responsible for developing and maintaining the virtual assets?
- #23 Is virtual asset development done in house (requires SV expertise, which, although it isn’t rocket science, might be hard to come by) or is it outsourced to a third party? Much like regular software development
- #24 What could an example maturity journey look like? From single server, developed and maintained in one or more teams (small scale) to cloud hosted (flexible, scalable) developed by a center of excellence (less overhead, less fragmentation, one way of working)
- #25 Studielink
- #26 ING