Testing the Limits with Gerald Weinberg

Gerald M. WeinbergIn 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.

Essential Guide to Mobile App Testing

Comments

  1. RJay says

    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

    Gerald hit it right on the head. This is always the same, when we get a production bug. Everyone blames it on the testers. No one talks about the time estimate cut that was done on test to deliver quickly, or the risks that the testers had highlighted on areas that are not being tested (due to lack of time) or even the simple “Not ready for production” statement given at the end of a testing cycle.

    As a Test manager, it sometimes makes me laugh when everyone comes back to me with the same question “Why didn’t the test team catch this bug”?

    My question back to them is; how can testers catch a bug that exists in an untested area.

  2. Dayle says

    As an ol’ grey haired guy, it is refreshing to read Gerald’s thoughts. Do I think testers should know how to code? No. Do I think that the testing team would benefit from having a coder on the team. Absolutely. I have always believed, unless you are a full time software engineer you do not belong down in the code rooting around however. It is better not to really know what happens down there to make your widget accomplish its task. If it is broken, write it up, and move on. You are paid to test. And as we all know, there most generally is not enough time available to do that!

  3. TOm says

    The most insightful comment, to my mind, in this interview full of insights, is that the most vital skill for a software tester to have is courage. As a senior tester, I have found that that is what most separates great testers from mediocre ones.

  4. says

    Gerry says …Yes, poorly managed organizations seem to have no trouble finding new areas in which to mess things up.

    You hit it right on the nail Gerry :)

  5. jmags512 says

    Would like to hear Mr. Weinburgs thoughts on:
    - Differences between IV&V and testing.
    - Impacts on quality/testing/IVV when using Agile.

    The only way to convince management of the importance of testing and IV&V is to clearly quantify the risks/impacts of lack of testing. Emphasis an overarching quality management view, it’s everyone’s responsibility. You can’t test it into a product.
    I’m sure I’m preaching to the choir, because we fight the same battles on each project. Slowly, very slowly the subject is getting attention.

  6. says

    Gerry says: “greatest contribution to the field of software?
    GW: I never invented yet another programming language.”

    Good stuff! – I know over the last few years, in various “job interviews/searches” – I am always amused that they desperately need someone with multiple years experience withwhat I have called YAPL (yet another programming language) – but are not looking at all for someone with “good programming skills”.

  7. rwilliams254 says

    “To me, the biggest weakness is not considering software testing anything but a (barely) necessary evil.” – Great line.

    I’m a QA Manager and have been at numerous companies where this is the thought process. My last company had 32 developers and (what we ended up with was) 2 QA. Dev spots would open up and management would fill it with more developers. It’s no wonder the “quality” of company work has declined over the years.

    I love the phrase “don’t worry, developers can test their own work.” The last time I wrote anything I gave it to someone else to check it: content, punctuation, storyline usage, etc… It never ceases to amaze me that management (or even dev managers and IT directors) can’t get that through their heads.

  8. says

    Awesome! Looking forward to the books about experiential teaching/learning (as I have since you first mentioned them to me Jerry). Good to know they are in the works.

    I recently re-read Klas Mellander’s book “The Power of Learning”, on this topic. Mellander co-founded the company Celemi, which creates simulation games of all kinds.

  9. says

    I like Jerry’s books and have always found them very informative. Being a consultant myself I know the value of varied thinking but also realize that foundational principles withstand the test of time.

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *