Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Dietmar Strasser is director of quality assurance at Borland Software.

Q: Is the "traditional tester" a dinosaur, or are testers and test managers evolving?

A: Yes and no. There seems to be an increase in uptake of Agile across many businesses. If people chose to not adapt and change to this new way of working, they will become extinct like dinosaurs. Those that look at the change and see it as an opportunity to take their existing skills and apply them to this new process, those individuals will evolve and become very valuable to their teams.

Testers have a unique set of skills and experiences that can be lost if not carefully integrated into the team. The programmers tend to be focused on the technical solution, whereas the testers take in the big picture. Testers can really facilitate the communication between the customers and the developers by trying to capture examples from the customers that can then be turned into functional tests.

Testers have been accused of "making stuff up" -- every time they execute a test, it is under the assumption that the expectations are valid. In reality, the expectations don't have to be valid, they just have to be in alignment with the customer's overall expectations. That alignment is gained by bringing to the table very early on all the "bug hunting" questions that testers usually bring to end-phase testing. By injecting the question "how would we test this" into the customer conversation, requirements solicitation becomes a very powerful -- and much more effective -- process. Agile truly infuses QA throughout the development cycle and makes testers active counterparts to developers throughout the entire process. In Agile, testers move from being a quality gatekeeper to becoming a trusted expert on the team.

Q: What tool paradigms will rule in Agile?

A: In the Agile environment the tools need to be more lightweight. The paradigm shift comes from developers' interest in testing. It drives innovation to new tool ideas from a developer's perspective and taking into account the customers' involvement in Agile. As open source and tool vendors get on board, there's a real explosion that inject creativity and takes the tedium out of the testing job.

Traditional tools support a "test last" environment, but in Agile it's a "test first" situation. New tools will allow the expression of expectations in a technology-agnostic kind of way. It speaks directly to the problems you're trying to solve, and expresses the requirements as what needs to be accomplished at a business level. Then, rather than "translating" that business-level conversation to technical specifications, Agile tools actually hook that artifact to the code that connects to the software under test. It's a fundamentally different paradigm. The programmers are the ones creating this linkage, which drives testability into the software from day one.

This also creates customer readability of the test, which is another difficult shift for team members, testers and even tool vendors. Specification by example is the applied Agile principle for automated testing -- it takes a vague user story and provided examples of input and desired results that then create an executable framework. It infers what the software needs to be, based on anticipated real-life usage.

Q: What is the role of automation within Agile?

A: Automation becomes incredibly important as customers push to have a potentially releasable version of the software result from each iteration. The number of tests increases exponentially with each story, so much so that if the tests were done manually, the testing actually can exceed the length of the total iteration. It becomes imperative that you have the ability to automate the repeatable tests and performance regressions.

Automation also provides detailed documentation that is always up to date and current as the developing software needs to keep passing each testing iteration.

Q: Is Agile testing possible with globally distributed or outsourced teams?

A: Agile can work with distributed teams, but the whiteboards, post-it notes and index cards of co-located Agile teams need to be adapted. Additionally, self-managing teams make several decisions and changes in "plans" each day, and keeping everyone on the same page can become extremely challenging. Further, separate sets of boards and notes mean that managers and executives have no cross-project visibility. Distributed teams need a solution that gives all the visual impact and information import of the physical-board approach in a virtual package that is accessible from anywhere, at anytime, and that updates in real-time.

RELATED ARTICLES C Snippet #8 Multitouch Gains Momentum ASP.NET Gets Testable Adobe, Saleforce.com Team Up for Flash Builder for Force.com Other Voices: 8 IT Predictions for 2010		TOP 5 ARTICLES No Top Articles.