A while back (no link cause I’m lazy), I mentioned that one thing (among many) missing from How We Test SW at MS was a bibliography of testing books. While we didn’t refer directly to any books when writing the book, the influence of several testing books is definitely there, and worth noting for those who want to study where the craft has come from (which is one way to better understand where it’s going). This post will now serve as the official bibliography of the 2008 edition of How We Test Software at Microsoft. That should get at least one nagger off my back.But First…
My bookshelf is filled with four different types of books (technically, three – one type is a subset of another.
- Business-ish books. I have (and read) a lot of books on leadership, innovation, etc.. I think these are important for all leaders and those who want to influence (definitely not just managers). These books contain the most read and most loved books in my collection – but none of them are included in this list.
- Books on thinking. I also read a lot of books about thinking and motivation. Examples include Michalko’s Cracking Creativity and Thinkertoys, Kahneman’s Thinking Fast and Slow, Pink’s Drive, and A Whole New Mind, Weinberg’s General Systems Thinking, and Chabris’s The Invisible Gorilla . I think books like these are a great resource for anyone who does knowledge work. A good way to push my buttons (as many of you know) is to take a nugget from a book like these (the gorilla is, of course, my favorite), and announce to the world, “OMG!!! THIS IZ JUSST LIK TESTING!!!!!!!!” These books aren’t in this blog-iography either.
- Software books. The final category is books about software engineering. Note that there are examples of software books that overlap into the above categories.
Please don’t ask where book “Foo” fits into the above categories. The category list above is arbitrary and I just made it up. I may change it later (or by the time I post this).
Category #3 above also includes books on software testing – and after an introduction that is now likely longer than I expect the list of testing books and notes to be, let’s get started. Below is a list of the software testing books that I believe have contributed in some way to my test education (and hence, my own teaching and the writing of HWTSAM), as well as directly and indirectly to many of my peers. In no particular order (other than the order you can find them on the shelf in my office from right to left):
- Software Testing Techniques by Boris Beizer. This book has a comprehensive overview of a whole lot of testing techniques. Some of them are good, some don’t apply, and some are complete bullshit. I tell a story about my journey with software testing books where I say, “When I read my first book on software testing, I thought I learned it all. After reading a second book on testing, I was confused. After reading a third testing book, I began to form my own opinions. For me, I don’t think it’s fair to determine where formal models apply and don’t apply until I really understood them – and this book gave me that background.
- Software Testing: A Craftsman’s Approach, by Paul Jorgensen. This is another book in the “comprehensive” category, and deals entirely with software testing techniques. Again, it’s an exercise for the reader to figure out the best ways and contexts to apply the techniques (and to filter out the bullshit), but as far as basics of testing goes, it’s one of my favorites. I know that Bj was influenced heavily by Jorgensen’s work, and I think it shows in his chapters on functional techniques.
- A Practitioner’s Guide to Software Test Design, by Lee Copeland. I hate to say this, because Lee occasionally reads this blog, but this is my absolute favorite book on the basics of Test Design. For me, it was so much easier to read than the Jorgensen and Beizer books (and the even Meyers book I’m about to mention), and I think it’s much easier for the reader to take the information in the book and apply it to their own work. I don’t recommend reading just one book on test design (see my comments on the Beizer book), but this is one I think is worth having on your shelf.
- The Art of Software Testing by Glenford Myers. This one is sort of the classic of software testing. It too, focuses on functional techniques (and introduces the classic triangle testing problem). Note that this book Ii s generally way overpriced ($130 on Amazon right now)– look for a used copy if you want to own it.
- Testing Object-Oriented Systems, by Bob Binder. I probably mentioned this book in the chapter on model-based testing. This is the book where I first studied MBT, and also the book that got me thinking deeply about test patterns and patterns in general (I was inspired by this book to finally read the GOF book, as well as Alexander). Note that this book can double as a weapon. It’s just under a zillion pages long, so I recommend reading it in chunks rather than in a single three-week sitting.
- Software Testing Techniques by Loveland and Miller. In a way, this book could be called How We Test Software at IBM – or, perhaps, Things you can learn from Mainframe Testers. This book came out just a few years before we began writing HWTSAM, and probably subconsciously influenced my decision to agree to think about possibly writing a book about testing at Microsoft. There are a lot of lessons to be learned from this book, and although it’s applicability to my world of testing has waned quite a bit in the last decade, there are definitely some nuggets here for anyone.
- This is the placeholder for something obvious I’ve missed. I’ve read dozens of other books on software testing, and unless someone has borrowed something significant without asking, I have to say that those are the most likely books that influenced my world view of testing – and likely what we drew from (at least indirectly) when writing HWTSAM.
Well… those six books and a combined half a century of practical experience from the authors, and a millennia of experience from the combined contributors.
2014 was an interesting year for me. The year began with the trailing two weeks of a four week visit to Australia. Then, I spent July and August in France, then took another week off when I returned to take care of my dad. Finally, I took the last two weeks of the year off to be with family. With other short vacation days thrown in, I took nearly 13 weeks off in 2014 (if my math is right, that’s a quarter of a year). Most of that time off came from an award I received several years ago that allows me a one-time eight-week vacation (a sabbatical of sorts), and I also used just about all of the five weeks of regular vacation time that Microsoft gives me.
I mentioned the above (in much shorter form) on twitter this week. In the discussion, I mentioned that I’ve been at MS for nearly 19+ years, and it’s a once in a career sort of thing, and Geir Gulbrandsen asked if I’d do an encore after an another 19 years. I answered that I’d likely be in some stage of retirement by then, and that led to a discussion on what retirement is…and it made me want to dump my thoughts into a form longer than 140 characters.
So here goes.
A lot of twitter folks said things like, “If you do what you love, do it forever” or, “I’ll never stop working if I enjoy the job”. I agree with these folks. Even in “retirement”, my dad worked for years just to keep from getting bored. I get bored easily too, and I really like my field of work, so why would I even think about retirement (in any form)?
Because I like things other than working too. I like to travel (actually, I don’t like the travelling part – I like being in other countries). Spending two months in a foreign country (or a month each in two different countries) isn’t something someone can do often when working a full time job. Or, I may write another book someday – but I know from past experience that I didn’t like the schedule I had to keep to work full time while writing. I may take a class. I may want to work in a winery. Who knows. All I know is that at some point in my life (and probably within 10 years or so), I’ll want to work much less than I’m working now. Somewhere in the twitter stream, I said (tweeted) this:
For me, “retirement” isn’t a stoppage of work. It’s a choice to work when I want, on what I want, and as frequently as I want.
— Alan Page (@alanpage) December 31, 2014
I’ve known that I wanted “retirement” options from the time I entered the workforce (as a middle school music teacher when I was 22 years old!). I’ve saved aggressively – maxing out my pre-tax 401k for the last 19 years, and contributing as much as I can afford to post-tax 401k over the past several years. I feed my IRA every year and save whatever else I can. The only debt I’ve had for the last two decades is a mortgage. And, although we went a little crazy with vacations over the last year, we travel cheaply, and save as much as we can while still enjoying life. To be fair, I’ve been successful working for a large company, so my income level enables me to save more than a lot of people, but the point is that I’ve tried to save what I can, so at some point, I have a choice to work – or not, as I choose.
Any sort of retirement for me is still quite a few years off. My kids are in school for another eight years, and will probably go to college after that (I started 529 plans for both of them when they were born, and I expect I’ll have enough saved to cover a large portion of costs for all but the most elite schools). The point is that I think a lot about what I need to do to get myself to a point where I can cover most or all of my expenses without needing to work.
But I’ll still work when I want to.(potentially) related posts:
I took some time recently to answer some questions about Combined Engineering, Data-Driven Quality, and the Future of Testing for the folks at the A1QA blog.
Check it out here.(potentially) related posts: