turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
In the 1990s a craze swept the software development world. It was called Rapid Application Development (RAD). (Read more about it here.) RAD was so widely adopted that, ironically, we don’t talk about RAD anymore. Almost all application development these days uses a RAD approach. At the time, though, RAD was considered a useful approach for the prototyping stage of a new product. But once the development entered the mainstream, most organizations reverted to conventional approaches for coding software. For example, a developer might use a tool like Visual Basic to prototype a new GUI application. The resulting semi-operational prototype could then be used for finalizing the specification and getting customer feedback. But the final application would often be written in Visual C. Of course, once a customer or product manager saw a nearly functional prototype, they were impatient to get the product itself.
This approach drove the development and enhancement of RAD tools, until they were good enough for full production use. As a result, most GUI developers today use sophisticated visual layout tools when creating production applications. Many software designers use UML and other CASE tools in a mode that generates actual production code.
In the testing world, we need the same thing to happen—though it would be called Rapid Test Development. The laborious process of hand-crafted scripting of automated tests has to become part of the past. Developers and testers want—and need—visual tools to help accelerate the testing and test automation process. Just like with RAD, though, these tests cannot be mere prototypes. They need to achieve the same maintainability, portability, and sophistication that one would expect from a well-scripted automated test. We just want them faster and more easily shared with others.
Rapid Test Development is just a buzzword. In fact, just like RAD, I don’t expect this term to ever take off. In five years, we’ll look back and realize that at some point everyone agreed that this is just the way testing is done.
This approach drove the development and enhancement of RAD tools, until they were good enough for full production use. As a result, most GUI developers today use sophisticated visual layout tools when creating production applications. Many software designers use UML and other CASE tools in a mode that generates actual production code.
In the testing world, we need the same thing to happen—though it would be called Rapid Test Development. The laborious process of hand-crafted scripting of automated tests has to become part of the past. Developers and testers want—and need—visual tools to help accelerate the testing and test automation process. Just like with RAD, though, these tests cannot be mere prototypes. They need to achieve the same maintainability, portability, and sophistication that one would expect from a well-scripted automated test. We just want them faster and more easily shared with others.
Rapid Test Development is just a buzzword. In fact, just like RAD, I don’t expect this term to ever take off. In five years, we’ll look back and realize that at some point everyone agreed that this is just the way testing is done.
 | Kingston Duffie is the founder and CTO of Fanfare. Learn more about Kingston >> |
You must be a registered user to add a comment on this article. If you've already registered, please log in. If you haven't registered yet, please register and log in.