Book Review: Enterprise Continuous Testing

As I've mentioned in previous posts, this year I'm reading one testing-related book a month and reviewing it in my blog.  This month I read Enterprise Continuous Testing, by Wolfgang Platz with Cynthia Dunlop.

This book aims to answer solve the problems often found in continuous testing.  Software continuous testing is defined by the author as "the process of executing automated tests as part of the software delivery pipeline in order to obtain feedback on the business risks associated with a software release as rapidly as possible".  Platz writes that there are two main problems that companies encounter when they try to implement continuous testing:

1. The speed problem
Testing is a bottleneck because most of it is still done manually
Automated tests are redundant and don't provide value
Automated tests are flaky and require significant maintenance

2. The business problem
The business hasn't performed a risk analysis on their software
The business can't distinguish between a test failure that is due to a trivial issue and a failure that reveals a critical issue

I have often encountered the first set of problems, but I never really thought about the second set.  While I have knowledge of the applications I test and I know which failures indicate serious problems, it never occurred to me that it would be a good idea to make sure that product managers and other stakeholders can look at our automated tests and be able to tell whether our software is ready to be released.

Fortunately, Platz suggests a four-step solution to help ensure that the right things are tested, and that those tests are stable and provide value to the business.

Step One: Use risk prioritization

Risk prioritization involves calculating the risk of each business requirement of the software.  First, the software team, including the product managers, should make a list of each component of their software.  Then, they should rank the components twice: first by how frequently the component is used, and second by how bad the damage would be if the component didn't work.  The two rankings should be multiplied together to determine the risk prioritization.  The higher the number is, the higher the risk; higher risk items should be automated first, and those tests should have priority.

An example of a lower-risk component in an e-commerce platform might be the product rating system: not all of the customers who use the online store will rate the products, and if the rating system is broken, it won't keep customers from purchasing what's in their cart.  But a higher-risk component would be the ability to pay for items with a credit card: most customers pay by credit card, and if customers can't purchase their items, they'll be frustrated and the store will lose revenue.

Step Two: Design tests for efficient test coverage

Once you've determined which components should be tested with automation, it's time to figure out the most efficient way to test those components.  You'll want to use the fewest tests possible to ensure good risk coverage.  This is because the fewer tests you have, the faster your team will get feedback on the quality of a new build.  It's also important to make sure that each test makes it very clear why it failed when it fails.  For example, if you have a test that checks that a password has been updated, and also checks that the user can log in, when the test fails you won't know immediately whether it has failed on the password reset or on the login.  It would be better to have two separate tests in this case.

Platz advocates the use of equivalence classes: this is a term that refers to a range of inputs that will produce the same result in the application.  He uses the example of a car insurance application: if an insurance company won't give a quote to a driver who is under eighteen, it's not necessary to write a test with a driver who is sixteen and a driver who is seventeen, because both tests will test the same code path.

Step Three: Create automated tests that provide fast feedback

Platz believes that the best type of automated tests are API tests, for two reasons: one, while unit tests are very important, developers often neglect to update them as a feature changes, and two, UI tests are slow and flaky.  API tests are more likely to be kept current because they are usually written by the software testers, and they are fast and reliable.  I definitely agree with this assessment!

The author advises that UI tests should be used only in cases where you want to check the presence of or location of elements on a webpage, or when you want to check functionality that will vary by browser or device.

Step Four: Make sure that your tests are robust

This step involves making sure that your tests won't be flaky due to changing test data or unreliable environments.  Platz suggests that synthetic test data is best for most automated tests, because you have control over the creation of the data.  In the few cases where it's not possible to craft synthetic data that matches an important test scenario, masked production data can be used.

In situations where environments might be unreliable, such as a component that your team has no control over that is often unavailable, he suggests using service virtualization, where responses from the other environment are simulated.  This way you have more control over the stability of your tests.

Enterprise Continuous Testing is a short book, but it is packed with valuable information!  There are many features of the book that I didn't touch on here, such as metrics and calculations that can help your team determine the business value of your automation.  I highly recommend this book for anyone who wants to create an effective test automation strategy for their team.

Adventures in Node: Arrow Functions

This year I've been feeling an urge to really learn a programming language.  There are lots of languages I know well enough to write automation code in- C#, Java, Javascript, and so on- but I decided I wanted to really dive into one language and learn to really understand it.

I decided to go deep with Node.js.  Node is essentially Javascript with a server-side runtime environment.  It's possible to write complete applications in Node, because you can code both the front-end and the back-end of the application.  And I was fortunate enough to find this awesome course by Andrew Mead.  Andrew does a great job of making complicated concepts really simple, so as I am taking the course, I'm finding that things that used to confuse me about Node finally make sense!  And because I like sharing things I've learned, I'll be periodically sharing my new-found understanding in my blog posts.

I'll start with arrow functions.  Arrow functions have been around for a few years now, but I've always been confused by them, because they weren't around when I was first learning to write code.  You may have seen these functions, which use the symbol =>.  They seem so mysterious, but they are actually quite simple!  Arrow functions are simply a way to notate a function to save space and make code easier to read.  I'll walk you through an example.  We'll start with a simple traditional function:

const double = function(x) {
     return x + x
}

double is the name of the function.  When x is passed into the function, x + x is returned.  So if I called the double function with the number 3, I'd get 6 in response.

Now we're going to replace the function with an arrow:

const double = (x) =>  {
    return x + x
}

Note that the arrow comes after the (x), rather than before.  Even though the order is different, function(x) and (x) => mean the same thing.

Now we're going to replace the body of the function { return x + x } with something simpler:

const double = (x) => x + x

When arrow functions are used, it's assumed that what comes after the arrow is what will be returned.  So in this case, x + x means the same thing as { return x + x }.  This is only used if the body of the response is relatively simple.

See?  It's simple!  You can try running these three functions for yourself if you have node installed.  Simply create an app.js file with the first version of the function, and add a logging command:

console.log(double(3))

Run the file with node app.js, and the number 6 will be returned in the console.

Then replace version 1 of the function with version 2, run the file, and you should get a 6 again.  Finally, replace version 2 with version 3, and run the file; you should get a 6 once again.

It's even possible to nest arrow functions!  Here's an example:

const doublePlusTen = (x) => {
    const double = (x) => x + x
    return double(x) + 10
}

The const double = (x) => x + x is our original function.  It's nested inside a doublePlusTen function.  The doublePlusTen is using curly braces and a return command, because there's more than one line inside the function (including the double function).  If we were going to translate this nested function into plain English, it would look something like this:

"We have a function called doublePlusTen.  When we pass a number into that function, first we pass it into a nested function called double, which takes the number and doubles it.  Then we take the result of that function, add 10 to it, and return that number."  

You can try out this function by calling it with console.log(doublePlusTen(3)), and you should get 16 as the response.

Hopefully this information will help you understand what an arrow function is doing the next time you encounter it in code.  You may want to start including arrow functions in your own automation code as well.  Stay tuned in the coming weeks for more Adventures in Node posts!

How I Would Have Tested the Iowa Caucus App

About six weeks ago, the Iowa Democratic Party held its caucus.  For those who don't live in the United States, this event is one of the first steps in the presidential primaries, which determine who will be running for president in the next presidential election. 

In 2016, the Iowa Caucus used a mobile app created by a company called Interknowlogy in partnership with Microsoft to allow each precinct to report their results.  This app worked successfully in the 2016 caucus.  But this year the Iowa Democratic Party chose to go with a different company to create a new app, which proved disastrous.  Incorrect tallies were reported, and precincts that tried to report via phone were often not able to get through or found that their calls were disconnected.

From reading this assessment, it appears that the biggest problem with the 2020 app was that the software company didn't have adequate time to create the application, and certainly didn't have enough time to test it.  But as a software tester, I found myself thinking about what I would have done if it had been my responsibility to test the app, assuming that there had been enough time for testing.  Below is what I came up with:

Step One: Consider the Use Case

The interesting thing about this application is that unlike an app like Twitter or Uber, the number of users is finite.  There are only about 1700 precincts in Iowa, including a few out-of-state precincts for Iowans who are in the military or working overseas.  So the app wouldn't need to handle tens of thousands of users.  

The users of the application will be the precinct leaders, who will own a wide variety of mobile phones, such as iPhone, Galaxy, or Motorola, and each of those devices could have one of several carriers, such as AT&T, Verizon, or Sprint.  Mobile service might be spotty in some rural areas, and wifi might be unavailable in some locations as well.  So it will be important to test the app on a wide variety of operating systems and devices, with a variety of carriers and connection scenarios.  

Moreover, the precinct leaders will probably vary widely in their technical ability.  Some might be very comfortable with technology, while others might have never installed an app on their phone.  So it will be imperative to make sure that the app is on both the Apple App Store and Google Play, and that the installation is simple.

Some leaders may choose to call in their election results instead of entering them in the app.  So the application should allow an easy way to do this with a simple button click.  This will also be useful as a backup plan in case other parts of the app fail.

Finally, because this is an event of high political importance, security must be considered.  The app should have multi-factor authentication, and transmissions should be secured using https with appropriate security headers.  

Step Two: Create an In-House Test Plan

Now that the users and the use case have been considered, it's time to create an in-house test plan.  Initial testing should begin at least six months before the actual event.  Here is the order that I would direct the testing:

• Usability testing: the application should be extremely easy to install and use.
• Functional testing: does the application actually do what it's supposed to do?  Testers should test both the happy path- where the user does exactly what is expected of them- and every possible sad path- where the user does something odd, like cancel the transaction or back out of the page.
• Device and carrier testing: testers should test on a wide variety of carriers, with a wide variety of providers, and with a wide variety of connection scenarios, including scenarios such as a wifi connection dropping in the middle of a transmission.  Testers should also ensure that the application will work correctly overseas for the remote precincts.  They can do this by crowd-sourcing a test application that has the same setup as the real application.  
• Load and performance testing: testers should make sure that the application can handle 2500 simultaneous requests, which is much higher than the actual use case.  They should also make sure that page response times are fast enough that the user won't be confused and think that there's something wrong with the application.  
• Security testing: testers should run through penetration tests of the application, ensuring that they can't bypass the login or hijack an http request.  
• Backup phone system testing: testers should validate that they can make 2500 simultaneous calls to the backup phone system and be able to connect.  Since there probably won't be 2500 phone lines available, testers should make sure that wait times are appropriate and that callers are told how many people are in the queue in front of them.  

Step Three: External Security Audit

Because of the sensitive nature of the application, the app should be given to an external security testing firm at least four months before the event.  Any vulnerabilities found by the analysis should be addressed and retested immediately.

Step Four: Submit to the Apple App Store and Google Play

As soon as the application passes the security audit, it should be submitted to the app stores for review.  Once the app is in app stores, precinct leaders should be given instructions for how to download the app, log in with a temporary password, and create a new password, which they should save for future use.  

Step Five: End User Testing

Two months before the caucus, precinct leaders will be asked to do a trial run on the application.  Instead of using actual candidates, the names will be temporarily replaced by something non-political, like pizza toppings.  The leaders will all report a fictitious tally for the pizza toppings using the app, and will then use the backup phone number to report the tally as well.  This test will accomplish the following:

• it will teach the leaders how to use the app
• it will validate that accurate counts are reported through the app
• it will help surface any issues with specific devices, operating systems, or carriers
• it will validate that the backup phone system works correctly

By two weeks before the caucus, any issues found in the first pizza test should have been fixed.  Then a final trial run (again with pizza toppings rather than candidates) will be conducted to find any last-minute issues.  The precinct leaders will be strongly encouraged to make no changes to their device or login information between this test and the actual caucus.

Monday Morning Quarterbacking

There's a term in the US called "Monday Morning Quarterbacking", where football fans take part in conversations after a game and state what they would have done differently if they had been the quarterback.  Of course, most people don't have the skill to be a major-league quarterback and they probably don't have access to all the information that the team had.  

I realize that what I'm doing is the software tester equivalent of Monday Morning Quarterbacking.  Still, it's an interesting thought exercise.  I had a lot of fun thinking about how I would test this application.  The next time you see a software failure, try this thought exercise for yourself- it will help you become a better tester!

API Contract Testing Made Easy

As software becomes increasingly complex, more and more companies are turning to APIs as a way to organize and manage their application's functionality.  Instead of being one monolithic application where all changes are released at once, now software can be made up of multiple APIs that are dependent upon each other, but which can be released separately at any time.  Because of this, it's possible to have a scenario where one API releases new functionality which breaks a second API's functionality, because the second API was relying on the first and now something has changed.

The way to mitigate the risk of this happening is through using API contract tests.  These can seem confusing: which API sets up the tests, and which API runs them?  Fortunately after watching this presentation, I understand the concept a bit better.  In this post I'll be creating a very simple example to show how contract testing works.

Let's imagine that we have an online store that sells superballs.  The store sells superballs of different colors and sizes, and it has uses three different APIs to accomplish its sales tasks:

Inventory API:  This API keeps track of the superball inventory, to make sure that orders can be fulfilled.  It has the following endpoints:

• /checkInventory, which passes in a color and size and verifies that that ball is available
• /remove, which passes in a color and size and removes that ball from the inventory
• /add, which passes in a color and size and adds that ball to the inventory

Orders API:  This API is responsible for taking and processing orders from customers.  It has the following endpoints:

• /addToCart, which puts a ball in the customer's shopping cart
• /placeOrder, which completes the sale

Returns API:  This API is responsible for processing customer returns.  It has the following endpoint:

• /processReturn, which confirms the customer's return and starts the refund process

Both the Orders API and the Returns API are dependent on the Inventory API in the following ways:

• When the Orders API processes the /addToCart command, it calls the /checkInventory endpoint to verify that the type of ball that's been added to the cart is available
• When the Orders API processes the /placeOrder command, it calls the /remove command to remove that ball from the inventory so it can't be ordered by someone else
• When the Returns API runs the /processReturn command, it calls the /add command to return that ball to the inventory

In this example, the Inventory API is the producer, and the Orders API and Returns API are the consumers.  

It is the consumer's responsibility to provide the producer with some contract tests to run whenever the producer makes a code change to their API.  So in our example:

The team who works on the Orders API would provide contract tests like this to the team who works on the Inventory API:

• /checkInventory, where the body contained { "color": "purple", "size": "small" }
• /remove, where the body contained { "color": "red", "size": "large" }

The team who works on the Returns API would provide an example like this to the team who works on the Inventory API:

• /add, where the body contained { "color": "yellow", "size": "small" }

Now the team that works on the Inventory API can take those examples and add them to their suite of tests.  

Let's imagine that the superball store has just had an update to their inventory. There are now two different kinds of bounce levels for the balls: medium and high.  So the Inventory API needs to make some changes to their API to reflect this.  Now a ball can have three properties: color, size, and bounce.  

The Inventory API modifies their /checkInventory, /add, and /remove commands to accept the new bounce property.  But the developer accidentally makes "bounce" a required field for the /checkInventory endpoint.  

After the changes are made, the contract tests are run.  The /checkInventory test contributed by the Orders API fails with a 400 error, because there's no value for "bounce".  When the developer sees this, she finds her error and makes the bounce property optional.  Now the /checkInventory call will pass.  

Without these contract tests in place, the team working on the Inventory API might not have noticed that their change was going to break the Orders API.  If the change went to production, no customer would be able to add a ball to their cart!

I hope this simple example illustrates the importance of contract testing, and the responsibilities of each API team when setting up contracts.  I'd love to hear about how you are using contract testing in your own work!  You can add your experiences in the Comments section.