Lean Software Testing
How to get started with automated testing in your web application
It’s only after a web application has proven its value that automated testing feels like a good idea. What use is well tested code that doesn’t produce a return?
So you start without testing. In the beginning, your only goal is to build and see if it’s worth continuing. Progress happens quickly, habits are established, there’s incredible momentum and the value provided by the app becomes more clear.
Then it happens slowly. The progress slows down. Each new feature interacts with every feature already written, causing unforeseen side effects. Releasing new features used to be easy, but hard lessons have been learned and now deploys are treated with a greater reverence. Building test coverage now feels like a monumental task. So where do you start?
After building automated tests for existing web applications for almost a decade, we’ve developed a strategy outlined by the 4 steps below that will maximize your benefits with the smallest investment of resources.
- Test like a user. Use full integration tests.
Integration tests operate as a programatically controlled web browser that clicks what your user clicks and tests that the full application works as your users experience it. You will eventually add unit testing for the smaller parts, but since you have little to no testing you’ll start by casting a wide net and catching errors at any level of the stack.
- Focus on value
Knowing what to test is vitally important with limited resources, so you should focus your tests first on only the most valuable parts of the application. For an e-commerce store, this means test your product information pages first. For an online magazine, you’ll test the article pages first. The value produced by your application is more important than the revenue it brings to the business.
- Then focus on revenue
Only after the parts of your web application that create user value are tested should you develop tests for the revenue producing part (if applicable). The thinking here is that a web application that creates value but cannot process payments produces fewer losses than a web application that can process payments but cannot create value. If you have to choose your failures, make sure your customer fails last.
- Eventual coverage on everything else
With the tests above in place, your development team needs to establish a no-exceptions rule to test all new code developed for your application. In the long term, this brings full test coverage to the rest of the application.
As a team, we’ve used the strategy above successfully in web apps since 2009 to transform “scary” codebases into reliable and stable business assets.
If you’d like assistance in building a solid test platform for your web application, submit your app for a free quote at agileasaservice.com