Picture this: You’re planning a sprint, going over stories in the Product Backlog, bringing high priority stories into the Sprint Backlog, and working to identify what is required to deliver the stories. The Product Owner is present, making sure that the team understands the acceptance criteria, and the ScrumMaster is facilitating the session, helping ensure that the team doesn’t overcommit. Things are moving along smoothly.

As the team begins to figure out what it takes to deliver a story, a team member says:

Some rights reserved by ginatrapani

“Well, we can figure out the steps the system will have to perform to complete the business logic. We also know what data table the result needs to go into. The Product Owner really wants this feature, but we’re not too familiar with the new programming language we are using and it would take too much time to figure it out. For now, we will put the logical steps into a Word document and have a developer follow the steps in the document and manually enter the result into the system we have to interface with.”

That would be absurd! No developer would ever utterer that in real life. The story can either get coded to meet the acceptance criteria within the desired timeframe, or it cannot.

Now, if you take that previous sentence and change it a little bit:

“Well, we can figure out the steps the system will have to perform to complete the business logic. We also know what data table the result needs to go into. The Product Owner really wants this feature, but we’re not too familiar with the automated testing framework we are using and it would take too much time to figure it out. For now, we will put the logical steps into a Word document and have a tester follow the steps in the document and manually enter the result into the test result matrix.”

Somehow, the “test” version of that paragraph isn’t only acceptable to a lot of teams, it’s incredibly common to hear. “We don’t have time to automate the tests.”

In reality, you don’t have time the luxury of not automating your tests. Manual testing isn’t sustainable; it is too expensive and it is too slow to execute all the logic present in your application. Because manual testing is not feasible, the buildup of untested code in your system present the biggest risk to almost any software development effort. (James Grenning recently articulated a strong case for why this is so at a recent Chicago Agile Project Leadership Network meeting.) That risk may not manifest itself today or tomorrow, but not too many versions down the road your team, your application, and your business is going to hit a brick wall of poor quality.

Automated testing cannot be optional. It’s the team’s responsibility to make sure that automated tests are being created. You don’t have to be perfect to get started; just start during your next Sprint. Next, inspect and adapt. Learn from others, get training, and make the investment. Perhaps you “complete” fewer features by not investing in automation, but remember… you would not call a story “done” if the code is not automated, so don’t call it “done” if the tests are not automated.