Think Like a Tester

Recently I was meeting with some coworkers who were looking to improve our Continuous Delivery practices. They were thinking of ways to measure our progress with automated testing, and one of the first suggestions was to measure code coverage.

“Nope,” I said. “Measuring code coverage isn’t helpful because it doesn’t indicate whether we have good tests; only that the tests execute certain parts of the code.”

The next suggestion was measuring the lines of test code. “No,” I said. “That won’t help either. Just as the number of pages in a book don’t indicate how good it is, the number of lines of test code won’t indicate how good the tests are.”

“OK,” they said. “How about the number of tests? Surely that would indicate our progress.”

“Nope, that won’t do it either,” I responded. “Because you could have hundreds of tests, and every one of them could be unreliable or testing the wrong things.”

At this point, they asked: “Well, then what DOES indicate a good test?” The answer to that question is the topic of this blog post! Below are six indications that you have a good automated test.

1. It tests something important

It’s possible to create automated tests to do all kinds of things, but you want to make sure that what you are actually testing is worth it. Code of any type requires maintenance, so it’s not a good idea to create tests just for the sake of having them.

Here’s an example of something you might not want to automate: let’s say that when you are testing a new page in your application, you discover that the “Last Name” header is misspelled “Lsat Name”. You log a bug, the developer fixes the issue, and you verify the fix. What are the chances that bug will appear again? Probably fairly low; so it makes no sense to write an automated test to check the spelling.

2. It fails when it should

Test engineers new to automation often forget to check that their automated test fails when it’s supposed to. This happened to me when I first started writing automation in JavaScript. I wrote a test to check an uploaded record and was so happy that it was passing; then my developer asked me to check if it would fail if the record didn’t match. It didn’t fail! It turned out that I didn’t understand promises; I was actually validating that the promise existed rather than validating the value of the web element. Having tests that pass 100% of the time regardless of the circumstances might look good in a test report, but they provide no value whatsoever.

3. It’s reliable

A test should provide accurate information 100% of the time. This level of perfection is probably not attainable, but the creator of the test should strive for this ideal. Flaky tests should be fixed or eliminated. A flaky test cannot provide reliable information: did it fail because there’s a bug present, or because of the flakiness?

4. It’s maintainable

An automated test suite filled with spaghetti code will be an incredible chore to maintain. Every time a change is made to the feature code, the test suite will take hours or days to update. Test code should be clean code that makes sense to read, is well-organized, and doesn’t repeat itself.

5. It runs quickly

An automated regression suite that takes eight hours to run is not going to provide fast feedback to a development team. We want tests that run as quickly as possible to let the team know if there’s a problem. There are a lot of ways to speed up test automation; my favorite way is to run more API tests than UI tests. I like to have as few UI tests as possible, testing all of the feature logic through the API instead. Other ways to speed up automation include running tests in parallel, and running a test setup once before running the test suite instead of running it before every test.

6. It runs at appropriate times

As software testers, we often want to test as much as possible, as often as possible. But this isn’t always the most efficient thing to do. Smoke tests are a good example of efficient testing. A smoke test is often used during a deployment. We want very few smoke tests so that we can get a clear indication immediately of how the deployment is behaving. It’s OK to run a longer suite of regression tests at some other time, perhaps overnight.

As you can see, determining whether a test is a good test is not simply a matter of looking at metrics. You need to be familiar with the product, understand what the product’s most critical features are, and be able to read the test for code quality and validity.

In my last post, I introduced the concept of the Quality Maturity Model: a series of behaviors that help teams attain various attributes of quality in their software. One of the things it’s important to note is that adopting a Quality Maturity Model requires the whole team to contribute to quality. Quality is not something to be thrown “over the wall” to testers; rather it is a goal that both developers and testers share.

But how can you get the whole team to own quality? One way is through the creation of a Quality Strategy. A Quality Strategy is a document that the whole team agrees on together. It’s like a contract that describes how quality software will developed, tested, and released by the team. In this post, I’ll discuss some of the questions you may want to answer in your team’s Quality Strategy.

Creating and Grooming Stories:
How does the team decide what stories to work on? This could be a decision by the whole team, or by the product owner only. Or the prioritization could be done by someone outside the team.

Who grooms the stories to get them ready for development? This could be the whole team or a subset of the team. Ideally, you’d want to have at least the product owner, one developer, and one tester participating.

Development Process:
How does the team decide who works on which story? It could be that the developers can pick any story from the board, or it could be that developers each have stories in specific feature areas that they can choose from. On some teams, software testers work on simple development stories as well, such as changing words or colors on a webpage or adding in automation ids to make automation easier.

What does “Done” look like for the story? Is it measured by meeting all of the acceptance criteria in the story? Is the developer required to add unit tests before the story can be considered done? How do you know that a feature is ready for testing? On many teams, it’s expected that the developer will do some initial testing to verify that what they coded is ready for further testing.

Feature Handoff:
How will a story be handed off for testing? On some teams this is done by simply moving the story into the “Testing” column on the story board. On other teams, a more formal handoff ceremony is required, where the developer demonstrates the working story and provides suggestions for further testing.

Who deploys the code to the test environment? This seems like a trivial thing, but it can actually be the cause of many misunderstandings and much wasted time. If the developer thinks it’s the tester’s job to deploy the code to the test environment, and the tester assumes that the developer has done it, the tester could begin testing and not realize that the new code is missing until after they have spent a significant amount of time working with the application.

Who will be doing the testing? On some teams, developers can pick up simple testing stories to help improve product velocity, while the more complex stories are left for the testing experts.

Test Plan Creation:
Who will create the test plans? How will they be created? Where will the test plans be stored? Some teams might prefer to do ad-hoc exploratory testing with minimal documentation. Other teams might have elaborate test case management systems that document all the tests for the product. And there are many other options in between. Whatever you choose should be right for your team and right for your product.

Who will write the test automation? On some teams, the developers write the unit tests, and the testers write the API and UI tests. On other teams, the developers write the unit and API tests, and the testers create the UI tests. Even better is to have both the developers and the testers share the responsibility for creating and maintaining the API and UI tests. In this way, the developers can contribute their code management expertise, while the testers contribute their expertise in knowing what should be tested.

Who will be doing other types of testing, such as security, performance, accessibility, and user experience testing? Some larger companies may have dedicated security and performance engineers who take care of this testing. Small startups might have only one development team that needs to be in charge of everything.

Test Tools:
What tools will be used for manual and automated testing? Selecting test tools is very important when you want the whole team to own testing. Developers will most likely want to use tools that use the same language they are using for development, because this minimizes how much context switching they’ll need to do.

Test Maintenance:
Who is responsible for maintaining the tests? It’s amazing how fast test automation can become out of date. One word change on a page can mean a failed test. Ideally, a team should have a “you break it, you fix it” policy where tests are fixed by the person who checked in the code that broke them. If that’s not possible, at least make sure that everyone on the team understands how the tests work and how to fix them in a situation where a fix is needed quickly.

Bugs and Tech Debt:
How are bugs handled when found in testing? Are they discussed by the developer and the tester, triaged by the whole team, or logged on a backlog to be looked at later? It’s often a good idea to fix bugs as soon as they are found, because the developer is already working in that section of code.

How will the team deal with tech debt? Does the team have an agreement to take on a certain amount of tech debt per sprint? Some teams have a policy that when a developer has run out of stories to work on, they pick up tech debt items from the backlog.

Releases:
What kind of testing will you do before a release? Will there be a regression test plan that the whole team can execute together? How about exploratory testing? One high-performing team I know gets together for exploratory testing right before they release. Using this strategy, they’ve uncovered tricky bugs and fixed them before they were released to production.

How will the software be released? In some companies there is a release manager who takes care of executing the release. In other companies, the team members take turns releasing the software. One very helpful technique is Continuous Deployment, where the software is automatically deployed and tests automatically run to verify the deployment to each environment, saving everyone time and effort.

Maintenance:
How will you measure the success of the release? Once software has been released, it’s easy for development teams to forget about it; but this is the time the users begin working with it. What kinds of metrics might you use to measure how well your product is working? You could keep track of defects reported by customers, or look at logs for unexpected errors.

How will you monitor the health of your application? It would be a good idea to have alerts set up so that you can find out about problems with your application before your users do. What kinds of behaviors should you be looking for?

Quality Strategies can be as varied as snowflakes. Imagine the differences between a small startup of ten people who are making a mobile chat app and a company of twenty thousand people who are designing software that flies airplanes. These two companies will need very different strategies! You can design a Quality Strategy that works well for your team by discussing these questions together and drafting a strategy that you can all agree upon.

One year ago, my company adopted something we call the “Quality Maturity Model”. We created the model to help teams measure how they are doing with behaviors that support creating quality applications. The project has been a big success, so I’ve decided to share some details about it with the world!

We started out by coming up with a definition of quality. Using this excellent blog post as a jumping-off point, we defined the seven Attributes of Quality at Paylocity.
A Quality application is:
Valuable: It meets the customer’s needs
Functional: It does what we say it does, and we can measure those interactions
Reliable: It is available when needed
Secure: It protects customer and company information
Performant: It responds within an acceptable time
Usable: It is easy and intuitive to use
Maintainable: It is easy to test, deploy, automate, monitor, update, and scale

After we had defined these attributes, we created a list of behaviors development teams could do that would help ensure those attributes were part of our products. For each of those behaviors, we determined what a minimum version of that behavior would look like, what a standard version would look like, and what excellent would look like. From there, we created the Quality Maturity Model.

Here are some examples of the behaviors defined in the Quality Maturity Model:
Valuable: Team identifies and investigates customer needs
Functional: Team creates, executes, monitors, and maintains reliable test automation
Reliable: Team actively monitors the health of their applications and takes appropriate action as needed
Secure: Team creates and adheres to a security strategy following security best practices
Performant: Team consistently meets SLO standards for their product
Usable: Team ensures the product is usable on multiple devices and supported browsers/platforms when applicable
Maintainable: Team manages and owns their deployments following the release management process

We rolled out the Quality Maturity Model to all the teams and asked them to identify which of these behaviors they were already demonstrating. From there, we asked teams to create quarterly goals to adopt more of the behaviors. Quality Leaders were each assigned a group of teams to meet with monthly to help answer any questions and hold teams accountable.

After a year of working on adoption of the model, we’ve made significant progress! Here are some examples:

A team committed to having the whole team own the test automation. The team works together to make sure that tests aren’t duplicated; for example, if a unit test already covers what’s needed to test a feature, there’s no need to write a UI test. This saves the team significant time in test creation and maintenance, freeing them up to focus on new features.

Another team made sure that the whole team knew how to use the UI automation framework. A developer was able to do a complete regression test on the UI work he was doing and fix all the bugs he found without involving anyone else on the team.

One tester on a team created a reusable test plan so the developers would be able to determine what to test. When both the testers on the team were on leave at the same time, the developers were able to carry on with feature development and testing with no problems.

A team was able to use the progress they made in test automation to speed up their release times from once a month to twice a month.

If you are looking for a way to enhance the quality of your product, minimize escaped defects, and speed up your delivery time, the Quality Maturity Model may be a great way to help. I recommend starting a discussion with the leaders at your company about what quality behaviors you’d like to see in your teams!

Most software companies would agree that in order to release quality software in a timely fashion, good test automation is necessary. There’s simply not enough time to wait around for manual testers to do a complete pass of regression tests before releasing new features; progress would slow to a point that the company would not be competitive.

While it’s possible for software developers to write good automated tests, what’s even better is to have a software tester guide the automation projects to make sure that the right things are being tested, and to think of the edge cases that developers might not think of.

But there are many software testers out there who are not actually testers! They can write test automation, but they don’t know how to think like a tester. I call these folks “lazy developers”. They enjoy writing code, and they also enjoy not having to feel responsible for writing good feature code. They can quietly work on their automation projects without worrying about the quality of their code. Unfortunately their poor automation code results in tests that don’t provide the company with the information it needs about the product, which results in poor quality software.

How can you tell if you have a lazy developer rather than a software tester on your team? Here are five key signs:

1. They are not particularly interested in thinking about what to test
   In story grooming sessions, the lazy developer doesn’t have any questions for the team. They don’t participate in the conversation, and they don’t point out any possible problem areas of new features or areas of regression for bug fixes. This can result in many missed opportunities to find bugs.
2. They refuse to do any manual or exploratory testing
   The lazy developer thinks of themselves as an automation engineer and nothing else. They are insulted by suggestions that they do exploratory or manual testing on a new feature. Rather than get to know the product, they’d prefer jumping right in to writing tests. Unfortunately, this means that they really don’t understand how the product works, and they may be automating the wrong things.
3. They are protective of their code and don’t want to share it with others
   Real developers understand that the product code base is a shared code base. No one has exclusive claim to any section of the code. But lazy developers like to have their own little corner of code that no one else looks at. They’ve discovered that by writing automated tests, they can write code that the other developers won’t be interested in, so they won’t interfere with the lazy dev’s pet project. See my post on lone wolves for more information.
4. They have no real interest in the quality of software releases
   The lazy developer doesn’t pay much attention when the team releases software. They are only interested in their automated tests. If the tests run and mostly pass, that’s good enough for them. They don’t make the connection between escaped defects and their tests, because they’re not writing tests to check the quality of the product; they’re writing tests because writing them is fun.
5. They aren’t good at finding bugs
   The lazy developer isn’t good at finding bugs, because they don’t actually care about finding the bugs. If their automation finds a bug, that’s great; they feel like they’ve done their job. But if a bug can’t be found by their automation, they feel it’s probably not that important anyway.

Are YOU a lazy developer?

If any of the above descriptions sound like you, then you might be in the wrong career! Take some time to do the following soul-searching:

• Pay attention to what you enjoy spending time on
  You can definitely be a good software tester and enjoy writing automation code! But if you find yourself sighing inwardly whenever you need to write a test plan, you might really be a developer.
• Notice what kind of stories catch your interest
  When you are reading stories about software online, what gets you excited? Is it the story of an elusive bug that took days of searching to find, or is it a new coding language or an engineering challenge? If development stories excite you more than testing stories, you might be in the wrong role.
• Are you envious of the developers on your team because it seems like they are having more fun?
  Ask your manager if you can do some simple development stories for the team. See if you actually enjoy working on those stories more than you enjoy testing them.
• Is fear holding you back from becoming a developer?
  Perhaps you actually trained to become a software developer, but got stuck in the testing role and never got the courage to leave. Would you be willing to face your fear and take on some additional training? Would you be willing to ask for some coaching from a developer you trust?
• Explore what it would take to become a developer at your company
  If you’ve decided that you are really a developer, talk to your manager. See if there is an established path at your company for making the transition from tester to developer. If there isn’t a path, look for someone at your company who made the transition and ask them how they did it.
• Find a mentor
  Find a developer at your company who has good communication skills, and ask them if they would be willing to mentor you. Let them suggest projects that you can work on that will develop your skills and fill in any technical gaps.

I personally love software testing, and I want to see as many great testers out there as possible! We need people who care about quality so much that they are willing to go the extra mile. But we also need passionate developers. Our software teams will be more effective if everyone is doing a job that they love!

Last week, I released a web application for people to use to practice UI and API automation. It took me about four months to develop, working on weeknights and weekends, and it was quite an adventure! Here are five lessons I learned while developing the app.

Lesson One: Software development is hard; really hard
You’ve probably heard this before, and probably from the developers you work with. But unless you’ve actually tried to develop an app yourself, you really don’t know how hard it is. I remember in my early days of software testing, when I would find bugs where field validations weren’t working correctly, and I would assume that the developer just didn’t care. But now that I know just how hard it is to get validations to even work at all, I am really sympathetic!

Lesson Two: We have product owners for a reason
Take a moment to appreciate your product owner this week; the work they do is more important than you realize. When I started to work on the front end of my application I didn’t think it would be very complicated because it only has a few simple screens. But as I was coding the pages, I kept coming up with questions about how each page should be connected to the others. Finally I had to stop what I was doing and sketch out wireframes. This is the kind of thing that product owners do for us so that we don’t have to!

Lesson Three: Even the best coding courses won’t teach you everything
As I’ve mentioned in previous posts, last year I took a really great Node.js course to prepare me for this project. I learned a ton about how to create and validate APIs, how to create a web page, how to work with a database, and how to publish an application. But there were some details missing about working with web pages and JavaScript files. Even though the course was comprehensive, it couldn’t teach me absolutely everything. I didn’t have time to take another course, so I wound up doing a lot of web searching.

Lesson Four: There are a lot of different ways to solve a problem
All that web searching brought me to my fourth realization: there are a lot of different ways to do things with code, and this makes software development very confusing. One of the things I struggled with was how to get authentication working on my site. I had it working in the back end- thanks to the Node.js course- but I had no idea how to get it working in the front end. My searches would bring up several different blog posts, each with a different solution. I’d start trying to follow one tutorial, and then hit a roadblock and decide that it wouldn’t work for me. Finally I found this post, which came the closest to meeting my needs.

Lesson Five: Testing and developing are different skill sets
There has been a lot of focus recently on making sure that the whole development team owns quality, and this is a really good thing! Test automation is more reliable and scalable when developers help with the automation frameworks and add new tests. But working on this project, it was so clear to me that testing and developing need really different mindsets. While I was developing the app, I kept on thinking of all the different things I could do to test it, and I had to tell myself to stop thinking like that so that I could focus and get the development work done! When I’d finished creating the API, then I took a break and created all the tests I could think of. And when I finished the UI I had a lot of fun doing exploratory testing on the app. There may be some people out there in the world who enjoy both developing and testing, but I’ve never met anyone who is truly passionate about both.

Developing my app made me understand the big picture of web applications better, and made me appreciate the developers and product owners I work with even more! If you have some time to spare, I recommend going on an adventure like this yourself.

I am writing a book on software testing, which I’m hoping to publish by the end of the year. In order to help my readers learn about manual testing, API testing, and API and UI automation, I decided I’d like to have an example application to accompany the book.

There are a lot of great practice sites out there for API testing and UI automation, but not a lot of sites that offer both, and some of those sites are a little too complex for someone learning the basics. So I decided to create my own!

The Contact List App is a simple web application that allows testers to create an account, log in, and add, edit, and delete a list of contacts. The web elements are easy to access, so it’s great for getting started with UI automation. The application includes an API for testers to practice GET, POST, PUT, PATCH, and DELETE operations.

This was my first time creating a complete application, and it was quite a learning experience! I’ll share some of the things I learned in a future post. I hope that you will find the application helpful as you hone your testing skills, and please email me with any feedback.

If you’d like to stay informed about my upcoming book, and perhaps even preview chapters, you can sign up for my mailing list here. In the meantime, enjoy the Contact List App!

Have you ever been testing an API and gotten involved in a dispute about what a response code should be?  Perhaps you witnessed a disagreement between two developers, or perhaps a developer was insisting the response code should be one thing and you thought it should be something different.  You might have gone to Stack Overflow to see what others think, and discovered people referencing something called an RFC.  

RFC stands for “Request for Comments”.  The RFCs related to HTTP protocols are produced by the ISOC: the Internet Society.  The Internet Society consists of tens of thousands of members, a staff, and a board of trustees.  They produce the standards that most developers use when developing websites and web applications, and those standards are written up in the form of RFCs.  

The first HTTP RFC was created in 1996, and RFC 2616, the most recent RFC that discusses response codes, was created in 1999.  These RFCs are surprisingly easy to read!  Let’s take a look at some of the contents of RFC 2616 and see how we can apply them to real-life scenarios.

Responses to POST requests:

In section 9.5, the RFC states “The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.” So when you are doing a POST that doesn’t create a new resource, such as a request that checks for the existence of a resource, you could use a 200 or a 204 response code. But if your POST is returning a response body, you must use the 200 response code rather than the 204 response code, because the 204 response code cannot include a response body.

Responses to PUT requests:

In section 9.6, the RFC says “If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.” So as with the POST request, if you are modifying a resource and not returning anything in the body of the response, you could use a 200 or a 204 response code. But if you were returning something in the response body, you’d definitely want to use a 200.

Responses where the user is not allowed access to a resource:

Section 10.4.4 says of a 403 “Forbidden” response code: “The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity.  If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.” So if your user does not have permission to view a resource, and you don’t mind if the user knows that the resource exists, then you can use a 403 response code. But if you don’t want the user to even know that the resource exists, because perhaps that might give a malicious user too much information, then you’d want to return a 404 so that all they’d know was that the resource was not found.

Hopefully these examples have shown how useful the HTTP RFC documents can be. So the next time you are testing an API and you’re wondering if you’re seeing the right response code, try going to the source!

The very first test automation job I had was for a company that had no QA Engineer before I was hired. I’d never done automation before, but I convinced the company that with my rudimentary knowledge of Java, I’d be able to figure it out. This was long before there were awesome online resources like Test Automation University, so it took me a long time and a lot of trial and error before I had automated tests that would run and pass. My tests were long, flaky, hard to maintain and filled with implicit waits and duplicated code, but they were my tests, and I had really enjoyed solving the problem of test automation on my own.

Then the company hired a new software developer, and our manager thought it would be a great idea for him to learn about our software by looking at my tests. Without consulting me, the new developer completely rewrote my tests. I was really annoyed, until I looked at the tests and saw that he had reorganized them using page object models and methods so that no code was duplicated. It would be so much easier to maintain the tests now! That week I learned that it’s always best to work with others rather than going it alone, because others often have skills or information that we don’t.

Software developers know this already, because they are required to collaborate with others through feature planning and code reviews. But often testers aren’t required to do this. Test automation code is just as important as production code because of the value it provides, and for that reason, we shouldn’t be lone wolves, even if we enjoy it! Here are some lone wolves that you may encounter or recognize in yourself.

The Gollum: In The Lord of the Rings, Gollum loved his ring so much he called it his “precious”. For the test automation Gollum, her automated tests are her “precious”. She’s worked long and hard at those tests and is very proud of them! Unfortunately, because she was the only one who worked on the tests, they make sense only to her. Nobody wants to help maintain the tests because they are so hard to understand. As a result, she is the only one who can fix the tests when they break, and therefore she has become the bottleneck for automated testing on her team.

How to stop being The Gollum: Share your test automation with others and get feedback on how they could be more useful and maintainable. Implement the feedback and repeat.

The Frank Sinatra: Just as the real Frank Sinatra sang about doing it “My Way”, the test automation Frank wants to do it all his way. He is convinced that he alone knows the right way to do test automation. And unsurprisingly, the right way is with his favorite tool! Every other tool falls short in his estimation, so he’s going to stick with his tool even if the rest of the company is using something different. As a result, he can’t collaborate and share ideas with testers on other teams, and his test automation never improves.

How to stop being The Frank Sinatra: Try some new test automation tools! You don’t have to love every single one, just give yourself enough time to really understand their strong points. You may be surprised at how much test tools have improved in recent years!

The Magpie: This species of bird is attracted to shiny objects. The test automation Magpie is attracted to new test automation frameworks! If it’s new, she wants to try it out, and she loves writing test automation from scratch. In her opinion, any problems with her existing automation must be problems with the framework, and the problems become an excuse to scrap the project and start over again with a new framework. This means her team never has a complete test suite that they can run and rely upon. It also means that the team has to keep up with all the framework changes, which will make them reluctant to contribute to the automation.

How to stop being The Magpie: Get input from your team about what framework would be best for your application, then stick with it. When you run into trouble, ask your team for help, or ask other test automation engineers. You don’t have to keep using the framework forever, but use it at least long enough to see it working in CI/CD.

The Hermit: The Hermit simply loves working alone. He’s very busy working on his automation all by himself, so he doesn’t want to take the time to explain what he’s doing to the rest of his team or to any other testers. He hates asking for help and sees it as a sign of weakness; he’d rather figure everything out on his own. As a result, his automation never improves, and no one at the company ever benefits from his expertise.

How to stop being The Hermit: Find a developer or test automation engineer that you admire and trust, and ask them for their opinion on your automation work. Implement some of their suggestions. Volunteer to lead a workshop on something you’re really good at. Try to help one person a week who is stuck on a thorny automation problem.

Software is a collaborative adventure! Building software is complicated. There are many facets of software quality to consider, while at the same time delivering features that will put your company ahead of its competitors. That’s why we don’t have room for lone wolves anymore. Software testers need to work together to contribute to test automation projects that deliver fast, accurate results. And software testers need to work with software developers to make sure that quality goes both ways: we need quality production code and quality test code.

Imagine that you are working on a team that is creating a new feature that allows users to submit and watch videos. The application uses a third party- we’ll call it Encodurz- that encodes the videos that are uploaded to your application. You work hard to test the feature; making sure that the UI is flawless, that the user journeys make sense, and that the videos play correctly, among many other things.

It’s time for your new feature to be released to the world, and you’re excited! But on the day of the release, Encodurz has an outage. No videos can be encoded, so none of the uploaded videos will display! Your users don’t know that it’s not your fault; all they see is that the new feature doesn’t work. They call and complain to customer service and they post complaints on Twitter. This is why reliability engineering is important!

Reliability engineering focuses on the ability of applications to be as available as possible. It aims to offer a good user experience, even in the following situations:
* The server goes down
* The database is unavailable
* An API that your application relies on is unavailable
* A third-party provider that your application depends on is unavailable

Do you know how your application will behave in those scenarios? If not, it sounds like it’s a good time to test those scenarios! There are two ways to test:

Bring the service down
You can bring a server down by unplugging it, but chances are your server is not nearby for you to do that. But you can also bring a server, a webservice, or a database down by shutting it down using scripted commands. If you don’t have permission to do that, you can find someone in DevOps at your company who has the correct permissions.

Change your connection strings
It’s really easy to simulate an outage of a server, a database, an API or any other service your application depends on simply by changing the way your application connects to it. For example, if your app connects to your company database with a username and password, all you need to do is simply send in a bad password. Or you could change the URI needed for the connection so that it’s incorrect.

NOTE that it is a bad idea to test either of the above strategies in Production, at least until your application is VERY resilient. You will want to do this testing in your test environment.

Once you have discovered what happens when your application or its dependencies has an outage, it’s time to make your app as resilient as possible. Here are seven strategies for doing that:

1. Use a “circuit-breaker”
   This method puts logic in the code that tries connecting to a resource a few times, and when it is unable to connect, switches over to a different resource. For example, if your application usually points to Server A, and you have a backup server called Server B, when the circuit-breaker is tripped the connection changes over to Server B.
2. Use retries
   Sometimes a third-party app will fail temporarily for an unknown reason. You don’t want your request to the app to fail and never try again. So you can build in some retries; perhaps if the request fails, you wait 30 seconds and try again, if it fails again you wait 60 seconds and try again, and so on. You don’t want to retry indefinitely, but instead set some sort of time limit so if the request still hasn’t succeeded when the limit is met, an error is returned.
3. Use cached data
   It’s a great idea to have some kind of caching service that will be able to serve up data if a request fails for some reason. When the request fails, your application just grabs the slightly-stale cached data and returns that instead.
4. Enter into read-only mode
   If your application detects that there’s a problem writing to a data source, you can configure it to go into a read-only mode so that your users can at least see their data. You should set a message to display when this is the case to explain to users why they can’t update their data at the moment.
5. Provide messaging that something isn’t quite right
   It is so annoying to get a cryptic error like “Error: T-128556” when using an application. That’s not helpful at all! Instead, provide your users with as much detail as you can about what’s wrong. In the example at the beginning of this post, there could have been a message that read “Sorry, we are having an issue connecting to our video encoding software at the moment. Please try again in a few minutes.”
6. Have a status page that explains what is going on
   If your application goes down completely or is very degraded, it’s a great idea to have a status page (hosted on a different server) that provides a way to communicate to your end users what’s happening. You could include a timestamp with your time zone, a list of the features that are affected, and a message about what’s going wrong. Then you can keep the status page updated at regular intervals until the problem is fixed.
7. After the problem has ended, do a post-mortem to see what lessons you’ve learned
   If the outage was very brief or only affected a few users, you might not need to make the post-mortem public. But if it was a big outage, it’s a great idea to communicate to customers what happened, why it happened, and how you are going to prevent it in the future. See Slack’s message about their January 4th outage for a really good example of this.
   

No application can run perfectly 100% of the time; servers are imperfect and our apps are almost always dependent upon outside forces. But it’s important to know exactly what will happen when services are down and to figure out the best ways to respond to those issues before they happen. As testers, we can encourage our team to participate in this process.

It’s a new year, and a new year means it’s time for new challenges! My challenge to you is: this year, learn- and I mean REALLY learn- a programming language. Don’t just learn “enough to be dangerous”, or enough to write test automation; really understand the components of the language and how to use them.

I did this last year, and it was one of the most rewarding things I did! I’ve always liked Node, so I decided to learn Node.js. I took this awesome course; it took about nine months for me to complete it, and it was definitely worth the time it took.

Why should you take the time to really learn a programming language? Here are four reasons:

1. You will understand what your test code is doing
   We’ve all done it- we want to get something done in our test automation, we do a quick search on Stack Overflow to see how other people have accomplished it, and we copy and paste their code. But when we do this, we don’t really understand what our test code is doing. This can result in flaky tests that we don’t know how to fix. When we fully understand our code, however, it’s easy to fix.
   
2. You will write better code, which means more maintainable tests.
   When you understand the principles of writing code in your chosen language, you’ll write clean code. You’ll know how to set things up like the page object model, and refactor code to make sure you’re not repeating yourself. You’ll put values into a config file so that your code will be easily reusable by everyone on your team. This will result in tests that are easy to maintain.
   
3. You will have sympathy for developers.
   Early in my testing career, I’m ashamed to say that I had a certain disdain for developers who couldn’t figure out how to validate date fields or phone numbers. When I tried coding these things myself, however, I discovered just how difficult they were. Coding is hard! Once you’ve tried writing an application and struggled with what seems on the surface to be a simple problem, you’ll respect the developers you work with so much more. This will enable you to work together more effectively.
   
4. You will understand your product’s code better.
   Understanding how to code in your chosen language won’t just make you better at writing code, it will make you better at reading code. You’ll be able to look at your production code and see what it’s doing and why. This will give you ideas for how to test it. For example, if you looked at the code for a form field and you saw that one of the values was expecting an enum, you might decide that it would be a good idea to try entering a value that wasn’t included in the enum, or a value that wasn’t in all caps, to see if the program would respond appropriately.
   

So this year, I challenge you to really learn a programming language! And once you’ve completed whatever course you’ve chosen, try writing an application on your own. I’ll be using the skills I learned in the Node.js course I took to create a simple application that readers of my forthcoming book will be able to use for testing practice. Let’s all become better coders together!