Testing Web Apps and API's

Editor's Notes

• #2: ------------ Introduction ---------- Main point: Greeting and credentials. Goals: positive feeling, personal connection ---------- Hi, I’m Aaron Evans. I've been testing software for about 15 years. Except for that period where I quit and moved to Fiji and ended up sailing around the South Pacific. I have my own test consulting company "One Shore" and “fijiaaron” is my twitter handle and blog name which stems from those days. My specialty is test automation with open source tools. I’ve worked for both small startups and large enterprises and just about everything in between. I am excited to share how I do testing and would love to hear your feedback.
• #3: ------------ Synopsis ------------ Main point: First a discussion, then a demonstration Goal: participants understand what to expect ------------ I’m going to talk about testing web applications. Specifically, I’m going to talk about testing “modern” web applications with reactive and responsive user interfaces communicating with RESTful web services. We’ll talk about the challenges and benefits of these “modern” apps and then dive in and explore testing a real live application via the browser interface and then the HTTP API. And then we will talk about the benefits of testing at each level. ------------ APPs and APIs ------------ Main point: What I mean by "web app" and "web API" Goal: participants understand what I mean by "app" and "API" ------------
• #4: ------------ Modern vs Traditional ------------ Main point: Modern web application are different than traditional applications Goal: Get participants thinking about their own experience with testing modern web apps ------------ What are the differences between “modern” web applications and more traditional applications? What are the challenges we face testing modern web apps? What can we do to make it easier?
• #5: ------------ Characteristics of modern web applications ------------ Main Point: Modern web applications have additional complexity which makes testing more challenging. Goal: understand what I mean by modern web applications ------------ Responsive layout - the presentation adapts to the display size and characteristics, whether on a laptop, tablet, or phone. Reactive user interface - client side rendering, DOM manipulation, AJAX calls,
• #6: ------------ Testing Challenges ------------ Main point: Testing modern web applications is challenging Goal: participants are thinking about the complexity of testing modern web apps ------------ What challenges do we face testing…the user interface? web services? back end data sources? integration with external services? cloud deployments? ------------ Challenges ------------ Main point: We need to test the UI, the back end services, and the architecture / deployment Goal: participants have a sense of the complexity of testing modern apps ------------ Traditionally, web applications have been tested via the browser. Testers manually click around following scripts to verify functionality or exploring the app, trying to “break” it. And automation scripts, using tools such as Selenium or QTP exercised the application to perform functional regression testing. We still need to test the user interface, but we also have these separate entities -- these web services that act independently. But they don’t have a user interface to interact with. You need to drop down to a lower level and test them at the protocol layer -- HTTP. And because apps are deployed as a series of independent components - a web UI that is primarily client-side (but needs to be served from somewhere). All the associated libraries and assets (javascript, css, images) -- which might be served from a CDN somewhere completely beyond our control -- and then all the services that our app communicates with, and the data sources and services they communicate with -- ok, take a deep breath. My point is that there is too much to test at too many layers. And let's not forget the greater concern for security, greater need for scalability, faster agile development processes and need for better adaptability to change...
• #7: --------- Solutions --------- But, there is some good news. Or at least it’s not all bad. You’ve heard of companies deploying multiple times per day, and not breaking anything. Or at least being able to roll back quickly with minimal user impact. Are these just myth? ------------ Solutions ------------ Main point: separation of concerns can make testing easier Goal: participants are hopeful about testing ------------ Because our app is separated into individual components, it can be easier to test the UI independently. We can also test functionality independent of the user interface, eliminating all sorts of problems including false positives from flaky UI tests and crashing browsers. API tests can run much faster than browser based tests. It does take some additional technical knowhow to understand HTTP but luckily there are tools that make working with APIs relatively easy. With help from DevOps and some continuous integration we can
• #8: --------- UI Testing ---------- We still need to test the user interface. But we can’t rely on it as the primary test mechanism. It’s too slow, too brittle, and too diverse to be able to test every state, on every device configuration. We will concentrate on using the browser to do end-to-end tests, verifying user experience, business requirements, and visual testing. We will use the same familiar UI testing tools. In this case, Selenium / Webdriver and
• #9: --------- UI Testing ---------- We still need to test the user interface. But we can’t rely on it as the primary test mechanism. It’s too slow, too brittle, and too diverse to be able to test every state, on every device configuration. We will concentrate on using the browser to do end-to-end tests, verifying user experience, business requirements, and visual testing. We will use the same familiar UI testing tools. In this case, Selenium / Webdriver and
• #10: --------- The Back End --------- Luckily, there are tools available that help to make it fairly easy. And for consistency’s sake, with a little thought (and some good program design) we can write our API tests and UI tests in a way that many features can be tested interchangably using either the browser or by calling the API directly.
• #11: -------- Testing Web APIs --------- We can use the APIs to verify the bulk of functionality. Calling APIs is faster, more reliable, and easier than browser automation. But it does require a higher level of technical acumen -- you need to understand the HTTP protocol and how your app works at that level to be able to test your APIs directly. Luckily, there are tools available that help to make it fairly easy. And for consistency’s sake, with a little thought (and some good program design) we can write our API tests and UI tests in a way that many features can be tested interchangably using either the browser or by calling the API directly.