There’s a new capability baked into iTest 4.0 that many of you might not notice at first. But once you discover it, I predict you’re going to find it pretty interesting. We call these “Quick Calls”.
The concept is fairly simple to explain. Any session profile can now have a set of iTest procedures associated with it. When you have one of these sessions open, you can search through available procedures and execute them. When you do this, a single action is captured – corresponding to the procedure you selected. If you flag one of these procedures to be for initialization, it will be called automatically when you start the session. In your test case, the dropdown list of actions for a step will now include these quick calls depending on the session associated with that step.
Okay. So is this a big deal? I think it is.
Have you ever had trouble with huge automation libraries – where no one knows how to use them, or even what is available to them? With Quick Calls, developers and testers can type in a keyword or two and will instantly see all of the procedures that might be relevant to their current session -- using documentation attached to those quick call procedures. And when they select one, iTest will show them all of the arguments (mandatory and optional) that they can use to control the behavior of those procedures.
Have you concluded that you can’t really use capture – because it tends to create big flat test cases, while you want to create highly structured and modular automated tests? Good news. Now you get the best of both worlds. Take a little extra time to create those reusable modules – as Quick Call procedures (using capture, by the way, if you want) – and then when you capture a test case, Quick Calls that perform these high-level functions translate into single steps to modular code.
Are you constantly having to “fix up” your test cases after capture – so that you get proper session initialization by calling some procedure to ensure that regardless of what state your box is in, the session will always get started on the right foot during execution? Well that’s the whole idea behind the support for the initialization quick call. When you start an interactive session during capture, you’ll end up with an “open” step immediately followed by a call to a shared procedure that will get your device into a known state. (It even helps you to avoid that work yourself when working interactively!)
I’ve heard a couple of people claim that Quick Calls won’t work for them because they are associated with a single session. But their procedures need to do work that is not necessarily associated with a single session. That’s where Quick Calls get very interesting. You can do anything in a Quick Call procedure that you can do in any iTest procedure. That means, for example, that in one Quick Call you can do all kinds of things – opening other sessions, interacting with a bunch of other devices, etc.
And, finally, here’s another tantalizing idea for how Quick Calls can be used. Suppose that you just want to organize a lot of things into a procedure library that others can easily access – but they don’t really relate to any one session. Can you use Quick Calls? Yes! I’ve done this myself now several times. You can just pick any session type for the session profile and use it simply as a container. In this session profile, you add the procedures that you want to collect together and make available for capture and replay. (If you’re familiar with Tcl, you might find the Tcl Shell useful – because it can serve as a simple UI for your session – where you can use various Tcl statements to help your users understand what is happening when they invoke your procedures.)
[Side note for software developers: You can think of Quick Calls as bringing object-oriented principles into iTest for the first time. Think of the session profile as a class declaration. The base of that class is defined by the session type (telnet, web, …) selected. The session profile inherits the built-in actions of that application. But now the session profile can also declare its own actions. Even more interesting is that when a session profile inherits from another session profile, it also inherits its procedures, but can add its own, too. (It can even override procedures.) So, if you’re an object-oriented guy or gal, you might think of the Quick Call procedures as the “methods” of the session profile. In future, we’re also looking at adding support for allowing you to extend the state information associated with a session.]
I predict that Quick Calls may have a big impact on how your team chooses to organize and share your work. Please reply and share your thoughts!
 |
Kingston Duffie is the founder and CTO of Fanfare. Learn more about Kingston >> |
