Last Friday, I was pleased to have the opportunity to present on testing at my Local Perl Programming group.
First off, yes, I think it helps for programmers to learn about testing.
No, not just the idea of Test Automation or of Test Driven Development. I mean the actual hard stuff of testing – what test ideas to use, and making sense of what those ideas tell us.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Since I have an upcoming conference presentation on quick tests, I thought I would present on those, which got me thinking about presentations.
Your typical presentation might be ten minutes of introducing what quick attacks are, followed by thirty minutes of descriptions, followed by a little Q&A. It might educate, but it’s unlikely that a slide deck will inspire action, right?
So I ditched the slide deck.
Instead of powerpoint, I gave a very quick introduction to quick attacks, then I had the audience open up laptops and actually do some quick attacks against a website. Then we tried a second one; then we conducted a brief retrospective.
I think more user group meetings should be like that, and I’d like to do more writing about how to set them up. But in the mean time, would you like to follow along the lessons yourself?
For that matter, I’ll give you enough information to do the presentation yourself at a brown bag luncheon at work. Here goes:
Outline for a ‘quick Attacks’ hands-on session:
(1) My article “Ten Quick Attacks for Web Based Software” on SearchSoftwareQuality.com provides a simple framework for quick attacks. Put simply, they are techniques to attack any GUI software quickly, even if you don’t know the business rules involved. They’ll help you find bugs fast — giving the developers something to do (fix the bugs), giving your testers time to learn the business rules.
So you can start with briefly ticking off the kinds of attacks. (Who knows – shoot me an email, I might even make a powerpoint. No promises.)
(2) Next, I used a whiteboard to introduce the famous triangle problem. Basically: You have three inputs, and the software tells the user if the values are all sides the same (equilateral), two sides the same (isosceles) or no sides the same (scalene). It’s also possible that you have “not a triangle”, as the rule is that two sides need to add up to more than the third. So 1,1,1 is equilateral and 9,2,2 is not a triangle.
Then I sent the audience to a triangle test application to practice testing it. The little application actually puts your attempts into buckets, tracks how many buckets you ‘hit’, and, when you are completed, gives you a score. So you get to practice all those great tester skills like special characters and null inputs.
If you’re reading this in your cube, you can go ahead and try it.
(3) Then I sent the audience to test ParkCalc, a parking calculator in the Grand Rapids Airport which has quite a few bugs. No score for it, but if you google “ParkCalc” you can find quite a few write-ups. If you really want to get deep into ParkCalc, you’ll want to know the requirements – to understand if the dollar amounts charged are correct. You can find something approximating requirements here.
(4) Next I challenged the audience to try to hit the “high score” of ParkCalc; to see who can find the highest cost of rental. (Yes, this is a James Bach idea. How did you know?)
You could argue this is not a testing challenge, per se, but it is a good example of boundary value thinking, system modeling, learning and exploration — critical roles for testers.
(5) It’s time for a debrief and discussion. Hopefully, this kicked up a few test ideas for you. If you’d like more, I’ve got a handy copy of Elisabeth Hendrickson’s Test Heuristic Cheat sheet right here to give away. (Or you could splurge and get the coffee mug. I got a couple to give away at the conference. C’mon. You know you want to.) If you really want more, you might consider Mike Andrews and James Whittaker’s excellent How To Break Web Software. Or perhaps you might consider the 40-minute introduction to Quick Attacks that Dr. Cem Kaner gives as part of his free online course on Black Box Software Testing.
So there you have it. An outline for self-study or a brown bag where you actually do software testing.
I’d like to see more of these. If this was helpful and you are interested, let me know, I may do a post of how to find, create, and work with local user’s groups to try to build a culture where we both talk about testing and actually learn by practicing consciously.
I know. Crazy.