I won't nag you about reading the newsletter every time it comes in,
but I will mention that you can find past issues at
http://tejasconsulting.com/#news
in case you've missed one. That's also where you can find this issue in
html format. Another reminder about the faught@asqnet.org forwarding address
that's still getting a lot of mileage - it won't work for much longer,
so please make sure you have faught@tejasconsulting.com in your records
as the best way to contact me.
Once again thank you for your kind words about our book.Stephen D. Poe (http://www.nautilussolutions.com) sent comments on the May feature "Watts Humphrey on Teams."Giving credit where credit's due: I was first educated to the concept of "page abandonment" by Alberto Savoia - Chief Technologist @ Keynote Systems and author of the forward for the Web Testing Handbook.
Cheers
Steve
Time Estimates - To counter Humphrey's comment: "But because the team has the data to back up their estimate, he hasn't seen a single case of management rejecting the plan", I've seen them rejected about 75% of the time. In most cases, management already has a release date in mind. It's usually marketing or investor relations related, such as "It has to be launched at the MegaComputer Show in November." or "It has to be launched before corporate year end." In these cases, I've presented project schedule estimates with detail and they were ignored. It didn't matter - then needed it out by their date, and that's what they expected. They weren't engineers, didn't understand software development, and didn't care. I don't work for any of these people any more.Sounds like further study of the Team Software Process is warranted to see if it merits Humphrey's claims of getting estimates accepted. By the way, while Humphrey was in town, I asked if he could provide some information to STQE magazine for a sidebar. The results are in the July/August issue on page 44 (the interviewer was Alyn Wambeke), where Humphrey provides another anecdote about negotiating schedule estimates.Overall, it is probably unrealistic to believe a small to medium size company will implement CMM. I'll be interested in exploring Humphrey's PSP and TSP more to see if they are viable candidates for such companies.
Thanks,
Stephen
Comments from my readers, whether negative, positive, or orthogonal,
are always a treat. You can contact me at faught@tejasconsulting.com.
I have added a tool review bibliography at testingfaqs.org that might interest you. It's at the bottom of the page at http://testingfaqs.org/t-other.htm. People often ask me how to find test tool reviews, so it made sense to make a list of where to find them. Some require ordering back issues of magazines (a cheap price to pay for a good review), and others I'm adding shortly are available for free on the web. If you know of other tool reviews that should be added to the list, please let me know.
Also on the subject of tool reviews, Elfriede Dustin tells me that her
upcoming book Quality Web Systems includes an appendix with reviews
of tools from Mercury, Rational, Empirix, Compuware, and Segue. The reviews
are comprehensive, not focusing only on web testing. I suspect that this
will become a very popular item. The book is scheduled for release in August
and is now available for preorder.
What's on your tool belt? Can you whip out a scripting language at a moment's notice to take care of a mundane chore?
Many testers don't have programming skills. For those who want to pick up some basic programming skills, scripting languages can provide a relatively easy platform to learn, and people can benefit from the power of scripts soon after starting to learn how to use them. Granted, some testers don't have a desire to be programmers, and there are roles for them to fill. But testers can make themselves more useful if they have some programming knowledge, even when it's not in the language that was used to implement the system that they're testing.
There are three scripting languages that I've found especially useful, and I'd like to introduce them to you - shells, expect, and perl. The shells are really a class of languages that include Unix shells such as sh, csh, and bash, plus DOS batch files, and many other options. They give you some basic control structures, and the ability to call upon the utility programs that are present on the system. Every operating system has a set of shells that you can rely on being available by default, so you don't have to worry about whether they're installed. No matter what system you're on and whose tool belt you're borrowing, you can rely on having a shell interpreter to do some basic automation. With some extra work and careful programming, you can even make shell scripts portable across different operating systems. I was delighted to find that the Cygwin environment includes several Unix shells that run on MS Windows, plus a nice collection of utilities that you're likely to call from a script.
Not many people need to automate interactive command line programs. But those that do should be aware of "expect." The name comes from old modem dialers with send/expect command pairs that would "send" a command and "expect" a particular string in response. Expect sets up a pseudo-terminal in such a way that the program can't really tell that there's not a real user tapping away on a keyboard on the other end. I've used it to implement a sophisticated reliability test that simulated many users doing everyday things on the system, including random typing delays, typing errors, and with some effort, some full-screen programs like text editors. Expect is available on most Unix variants and also MS Windows NT-based systems.
My favorite scripting language is perl. I can use perl to do most of the things that expect and the shells can do, and I can also use perl to do just about anything that can be done in compiled languages like C and C++. I've used perl to implement large high-level test harnesses, all the way down to individual test cases. Perl is available on a very wide variety of platforms, and perl code tends to be more portable than shell scripts, because shell scripts rely on external programs to do most of the work, each of which can introduce incompatibilities.
Scripting languages are very useful for test automation, whether the test harness itself is a script, or whether you use a script as glue to make a commercial test tool work better in your environment. But test automation doesn't necessarily mean automating test execution. I'll wrap up with a perl one-liner that I've used on many occasions (this uses Unix shell syntax here, but it's similar on other systems) -
perl -e 'print “\0" x 1000000' > fileThe code doesn't even have to be saved in a file - it's short enough just to type in on a command line. This code create a file that contains a megabyte of zeros, and it does it in the blink of an eye. What in the world would you do with such a thing? Why, test data, of course! When I do exploratory testing, I like to push the program's boundaries. I've crashed a word processor with it. I've rendered an operating system unbootable, and many other nasty things. I love to copy huge strings into the clipboard and paste it into unsuspecting places. You didn't really think I would just lean on the keyboard to get a long string, did you? Then I wouldn't really know how the string was.
Are zeros not enough like real data? Just print out a different character (this is where it's useful to use a shell that lets you recall a previous command and edit it). Once you get a failure with a megabyte or more of data, you want to see if you can do it with only 10k, right? Delete a few zeros, run perl again, and try out your new data file. I've isolated failures down to the exact minimum file size required to reproduce a crash, with only a handful of iterations.
So hang a few scripting languages onto your tool belt, and be on the lookout for where they can help you do your job.
#####
| Back to the newsletter index | Back to the home page |