This series of articles is for business owners and product managers with a small team of contract or full-time developers who build software products of all kinds, and who want to increase product quality, increase confidence in the product, and get time back from repetitive manual testing to focus on more important work. The series outlines a methodical sequence of actions to help you develop a plan for a prioritized test automation project, which can be implemented quickly, and will help you to gain confidence in your product’s most valuable features, and reduce manual work in the shortest amount of time.
A Scrum development team (of which I was a member) was working on web app to help distribute scientific data about polar ice. The team would deliver new features and bug fixes to the Product Owner each sprint, and in each sprint demo the PO would what seemed like ten seconds to “break” the app. The team’s PO was regularly (and reasonably) unhappy at these results, and the developers were regularly (and reasonably) unhappy at being the cause of visible unhappiness. The most frustrating part: these weren’t new defects. They were the same things, cropping up time after time, evading fix upon fix.
The PO could break the app so quickly because she was running through the same few test cases, ensuring the most important aspects of the app were working. So focused on making each new feature, the development team were changing existing code and inadvertently causing regressions.
Several months later, we had turned the situation around. We were delivering features more reliably, faster, and with lower defect rates. The Product Owner was proud to demo the software. What did we do? Amongst other things, we invested heavily in our automated tests.
Maybe you are experiencing similar problems:
- Low confidence that new features have not broken existing features.
- You spend hours each week running through the same steps to check your app is working.
- Every so often, you receive a flood of customer support calls because a new release has broken important functionality.
- “Well, it works on my machine…”
If these sound familiar, this series of articles will give you some tools to help.
You don’t need to be repetitively testing the same scenarios over and over, nor do you need to worry about whether it works on one browser or platform, and not another. You don’t have to repeat over and over what the most important, most basic product features are to every new developer to work on your product.
You can build an entirely automated system that will check that your most important features work all the time, on all platforms. The system can check that new features work the way they are meant to, and that they continue to work that way. These checks can run every time a developer adds a new feature or changes any part of the code, and your team can be notified of bad results the second they’re detected. You can even flag software builds that introduce errors to not be released.
Next: “Designing your first automated test plan”.