Fully Tested: From Design to MVP In 3 Weeks
•Download as PPTX, PDF•
0 likes•293 views
In this presentation Daniel Giordano, Product Marketing Manager at SmartBear, will cover how to speed up your development with a design first mind set, virtualizing services and dependencies to enhance collaboration between developers & testers, & end-to-End testing strategies for an immature product.
Recommended
Recommended
More Related Content
Similar to Fully Tested: From Design to MVP In 3 Weeks
Similar to Fully Tested: From Design to MVP In 3 Weeks (20)
More from SmartBear
More from SmartBear (20)
Recently uploaded
Recently uploaded (20)
Fully Tested: From Design to MVP In 3 Weeks
- 1. Fully Tested: From Design To MVP In 3 Weeks
- 2. Page Proprietary & Confidential We provide tools for development, testing, and operations teams to create great software, faster than ever. AccelerateSDLCWorkflows | ImproveQualityatEveryStage | RealizeRapidTime-to-Value • European HQ in Galway, with 7 offices globally • Founded in 2009 • Open Source Innovator (Swagger & SoapUI) 6.5M+ Users 194 Countries 22K+ Companies TestComplete SoapUI Pro SwaggerHub CrossBrowserTesting QAComplete AlertSite Fully Tested: Design To MVP 2
- 3. Agenda • MVPs & Testing • Definition DrivenDevelopment • The Benefits Of Virtualization • End-to-End Testing Coverage Fully Tested: Design To MVP
- 4. Page Proprietary & Confidential 4 Fully Tested: Design To MVP MVPs and Testing Go Together Like Baking SodaVinegar
- 5. Page Proprietary & Confidential 5 Fully Tested: Design To MVP Innovation’s Most Precious Resource… 12 6 39
- 6. Page Proprietary & Confidential 6 Fully Tested: Design To MVP And So, This Is Our Natural Tendency First Line Of Code $100M ARR Time Spent Developing Time Spent Testing
- 7. Page Proprietary & Confidential 7 Fully Tested: Design To MVP But Sometimes, Ideas Just Happen Whiteboard Session Requirement Doc (Maybe) Primal Function Auxiliary Function 1 Analytics Added Website Launch Auxiliary Function 2 Primary Function 2 Payment Service Start testing now? Maybe now? Probably here?
- 8. Page Proprietary & Confidential 8 Fully Tested: Design To MVP We Should Be Closer To This First Line Of Code $100M ARR Time Spent Developing Time Spent Testing
- 9. Page Proprietary & Confidential 9 Fully Tested: Design To MVP The Benefits of Testing MVPs Software Needs To Be Usable.
- 10. Page Proprietary & Confidential How Can We Test Earlier During The MVP Stage? • Define • Virtualize • Record Fully Tested: Design To MVP
- 11. Page Proprietary & Confidential 11 Fully Tested: Design To MVP Overcoming This Bias With Definition Driven Development • Swagger Tooling Virtualization • Mock it out! End To End Testing • Easy record-and-replay 11 Definition Driven API Development: advocates for designing the API’s contract first before any other lifecycle operations. The OpenAPI Specification (OAS) is the world’s standard for defining RESTful APIs
- 12. Page Proprietary & Confidential 12 Fully Tested: Design To MVP A Common Vocabulary Opens Up A World Of Possibilities The OpenAPI Spec • Machine&humanreadable • Languageagnostic • Powerfultooling Design Document Mock Test Consume
- 13. Page Proprietary & Confidential 13 Fully Tested: Design To MVP An OpenAPI Design Example API Info API Request API Response
- 14. Page Proprietary & Confidential 14 Fully Tested: Design To MVP Fast Prototyping Capabilities /user GETPOST 200200404 Query Parameters Body > UUID 5679123 > First_name > Last_name { “first_name”: “Dan”, “last_name”: “Gio”, “email”: “dgio@gmail.com, “join_date”: “5-1-18” } { “status”: 200 “first_name”: “Derek”, “last_name”: “Zoolander”, “email”: “Dzoo@gmail.com” “join_date”: “12-1-01” } { “status”: 404, “message”: “Bad Request” } { “status”: 200 “first_name”: Dan, “last_name”: Gio, “email”: dgio@gmail.com, “join_date”: “5-1-18” }
- 15. Page Proprietary & Confidential 15 Twitter: @keshinpoint Testing From The Definition The OAS definition allows you togenerate test casesdirectly from the contract ReadyAPI testing Tester Test Test cases Refactored Refactored
- 16. Page Proprietary & Confidential 16 Fully Tested: Design To MVP Service Virtualization: a method to emulate the behavior of specific APIs and web-services in modular-based applications to reduce system dependency. Emulate live APIs Import a Swagger Definition Create Endpoints via a wizard
- 17. Page Proprietary & Confidential 17 Fully Tested: Design To MVP Service Virtualization Benefits Cost Availability Pliability $
- 18. Page Proprietary & Confidential 18 Fully Tested: Design To MVP Can you afford $.02 per API call when building your MVP? You shouldn’t have to.
- 19. Page Proprietary & Confidential 19 Fully Tested: Design To MVP Virtualizing 3rd Party Services
- 20. Page Proprietary & Confidential 20 Fully Tested: Design To MVP Free, Ungated Access To Premium APIs Send Coordinates Send City Name Request Response Request Response Manipulate: • Behavior • Responses • Data
- 21. Page Proprietary & Confidential 21 Fully Tested: Design To MVP Virtualizing A Swagger Spec Design and Document Virtualization • Testers • Developers • Prototypes • Managers • Other Apps • Customers Development Refactor Feedback Import Test
- 22. Page Proprietary & Confidential Switching Gears Fully Tested: Design To MVP
- 23. Page Proprietary & Confidential 23 Fully Tested: Design To MVP Front-End Speed Found viaFrameworks
- 24. Page Proprietary & Confidential 24 Fully Tested: Design To MVP Browser Testing Stay Shallow
- 25. Page Proprietary & Confidential 25 Fully Tested: Design To MVP Introducing Record & Replay
- 26. Page Proprietary & Confidential 26 Fully Tested: Design To MVP Record & Replay • Takes just seconds to walk through and record your manual scenario • Makes you focus on UI/UX • Test multiple layers of your application • Can edit steps to mirror changes made to the UI layer
Editor's Notes
- Maybe you are a developer or a QA on an innovation team, or just a tinkerer in your workspace or home life.
- We’re trying to optimize Time and cost, and we’re talking about testing? MVPs come from teams and individuals that are trying to optimize at all costs. Time, money, resources, processes. Anything and everything is subject to optimization. Except for testing.
- And this is really no different for software that’s made more traditionally maybe not in an “MVP” type environment. But traditional testing usually happens at some point after the first line of code is written. Whether that be the 400th line or 4th major feature to be deployed. TDD and BDD aim to change that, but we’re still not all there yet
- We’ve seen and helped hundreds of start ups in the 1, 5, 10 million dollar ARR range just begin their test automation build out. I’m talking basic unit testing and regression testing. Some of the coolest start-ups and tech firms in the world. But if we can begin the testing process earlier, we’ll find some surprising outcomes for our MVP. the Benefit of TDD and BDD – that drive testing from the beginning of the development process.
- Like production MVPs are designed not only to determine the viability of the product’s value proposition, but also the technical elements of the product. Naturally there is no point in extensively testing a largely unfinished product but there is still a place for user acceptance testing with the MVP model. We’re not trying to perfect out technical ability to execute, but basic actions should be tested and expected to run smoothly Conducting validation testing on the overall platform to verify the expected outcomes and check the usability of the product makes a better product. Although the MVP is not a long-term project it should not be unusable because it is filled with bugs.
- Before a single line of code is written, the magic happens in the markdown of the definition itself. There are some really neat tools for UI development that are allowing designers and developers to work together closer than ever. Tools that can export neat, prettified code based on a drag and drop interface. Heck, Dreamweaver is a decade or 2 old and could almost do that. That is because the presentation layer of the web has standards. They are not always perfect, but W3C and the standardization of HTML and CSS have exponentially increased the productivity of the front-end design and development process.
- The OAS is trying to do the same for APIs. It affects the entire SDLC
- That markdown we were talking about before
- Just like TDD, BDD, and Mocking for the UI, conceptualizing your service via a contract-first methodology has implications at a couple of levels. We can plan all of this out before we start writing code, creating an API blueprint that is organized and thoroughly explored. This method makes us focus on business outcomes and customer outcomes instead of rushing to build out components we may never need. Components Domains Tags
- Speed your testing and increase test coverage with definition driven development as well. By importing the spec into ReadyAPI, you’ll be able to generate test cases and assertions on the fly, with just a few clicks.
- The lorem ipsum of integration and backend testing. Designers need the content to actually bend and place, and the content creators need to see the space that they are given to craft their words. It’s a catch 22. Testing has the same problem. Testers and developers need access to the same things, but that is often impossible. Virtualization allows that workflow to continue, just like lorem ipsum speeds the work between a designer and writer.
- Imagine a popular service inside your company or maybe an expensive API like Stats.com football data API. And getting a free version of it, that not only worked exactly like it, and responded with actual data, but could actually be customized in ways that ordinarily is not easy.
- We can a send a set of coordinates to the Google Maps API, then get back a City Name. Then we’re going to send that City Name to the NFL’s API and ask it for all the active players from that town. These two requests happen to two expensive, closed-access services. With Service Virtualization, we can keep 30% of their API up and running for all sorts of innovation purposes. And this example is very public facing – take this example and apply it to inside of your organization. Are there any highly used, brittle services that you’d like to experiment against? And how about pliability. It’s difficult to test for the server capacity of NFLs API, or to understand how it perform while asking for information while entering a tunnel. But we can manipulate these things with virtualization. Nfl.com/api/v3 becomes localhost.com:8088/api/v3
- All the great benefits of swagger, even more powerful. Virtualize your swagger spec, then inject data via ServiceV, allowing you to stand up a living breathing API with not much more than your API spec and some data, maybe only in an excel file.
- How can we talk about software MVPs and prototyping and not bring up some of these front-end frameworks. These tools are immensely useful to front-end teams that want to build and scale quickly. And you can see parts of these frameworks in Swagger – the ability to reuse components and find a common syntax has sped up development at all layers.
- Doesn’t need to be extensive. But people use several new versions of browsers. How do we make that easier