Do testers need programming skills in order to automate? What is continuous integration? What about continuous...
improvement? These are some of the questions that are answered by Agile ALM author, Michael Hüttermann, in this second part of a two-part interview. In part one Hüttermann explores types of automation and their uses in application lifecycle management. In this second part of the interview, Hüttermann digs more deeply into automation skills, build automation and continuous improvement to processes.
SSQ: With more and more automation in ALM workflows, do you think it’s necessary for everyone to have a basic background in programming fundamentals to be successful? Are there certain universal scripting languages that you’d suggest for the newbie?
Michael Hüttermann: I don't think that everyone in the project must have a basic background in programming fundamentals. Unfortunately, still today, many people reduce the complete software development process to coding, but coding is only a very small part of it. It is more important to have a comprehensive understanding of what is going on altogether. Agile ALM can help here. Concerning languages, I think it is more important that technical staff have a basic understanding of the target domain, not vice versa. The decision of which language to use should depend on the task you are trying to solve. It is hard to give general recommendations. As examples, if you work on build scripts, you should prefer Ant (or Maven) over plain Java. For writing enterprise applications, Java is still an excellent choice, or using other languages on the JVM like Groovy or Scala. Becoming Agile means to support and collaborate: if a non-technician has a good idea to automate something, the whole team should go after this idea.
SSQ: Continuous integration is the automation of the build process, is it not? What automated functions (for example running of regression tests, or automatic notification of build errors) need to be present for successful continuous integration?
Hüttermann: Continuous integration is the automation of the build process and has the goal to integrate activities of colleagues and the work items others produce. Actually, you should automate all steps in the build process. This can result in a build ecosystem where a new code commit directly triggers a continuous build including compile, technical tests, audits, package, functional tests and deployment. New executables should be available to the users immediately. Thus, it is essential to not only integrate continuously, but also to automate the deployment to test machines (or even production machines) and to automate code inspections. For me, all these aspects belong together. In a continuous integration process, build reports and notifiers should be in place as well. Sharing status and aggregating information are very important aspects. It is essential to have the team commit to the process.
SSQ: In your book you say, “In software development projects, a high process automation grade is a prerequisite to deliver quickly and in best quality and to get feedback from stakeholders early and often.” Explain what you mean by a “high process automation grade” and the top advice you have on how to achieve that high grade.
Hüttermann: The advice is that you should set up a continuous improvement process to review what you are doing, continuously. The prerequisite for that is to have an open atmosphere and a transparent as well as collaborative project setting. You should review your project setting at given times and identify bottlenecks or the most error-prone activities in your specific context. Then you should think about how to improve and give it a shot. In order to be able to measure what you are doing, don't try too much at once, especially if you are not sure if your actions will pay off. During the next reflection, you review the results. You may decide to again tune or to take the next most error-prone, time-consuming or annoying facet in your process. Improving an automation grade is a process, and it depends on individual requirements and experience to decide if an existing marginal benefit does not motivate any more automation in a specific area.
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.