This past weekend I came across a brilliant short paper entitled, "Computer Science Education: Where Are the Software Engineers of Tomorrow?" at http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html. The mini-abstract of the paper states, "It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline. We examine briefly the set of programming skills that should be part of every software professional’s repertoire." This statement reflects what I have been seeing for years: university computer science graduates are coming to industry (meaning Microsoft) less and less prepared to enter roles as top-level software developers and test engineers. And I am certain that the widespread use of Java in college computer science curriculums plays a role in this problem. So, notice the title of this entry should probably be more along the lines of, "Java Considered Harmful to all of Computer Science" but I am particularly concerned about the area of software testing. The paper I mention above clearly articulates several problems with Java but they can be whimsically summarized by what my good friend Doug (a top systems developer at Microsoft) said to me last night: "Java takes the science out of computer science." If I were the hypothetical King of College Computer Science, in addition to classes in Calculus, Probability, Statistics, Discrete Math, Algorithms, and Data Structures, I would require all computer science majors to take at least one class in C Language Programming, and Assembly Language Programming, and C++ Programming, and a functional programming language such as LISP or Prolog, and a Language Survey class, and finally a modern application programming language such as C# or Java.

One of the problems in the field of software testing is that there is no clearly established core body of knowledge. Take the Poisson distribution for example. Should all software testers have a basic understanding of this distribution? I'm not sure, but I know that a rudimentary knowledge of the Poisson Distribution certainly can't hurt a software tester. Very few software testers I know have even the most basic knowledge of the Poisson Distribution and the closely related Exponential Distribution. The Poisson Distribution may appear in a system when there are items arriving over time. For example, consider user connections arriving at a Web site, or process requests arriving at a CPU. Here's a quick example. Suppose you know from historical data that a new user connection to a Web site arrives on average once every 15 minutes. And suppose you arbitrarily establish your standard unit of time as one hour. Here, the average number of arrivals is 4.0 per hour. This average number of arrivals per standard unit of time is usually given the Greek letter lambda. The probability of a specified number of arrivals, k, in the standard unit of time, is given by the equation lambda raised to the kth power times the constant e raised to the minus lambda power, all divided by k factorial. This equation sounds real ugly but is not really as bad as it sounds. I punched this example into Excel, computed the probabilities of 0 through 10 arrivals in an hour, and got the image shown below. So what's the point? The Poisson Distribution is an example of a topic that is hard to categorize in terms of whether it should be considered required knowledge for a certain skill level of software tester. Knowing about the Poisson Distribution would certainly help a tester better understand load and stress testing. Additionally, the quantitative techniques associated with understanding the Poisson Distribution can be useful in many other software testing scenarios. A few months ago I wrote an article for MSDN Magazine where I described three probability related techniques and algorithms I feel are essential knowledge for all software testers: generatin pseudo-random numbers, analyzing a pattern for randomness, shuffling a list of items, and generating numbers from a Normal/Gaussian distribution. See http://msdn.microsoft.com/msdnmag/issues/06/09/TestRun/. But this particular "knowledge of the Poisson Distribution for testers" scenario is analogous to education in general: some topics are directly necessary for a particular goal/major/degree, some are peripherally useful, and some may not be useful at all.

Last week I developed a mini-class on an introduction to Windows Communication Foundation (WCF) for engineers at Microsoft. One of the hardest parts about WCF is not so much the technology, but rather understanding exactly what WCF is. One way to think of WCF is as a generalization of Web Services. Let me explain. Suppose you have a normal Web Service which contains Web Methods which expose some proprietary data in a SQL database (think book information for example). In a normal Web Service scenario, a client program (usually Internet Explorer) makes a request for book information using SOAP over HTTP to a Web Server which in turn queries the Web Service which is usually being hosted by IIS. The Web Service fetches the requested data and returns the data to the client using SOAP over HTTP. Well in some sense WCF takes this model and gives you options at every step of the way. The basic idea is the same: a client requests data from a server using SOAP and the data is returned using SOAP. But the WCF requesting client can be IE or any kind of program. WCF uses SOAP but the SOAP message can ride on HTTP or any kind of protocol. The WCF server can be hosted in IIS or any kind of service. Additionally, compared to Web Services, WCF gives you additional features such as transactions and enhanced reliability. The screenshot below shows a WCF demo from the training class I created.

 

 

So how do you test WCF systems? One the one hand you are still dealing with a request-response type of scenario so testing WCF systems is similar to testing Web Services. But because there are so many variables in a WCF system, your testing effort will be significantly more complex.