Jon has made performance and scalability testing the focus of his career since 1988. He has completed hundreds of engagements encompassing thousands of tests against applications from every major industry and then some. To him, technology is a playground to which the rules of the game are constantly changing... Jon works out of the Arizona office (360+ sunny days a year; sorry east coasters) and lives in Goodyear with his wife and son.
Point, Click, Done!
How far from the truth is that? When it comes to sophisticated performance testing tools, and even the not so sophisticated ones, how many times has anyone been able to just use the out-of-the-box functionality of a testing tool to accurately and thoroughly test an application? Let me guess at this... (thinking) (thinking) (thinking)... None! Ok, in all fairness, there are rare instances when someone tests a simple application, really simple (like a static web site). Anyway, here is my thought as I was flying home from a recent mentoring engagement.
Actually, this applies to all of the tools I use or have used. They all pretty much have the same base functionality. They record, they play back, and they have some form of programming language (compiled or interpreted). The implementation of these functionalities differs, of course. Regarding programming related functionality, in most cases if a specific functionality is not there, you can usually program around it (yeah, right!). For the newbie’s out there, programming around it only applies if you know it is something you need. This is all well and good, but what I was thinking about was the fact that I need to keep programming (or using) the same custom functionality.
Specifically, since the mentoring I was just doing was against a web application, I needed to use custom code functions that are typical and customary to doing web testing. For instance, pulling a list of values from a listbox, randomly picking one and using it in the next request. What about a function to randomly pick a link on a web page? Wouldn't it be great if there was a function that performed this act that comes with the test tool? Of course there are always unique situations for each application that will require custom coding, but the typical things like I just mentioned would serve 2 purposes. First it is code you do not need to maintain or carry with you (importing) and second if it is coded into the test tool itself, it would probably be just as efficient or maybe even more efficient than your custom code (assuming the tool vendors have the right programmers and/or you’re not dealing with interpreted script code).
This blog entry was geared towards newbies since I was recently training people new to these tools. They were all programmers in some form or other (very technical, which is always a pleasure when teaching a technical subject). So for typical code neccessities, let’s have the tool functionality built in. But for custom code – hey, all die-hard programmers out there, we all love our own code creations, right? (wink, wink)
Posted by Jon Harris on Monday, July 16, 2007 5:58 PM EDT
Leave a comment