Automated Testing Enables Agility
Automating tests at the unit and acceptance level are the “grease that helps the wheel turn” on Agile teams. Does automated testing take extra time? When you’re first starting, yes. However, you must consider automated testing an investment that will bring significant returns in the medium and long term, at the expense of some short term effort.
If you make that investment, you will find:
- Technical Debt will be much lower because developers will be able to make required changes to the code with the safety net of automated tests
- QA people will be much more confident in the product, and will be able to execute regression tests much more often, resulting in a substantially higher quality product
- The whole team can accommodate business changes much more easily, because they are spending considerably less time fixing defects
So put simply, automated tests enable your team to be agile.
Developer-level Testing
Testing at the developer level is used to provide tactical verification of the software, i.e. at the class and method level. Developers write tests for individual methods, working at a very low level with the code. This is also sometimes referred to as Unit Testing, however that term has certain connotations that came with it from more traditional software development processes. So, we prefer the term Microtesting in order to better communicate the level and scope of the activity.
To support developer testing, there are many commercial and open source testing frameworks available. The most popular are generically called ‘xUnit’ (from names such as JUnit for Java and NUnit for .NET), which allow the developers to write their tests in code that can be executed with a single click of a button.
A comprehensive list of the available developer testing frameworks for numerous languages can be found on Wikipedia.
Story Testing
Story Testing is the more strategic level of tests used for a system. These tests verify that the User Stories have been implemented as required by the Customer. Ideally, these tests are automated in order to provide an easy way to verify the state of the entire system. Note, however, that “through the GUI” record and playback testing tools are not recommended for this purpose since their tests tend to be quite brittle in the face of a changing user interface.
Story tests may be written using tools such as xUnit, FIT, FitNesse, Selenium, Watir, RSpec, Cucumber, and a number of other open-source and commercial tools.
Integration Testing
Integration testing is a more controversial subject in Agile circles. There are some who believe that the investment of time and effort that goes into creating reasonable tests doesn’t come with a good return. Integration tests tend to take much longer to run, and thus are less likely to be executed. Furthermore, the functionality covered by the integration tests should ideally have already been covered by the Story Tests.
Where Integration Testing does have merit is when Agile techniques are being applied to existing systems with a significant legacy code base. The Integration Tests form a foundation from which the developers can safely build new functionality.
These posts may also be interesting...
Smaller User Stories?We are the Borg
Every little thing
What problem are you trying to solve?
There’s a new look around here
Product Management
comments powered by Disqus