In last week's article, I mentioned that asking developers about automated testing was a favourite topic of mine. Today, we're going to talk about why it should be one of your favourite topics as well :)
Do either of these statements sound familiar to you?
- "It works perfectly on my machine!" (but doesn't on yours)
- "Well that worked yesterday; of course it should still work today." (but the feature is broken)
Automated testing can help.
Developers and Testing
Once upon a time, there was a clear distinction between the people who wrote code and people who tested it. The people who wrote the code did very little (if any) testing. In smaller companies with only developers, the end-user or customer became the surrogate tester. This was a Bad Thing™.
Software and environments are complex. As a project grows, so do the number of ways to accomplish a given task. The effort required to manually verify that everything works grows exponentially. Not even the client can remember every feature he or she requested.
What about now?
Today, the expectation is that every website or software project includes a suite of automated tests.
Even if your website or software developer goes on holiday, you should be guaranteed that any change made while they're away won't break existing functionality.
There are many types of testing: unit, integration, end-to-end, and acceptance to name a few. If you have never disccused testing with your development team, I would encourage you to ask about unit and acceptance. The first is for the developer's peace of mind, the second is for yours :)
Unit tests exercise small amounts of code in different ways. They help reassure a developer that individual components react as expected. As a client or end-user, you probably will never see these tests, but they are a vital part of software development.
Some developers even write tests before their code; this practice is commonly known as Test-Driven Development, or TDD. Hiring developers who understand the benefit of unit tests or TDD will certainly increase the return on your software investment.
In the past, projects started with the customer writing down a long list of requirements. Time would pass, and eventually they would get the "final" product in their hand. And it rarely did what they wanted.
Today, it's much more common to work in an iterative fashion. As a feature or page is added, the customer double-checks this is what they want before work continues. It's much easier to change course and the end product turns out to be much more useful for everyone.
Acceptance tests are usually automated scenarios that both the developer and customer can use to confirm everything works as expected. Here's an example:
- A new user reaches the site
- They create a new account
- After confirming their account via an email link, they can successfully log in
Wouldn't it be cool to have a bunch of these scenarios guaranteed to always work for you?
Now that you know automated testing is a real possibility, I'd love to hear what your developers think. Did you receive any pushback? Were they glad to hear that you value testing? Drop me a line and let me know :)