March 26, 2012 by 12 Comments
Copyright 2013 uTest Inc. 100
http://blog.utest.com/testing-the-limits-with-gerald-weinberg/2012/03/
In the latest installment of Testing The Limits we speak with Gerald Weinberg. Jerry has been practicing, teaching, lecturing, consulting, coaching and writing about software programming and testing since the 1950s. With decades of experience and accumulated knowledge he’s written more than 80 books and has dedicated his life to helping others be the best testers they can be – despite ever changing testing trends. In today’s Testing The Limits interview we’ll find out the biggest lessons Jerry’s learned over the years, how his books remain top sellers 20 years after their release and what the biggest issues facing testers today are.To keep up with Jerry visit his website or follow him on Twitter.
uTest: You’ve spent nearly 50 years working with computers and software in one form or another. Obviously, much has changed during this time, but surely some things have stayed the same. In your experience, what is the most notable “constant” in the world of software?
GW: The infatuation with the latest fad which is supposed to “increase productivity” by some arbitrary amount, with no clue as to how that “productivity” is measured. For the most part, these fads are usually a new set of names for old practices. Yet at the same time a segment of the developer population goes ga-ga over the fad, a much larger segment doesn’t even attempt to learn what is good about the fad. The majority of developers are working the same primitive way their predecessors did 50 years ago, just using more machine power to do it.
uTest: In a recent “testing roundtable” discussion, panelists were asked what they considered to be the biggest weakness in the way companies test software. James Bach and Cem Kaner both cited a lack of testing skills and a lack of means to acquire such skills. Do you agree? As a long time consultant, what do you think is the biggest weakness in the way companies test software?
GW: To me, the biggest weakness is not considering software testing anything but a (barely) necessary evil. Testing is seen as something that could be done by a troop of monkeys, so serious testers are treated like third-class individuals. The lack of means of acquiring testing skills arises from this attitude, as do most of the other poor practices in the testing business. You treat people as if they are stupid, then they will wind up acting stupid.
uTest: A good debate has recently sprung up on the subject of whether testers should be able to code. As an expert in programming (and testing) where do you stand on this matter? Are coding skills (or at least a base knowledge of coding) a requirement for good software testing? Are they a nice-to-have? Or are they totally superfluous?
GW: You can be a great tester if you have programming skills. You can also be a great tester if you have no programming skills at all. And, you can be a lousy tester with or without programming skills. A great tester will learn what skills she needs to continue to be great, in her own style.
uTest: We often ask our guests (and readers) what books influenced them most in their careers. Your book, An Introduction to General Systems Thinking, is almost always at the top of that list. First off, are you surprised at how well that book has held up over the years? (editor’s note: it was originally published in 1975) And second, what books and authors have had the biggest influence on *your* career?
GW: I’m always surprised and grateful when anybody buys and reads one of my books, but it was no surprise in the sense that one of my goals is to write books about enduring principles, not about the latest fad. My earliest books were about particular machines and languages, but then I noticed that such topics became obsolete in a few years, so I started looking for enduring principles. Since that time, all of those “general principles” books have all endured without becoming obsolete. For instance, my Psychology of Computer Programming was first published in 1971, and still sells vigorously. Our Review Handbook was first published in 1977; On the Design of Stable Systems (retitled as General Principles of System Design), in 1979; The Secrets of Consulting, in 1985; Becoming a Technical Leader, in 1986; Rethinking Systems Analysis and Design, in 1988; Understanding the Professional Programmer, also 1988; Exploring Requirements: Quality before Design, in 1989; and Are Your Lights On?, in 1990.
That’s 10 books that have each been selling well for more than 20 years, so, no, in that sense, I’m not surprised–and I won’t be surprised if more recent books are similar.
As far as my career is concerned, I have been influenced by so many books that I think you can best answer this question by examining the bibliographies found in my books.
uTest: We’ve noticed a recurring theme in some of your writing: corporate and bureaucratic obstacles to quality. Is it fair to say that the problems facing most organizations are rooted in poor culture, as opposed to poor processes? And does this dysfunction affect testing and engineering more so than other departments?
GW: Yes, poorly managed organizations seem to have no trouble finding new areas in which to mess things up. Poor management tends to propagate itself, and produces (among other things) poor processes. As for testing and engineering, they are awfully sensitive to poor management, but I don’t know if they are more sensitive than, say, marketing or any other function. Poor management can kill any business, in many ways.
uTest: The most vital skill for a software tester to have is ____?
GW: Courage. As Kipling put it, “If you can keep your head when all about you are losing theirs and blaming it on you.” That’s what testers need.
uTest: For readers who might not be familiar with your work, can you briefly explain what a “change artist” is and why is it especially relevant for software testers?
GW: Positive change (not the change we call “deterioration”) does not just happen. To foster such change, you need to have what great artists have–skill, training, experience, and a whole host of other things too numerous to list here. Take a look at my book, Becoming a Change Artist, for example.
uTest: It seems like many managers and executives today have a difficult time adjusting to new ideas and developments. After decades of expressing your views in books and articles, we’re wondering if you have ever changed a long-held opinion? If so, describe the process.
GW: It might make more sense to ask me, “Do you have any opinions that you haven’t changed over the years?” I do, but they have to do with the nature of people, not the nature of technology. Years ago, I thought punch cards were the last word in input. I thought that when I mastered sorting on magnetic tapes, I’d reached the ultimate in storage devices. I once thought that 2000 decimal digits was a vast amount of central storage. I guess what I’ve learned by now is that there is no ultimate technology, and if there were, I’d never live to see it.
uTest: You’ve written 80+ books and hundreds of articles. You’ve taught, coached, lectured and consulted in virtually all phases of the SDLC. At the end of day, what do you consider to be your greatest contribution to the field of software?
GW: I never invented yet another programming language.
uTest: What’s next for Gerald Weinberg? Care to give our readers a sneak peak of any new publications, speaking tours or workshops?
GW: For the past few years, I’ve been learning how to write fictional stories that carry the deep lessons about technology to an audience that prefers to read exciting, though-provoking stories, stories that are fictional, yet true. I’m also crafting a series of books on how to teach by experiential means, as we do in our workshops, rather than by lecturing.