Automation is often considered one of the key factors in a successful agile ALM deployment. In part one of this two-part interview with Michael Hüttermann, author of Agile ALM, we’ll explore more about the benefits and pitfalls of automation in application lifecycle management.
SSQ: In your book, you say that automation is one of the major fundamentals of Agile ALM. However, there are many types of automation with some types being more effective than others. Which type of automation do you feel is most essential?
Michael Hüttermann: Automating the most error-prone, most repetitive and most time-consuming activities is most essential. Additionally, automation is essential in all areas where you are interested in an objective, reproducible result. Another good impulse to start with automating is if some parts of the process are not transparent for the team; you can only automate what you understand and are able to describe. Finally, automation helps a lot in areas where manual work is just annoying. The latter is the motivation behind why good developers automate repetitive aspects of their work all along.
SSQ: I’m presuming all ALM vendors will include automation of some sort. After all, it is the automation of a manual process that is what creates an application or a tool. However, automation of a task that is typically done manually may cause complication or a lack of flexibility. Are there specific aspects of automation that should be sought out when look at Agile ALM tools?
Hüttermann: Quite the contrary, automation can lead to improved flexibility by just automating the boiler plate activities. You are flexible if you get the same automated results continuously and you can step in if you detect any defects that the automated process makes visible. Besides that, in your daily work, you should focus on those aspects that really require human activities. Humans should not do the work of robots. Agile ALM tools should have an open architecture that enables you to add further tools or functionality. Agile ALM vendors cannot and should not automate everything. For example, consider build scripts: tools should be able to trigger existing build scripts. But it is not the one-stop shop Agile ALM tool suite that compiles the code; rather, it is the underlying solution that is already in place very successfully.
SSQ: There is some controversy in the use of record and playback automation tools to test the user interface of applications. Some claim that more of an exploratory approach is required. Others feel that the maintenance required to keep the scripts up-to-date are not worth the effort. What are your thoughts on this type of automation?
Hüttermann: Capture & Replay tools for UI testing can add value, but you should not rely on them solely. Captured and saved interactions are like source code; you must maintain the scripts, refactor and optimize them. Aspects of optimization include isolating tests after recording and making them robust for future changes. One example is to identify UI controls relatively, not by its absolute position that directly depends on other controls. Software is about changes, and the test scripts must be flexible enough to evolve, together with the software itself. Depending on the context, having a small set of automatic UI tests ready can help. You could use this as a sanity check that runs after every build or as a first quality gate in a staged build environment. Many projects use a lot of UI tests and they find it helpful, some even automate all their acceptance tests as UI tests. I think you need both good test coverage of technical tests and some coverage of functional tests. But you should always take care of slicing your tests adequately. For example, if you must drive a UI test and press a button on the UI just to test a database operation, then something can be improved for sure.
SSQ: Do you think the use of automation for testing will render manual testers obsolete?
Hüttermann: Definitely no. Many projects experience good results while approaching software development more comprehensively. A barrier-free approach can be the result of more integrating development phases as well as project roles. Whether testing is integrated or held as a separate phase, the engagement of skilled testers is often needed. Why? One reason is, you cannot automate all tests, for example, usability tests. Another reason is you need the expertise of testers to test the application and to set up and manage automation. Interactions and shared activities of development with operations is called DevOps nowadays. I think such an abbreviation is not necessary for the development/testing case: testers also “develop” the software. The bottom line is that it is about collaboration and communication.Read part 2.
Agile ALM by Michael Hüttermann is available through the MEAP (Manning Early Access Program) at Manning.com. Compliments of Manning.com is a 41% discount on the MEAP, ebook and pbook of Agile ALM. Please use promotional code: agilealm41 in the Promotional Code Box at Manning.com.