"'Agile' is a natural way to develop good tests," according to Hans Buwalda, CTO at LogiGear Corp., a software testing company in Foster City, Calif. The result of agile test development will be better and more aggressive tests, he said, particularly for what he dubs "jungle testing" -– testing a system for unexpected situations.
In his presentation at the recent Software Test and Performance Conference in Boston, Buwalda said many tests today are mechanical, blindly following the specs or requirements. As a result, they are not that aggressive.
"Agile is just about the only way to develop good tests," he said. "And you can use agile test development even if you're in a waterfall environment."
Moreover, he stressed that testing in an agile environment is different than agile test development.
With agile test development, similar to agile system development, face-to-face communication and frequent communication among team members is important, as is breaking down testing into smaller chunks with more frequent iterations, he said.
"If there was one thing I should scream about, it's to come out of our cubicles," Buwalda said. "Rooms with whiteboards are good for test developers."
Testers have to understand the "business under test," he said, which is where agile comes in, which favors frequent interaction. Tests, Buwalda said, are a natural means of communication with users and stakeholders to capture agreement and meaning on the specs, as well as the business and functional requirements. This type of test development requires management buy-in to allow testers to be creative.
With agile test development, tests are developed in small units, independent from the system and each other. Test development needs to be sensitive to the overall planning, and it needs to be flexible, he said.
Separate test development from automation
Although agile test development typically utilizes automation, Buwalda stressed that testers should focus on the tests, not the automation, and, in fact, should separate the tasks of test development and automating the tests.
"Tests are developed whether they're automated or not," he said. "You can automate actions any time in the process by an expert in automation. Automation should not dominate; it's not an 'agile automation' project."
In addition to separating tests and automation, Buwalda made these recommendations to implement agile test development:
- Have a global test design, and keep it short and simple. And be prepared to revisit it during the project.
- Separate test objectives and test cases.
- Create and train a flexible, multi-discipline team. Use stakeholders, but focus on relevant tests. "Don't bother stakeholders more than necessary."
- Use a keyword-based approach to test development and automation. With this approach, tests are written as a series of keywords and arguments, which allows non-technical team members to write tests.
- Use "Soap Opera Testing." Buwalda explained, "Define tests as soap operas; with a small story you can make a lot of criteria, and you can test a lot of things quickly. It's fun to do in a group, and you can conquer a lot of objectives with a small set of test cases."
Most important, he said, "Go talk to people, go talk to each other, do it in iterations, and do it in small pieces."