I recently finished reading Blink. It’s about how we are programmed to make quick decisions. The driving force behind prejudices, but also our inherited ability to make quick and accurate decisions.
It’s funny, the book was mentioned in an episode of “In treatment”, and 60 seconds later I had purchased the book and had it on my Kindle.
Malcolm describes how we all make initial assessments of everything and everyone. The book explains when this ability is not to be trusted and when it is to be trusted.
I found it especially interesting how, for example packaging can change our entire perception of a product. It also explains how we often let our first impression of a person unconsciously affect our interactions with that person.
In essence the book is about decision making, a process that I’ve find to be hard to capture in text. It’s an interesting read and very inspiring, but it is more of a food for thought book than a practically focused guide.
I finished reading Agile Testing, on the recommendation of Mary Poppendick. It’s a thick book, and it took me longer to read than I originally thought it would.
I found it too long, to be honest. It covers both testing and agile principles. For me a better fit would have been if it only focused on testing, implying that I am not the target audience. For the Agile part I would recommend other books on the subject.
The testing parts, however, worked as a muse for my thoughts. It wasn’t long before I was thinking of how I could apply the different aspects mentioned in the book. For instance the book suggests that if the test suite start taking too long to run, it could be split into a quicker suite run each check-in (or my preference each compile) and a longer suite that runs in a build. I realized that most teams I know of would have a hard time splitting their test suites up into quick feedback suites run each time the code compiles and a longer list which run each night. This ties back to some of the problems with TDD where early practitioners risk just producing test after test without considering their value.
Another idea I had while reading the book was that it could be quite easy to produce a test suite for a REST-api using curl and a set of script-files. This suite could easily be automated as well, without need of much programming experience. Then again, it’s not difficult programming either.
The book suggests thinking of different types of tests as features are implemented. Which is good to have as a sort of checklist, and I agree that features should be considered from as many angles as possible for risks or if they can be implemented simpler. However I do not see this as a tester activity or a “programmer” activity. I see it as an obligation for everyone in the team. I do greatly agree with “the power of Three”.
I believe that the book could have been shorter and more concise. Also I could argue that the book isn’t a practical guide, but rather an introduction to agile testing. With this I mean that you shouldn’t expect concrete examples of how to set-up an automated regression test suite. It will however greatly describe the benefits of one and suggest that not every test is suitable for automation (I can see how it’s easy to get carried away with automation).
Despite the fact that I didn’t enjoy the book as much as I had hoped for I would still recommend reading it. However I would recommend readers whom want to focus on the Agile processes to read other books on Agile instead of the chapters discussing processes.
When Mary and Tom Poppendick was in Stockholm a few weeks ago, Mary recommended the Checklist Manifesto by Atul Gawande. And now I finished reading it.
In general it was a good read. Since it’s American it tends not to be very concise, sometimes over elaborating or using constructs of words that could have been shorter. This is normal.
It describes among others how a Checklist somehow can unite the team for the task ahead.
Around chapter 6 it gets really interesting. It’s where it starts discussing what constitutes a good Check-list. Where it divides checklists into two different types: Read-do and do-confirm. To be used in different scenarios. The Read-do is a simple follow this checklist and do the things on it. The do-confirm list is a do some work, then verify that it has been done. In a team verification is done verbally.
It also explains how checklists are used in different industries. What I found interesting was the air-line industry that tests the checklists in flight-simulators. Which begs the question: When did you last execute tests on your software documentation?
The book also describes, among other benefits of checklists, how checklists can increase the communication in the team, by adding communication check-points. One thing that I found missing, was that checklists can help team-members to focus. By having items written down, they don’t have to worry about “not remembering them”, thus freeing up memory space for the task at hand. At least this is the Getting Things Done theory for checklists freeing up focus.
It’s remarkable, the results these checklists demonstrate when used in surgery. And for the question “Would you want the checklist to be used if you were the patient”, my answer is “yes”.
I just started reading “Getting things done” – by David Allen. I’m roughly 25 pages in, but now I have to stop to write this blog-post just to clear my mind.
The reason for why I started reading the book is that I found Tracks though mor.ph and started looking at their system earlier this week. The goal was to get some inspiration for creating more productivity enhancing features in RemoteX Applications. Tracks was interesting enough but I wanted to read the book to get some better insight into the ideas behind it.
The way Scrum, Kan-ban works is similar in the sense that it is a way to organize Actions, things need to be done.
What I miss so far from Getting Things Done is that the items on the team boards that I’m working on is also a part of the things I need to get done. It feels as if I’m missing a dimension. I felt the same way about the Tracks software earlier this week.
The book it self has already resulted in 5 blog posts, this included. Ill add one when I’m finished to summarize.
