Let’s talk about testing in a DevOps environment. Right to the slides, we’re going to talk about the various types of testing. The first is unit testing. That’s where we test the parts of the system in isolation. Most developers and Dev shops, you’re all comfortable with the thought of unit tests. Unit tests are the breadth of your tests. We’re going to run them at every build, every time we run this thing. They can run without having to deploy the application out into production, so they tend to be very, very fast. And we’re going to run them constantly. We’re going to have a bulk of these unit tests. As we move up, we’re going to have integration tests.

Now, here, you might not mock out all of the pieces that you’re reaching into. You’re going to talk to the integration of various components of your application. And in the integration testing phase, you’re going to maybe have to deploy the app, because it might need to hit a database or something like that. But we’re going to want to run these integration tests quite often, quite quickly as well, and frequently. One of the things that I want to differentiate is between the concept of integration testing, and acceptance testing, and UI testing. Now, UI testing here is specifically where we’re testing components by driving it through the user interface. This is hard, and maintaining these tests can be very, very difficult.

When you get into this DevOps cadence, one of the things you’re going to see is in order to more rapidly deploy, get more confidence in your application, you’re going to find you’re re-architecting to drive those tests down lower in that chain of tests. You’re not going to drive-through the UI. Instead, you’re going to be driving more, and more, and more of those tests, those business value tests right through the API layer. However, there are cases when the only way you can test is to drive the UI. Go ahead and do so, and put it in that automated pipeline. Next up is load and performance testing. This often gets short shrift.

We tend to defer this off for two or three weeks and run a big load test and a big performance test at that point. I encourage you to pull that sooner. Run those every night. Maybe not every check in, but run them every night. So that you can get fast feedback on anything that might be negatively impacting or positively impacting your performance. Next, we’ve got telemetry. Now, telemetry, I’ve put in it in italics here. Because people often leave it out, but it’s another form of testing.

Instead of scripting tests and creating synthetic transactions against our production environment, telemetry gives us real feedback potentially from the real users who are navigating through our site and gives us an idea of whether or not something’s gone wrong in our system. And we get a quick heads up on that. The last thing we need to talk about is manual and exploratory testing. Now, I’ve broken these apart. Manual tests, you may be looking at manual tests and exploratory tests and thinking they’re the same. This is where we apply human intelligence against the expected behaviour of the app. Exploratory tests are necessary sometimes to go out and find something. Use our mind to discover what the problem is in the app.

However, I’d caution you that, if you find yourself going out and running that same test more than once or twice, you’re continually running the same sort of exploratory test. At that point, it’s probably due to look towards automating that particular test. That allows for a very fast DevOps pipeline end to end, so these are the tests you might plug together to get that fast DevOps pipeline with all of the tests running through continually the areas that you’re going to need to test in your application.