Until recently I hadn't paid much attention to the Python programming language. Let me get to my point quickly: I have become a big fan of Python. Python is a scripting language and at first glance it looks and feels quite similar to Perl. Python was created in the early 1990s but it has really taken off lately, driven in part by its use at Google where it is one of their main languages. Python is also used extensively at Industrial Light and Magic, Disney Animation Studios, and NASA. There are many online articles and blogs you can find which attempt to quantify in some way why Python is good, or better than some other language(s), but for me it boil down to the "does it feel right" criterion. And when I'm coding with Python, it just feels right. But what about Python for test automation? I don't have deep enough knowledge or experience to state a strong opinion, but from what I've seen so far, I think Python would make an excellent choice as a language for almost all types of test automation programs. When writing test automation in a Windows environment, typical tasks include unit/API testing (so you need to be able to access functions in a DLL file), UI automation (so you need to be able to access the Windows API set), network-related testing (so you need sockets), Web request-response testing (so you need HTTP methods), Web UI testing (so you need to be able to access the Internet Explorer DOM), SQL-related testing (so you need to be able to connect to databases), and XML-related tasks (so you need XML parsers and other tools). As far as I can tell, Python has excellent libraries for all of these tasks with the minor exception of being able to access the IE DOM directly (although you can get at the IE DOM through its COM interface) .

I've been looking at the new PowerShell from Microsoft. You can think of PowerShell as a replacement for (or possibly an addition to) the old CMD shell and .BAT files (which in turn were a replacement for the original Windows COMMAND shell and language). My bottom line opinion: it's not an absolutely must-have-right-now technology but it's pretty cool and I think it'll make a nice addition to your personal skill-set if you work in a Windows environment. PowerShell (PS) was formerly code-named Monad. PS is a combination of a shell environment and a scripting language which can be used interactively or as an executable script file. The image at the bottom of this blog entry shows a demonstration interactive session. I use the set-location "cmdlet" to navigate to a folder and then search a file for the string "the". PS was originally was going be released with Windows Vista, but Vista's ship schedule is so complex, apparently Microsoft has decided to make PS available before Vista. From my initial looks at it, I believe that PS will be used by developers, testers, and system administrators in cases where .BAT files just aren't quite good enough (meaning awkward to write), but using a more powerful language like C# is a bit of overkill. For example, maybe you've written .BAT file scripts which have some significant branching or looping logic. You can do it using the GOTO command with labels, but that technique is a bit awkward. A particular task I've noticed that PowerShell seems to be especially useful for is manipulating WMI (Windows Management Instrumentation) objects to perform systems administration tasks.

If you want to track user activity in a Web application, you may want to determine who the user is. Of course this raises all kinds of privacy issues, but let's ignore those for now. In general, trying to determine a user with server-side logic will not work except in very tightly controlled, and usually artificial, environments. By far the most common approach is to ask the user to identify himself by typing a user name into a text box. Then you can store this information in a persistent cookie on the client machine. This approach assumes that the user has both JavaScript and cookies available and enabled. With a cookie on the client, you now have a way to ID the user. I ran across an interesting alternative to bluntly asking the user for his ID. In a pure Microsoft intranet network environment, you can use a very surprising technique to ID a user. There is a WScript.Network object which has a UserName property -- and it's actually callable from inside a Web page. The code would look something like:

<script language="JavaScript">

function getUser()

{

   var wn = new ActiveXObject("WScript.Network");

   var username = wn.UserName;

   return username;

}

</script>

This trick doesn't seem to be well-known because it uses a WScript object and these are normally used strictly in a shell environment. Unfortunately, most browsers these days have ActiveX disabled because of security concerns. Another alternative technique for ID'ing a user is to assign a random ID, and then storing that ID in a cookie. For example:

function randomUserID()

{

  var chars = "abcdefghijklmnopqrstuvwxyz";

  //var chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

  var slength = 5;

  var result = "x";

  for (var i = 0; i < slength; ++i)

  {

    var rn = Math.floor(Math.random() * chars.length);

    result += chars.substring(rn, rn+1);

  }

  return result;

}

This JavaScript function creates a random ID. Each ID is 6 characters (lower case 'a' through 'z') in total length and starts with an arbitrary lower case 'x'.

Consider the problem of tracking user activity while the user is working on a Web application. For example, keeping track of which hyperlinks the user clicks on, how long the user spends on various Web pages, and so on. This is a fairly tough problem -- there are entire companies who do nothing but develop and sell this service. Before I talk about some of the ways to track user activity, I want to address the question of whether this is software testing or not. In my opinion, the answer is, "it depends." Software testing usually means the process of submitting input to a system, grabbing the response or new state, and determining a pass or fail result using an expected value of some sort. Tracking user activity in a Web application normally does not fit this description. However, if we expand our view of what software testing is to more of a software quality concept, then tracking user activity is often a measure of quality -- if a user skips over important links (such as advertising perhaps), then you have an indication of low quality. And yes, there are "official" definitions of software testing, quality assurance, and so forth, from organizations such as the IEEE but (perhaps unfortunately) the majority of practicing engineers I know rely more on informal or intuitive definitions. OK, so suppose you want to actually track user activity, how do you do it? Well, there are several problems. First, how can you identify who the user is? Second, how can you determine what activity the user has taken? Third, how can you save this user-activity information?

My book editors tell me that the Ruby programming language is one of the fastest growing technologies. Ruby has been around since 1994 but ony recently has received a lot of attention. Ruby is not an acronym, it comes from the gemstone; Ruby was created to be an improved Perl, by making the new language 100% object oriented. I like what I've seen of Ruby so far but I'm guessing that Ruby's use in software testing will be relatively minor. More specifically, I suspect that Ruby's best use in software testing will be for testing Ruby applications and possibly non-Windows applications. For testing Web applications, Perl and JavaScript are excellent choices -- Perl because of its large CPAN library of useful code, and JavaScript because of its ability to manipulate Web browser Document Object Models. For .NET Windows applications, C# and VB.NET are great choices because of their ability to directly call into the .NET Framework (for example using System.Reflection, and the underlying data types). For non-.NET Windows applications, C# and VB.NET again are great choices because of their ability to use the P/Invoke mechanism to call the Win32 API functions. In other words, for these kinds of systems, there's no compelling reason to use Ruby. But for Ruby applications, Ruby is a natural choice as a test automation language. And for non-Windows applications (typically written in Java or C++), Ruby may in fact prove useful, mostly because as a scripting language, Ruby is generally quicker to write than a compiled language (although that depends more on your choice of editing and debugging tools than choice of language).

Because AJAX Web applications work asynchronously, testing them is tricky. The image at the bottom of this blog entry illustrates a technique which has proven to be successful in practice. A test scenario run starts by calling a program-defined function asyncCall() which lives in the test harness. Execution of function asynchCall() causes the Application under test to send an asynchronous XMLHTTP request to the Web sever and also calls a program-defined delay() function. The delay function loops while the Web server processes the request and returns the asynchronous response, probing the state of the Web application every so often. After the response is received by the client and the app state is updated, the delay() function finds the Web page state-change, and the test harness can examine the new state of the Web application to determine a pass-fail result. Then, a new asynchronous call can be made, continuing the test scenario. This process repeats until the scenario finishes all its steps, and the final state of the Web app can be examined, and results logged to a file or database. I've written this interesting technique up, and it will appear in MSDN Magazine in a few months.