Seek, Identify, Gather… A model for talking about testing.

When I talk about testing I tend to talk about information. For me, testing is all about information. Information that helps decision makers make decisions, and information that informs risk. How we identify that information depends on the type of information we need, and to know that we can do several things… identify risk, ask questions, user research, analyse specifications, find out what’s important to those who matter; the list goes on.

Only recently have I actually thought about this as a model. So I thought I’d spend some time visualising it (something that helps me think deeper about a subject).

What testing means to me at a high-level:

testing

If testing wasn’t all about information, then it would be all about risk (generally speaking). So first up I like to talk about risk and risk identification. Testers (for the most part) are good at that. We tend to come with varied backgrounds; business, tech, users, and so-on. So we can view a product with many different lenses which provides greater risk identification coverage.

Then I move to the information required in order to understand and potentially mitigate the risk. The information we seek depends on the risk we’re trying to understand, as does how we seek and identify it.

Let’s visualise that part:

testing2

I then like to talk about gathering and reporting the information. Test reporting can be very painful, or it can be a breeze. Which one it ends up being not only depends on your stakeholders, but also on how you gather the information while testing. If you don’t record your testing (screen captures, notes, etc.) then how are you going to gather the information you need to report? Pass and fail? Whatever… realistically that means nothing. You need to work out what your stakeholders need (or in the real world, what they want) to see, and then gather the information in a way that translates as easy as possible to it. You may have a project sponsor that totally gets what you’re doing and completely trusts you, and so doesn’t need to see anything… but lurking in the background is the internal audit team who need to see EVERYTHING! So I like to include that when I talk about testing as it can make your break your entire effort (rightly or wrongly).

Thoughts? Feedback is always welcome.

Peace…

Time to step back…

If you align yourself with the Context-Driven Testing (CDT) community, or you’ve been a part of it in the past, then you’ve likely seen the flame wars on Twitter recently. If you haven’t, lucky you… don’t bother looking. Instead, just worry about doing good testing… whatever that means to you and your organisation.

I’ve remained silent for a few reasons:

  • In my opinion Twitter is absolutely awful for discussion/conversation, especially when there are more than two people involved.
  • I think many of the Tweets carry hatred due to personal issues/personality conflicts.
  • I think many of the Tweets are simply childish, like throwing the first punch and watching all your ‘mates’ deal with the aftermath.

I’ve seen awful words like:

  • Bullies
  • Asshats
  • Cowards

While these were not directed at me personally, they were directed at members of the CDT community in a very general and broad way. I therefore have included myself within their general and broad target. Rightly or wrongly, this is what happens when you label a community in such a negative way… the self-identified members take it personally (shocker).

This is me now raising my voice because I’m sick of being labelled in such a generalised way.

There are members of both ‘sides’ (I feel dirty even writing that word in this context) that simply need to grow up. If I witnessed my 9 year old daughter partaking in such rubbish I would educate her on how to handle it in a far more mature way. In fact, I’d be surprised if my daughter was even that bad in the first place.

Drop the elementary/primary school stuff folks, you just look silly.

What follows is a very personal story/experience report. I would like it known up front that I may also use generalisations, and if I offend anyone while doing do, I apologise.

When I first started out in testing I worked for a large organisation for many years. If you were to label their approach to testing then you may call it ‘factory’, or perhaps ‘traditional’. Whatever you label it, it was pretty damn wasteful for the most part. I spent 8 years learning how to test with that organisation and toward the end I began discovering that the way they tested could have been so much better. The turning point for me was reading Lessons Learned in Software Testing. This was my introduction to the CDT approach to testing (not the community – an entirely different beast).

After reading the book I then began to research more. I found more books, blogs, Twitter, LinkedIn, etc. I was then beginning to get introduced to the CDT community. After 8 years of ‘factory’ testing and no interaction outside of my organisation it was very refreshing. I met people (most virtually) that were making the same discoveries I was, other people that had called themselves CDT for years, and others that were ‘kind of’ in the CDT community and ‘kind of’ not. At the time I couldn’t have cared less what the people called themselves or what community they thought they were in… and guess what? I still don’t. If someone is willing to interact with me and help me make my testing better, I’ll interact with them. It’s true that most of the people I could find at the time were in the CDT community. Perhaps this was because there was no ‘factory’ community, or perhaps it’s because of where I was looking. I don’t care… and yes, I still don’t.

I naturally moved towards the CDT community and eventually self-identified as a member. This is an important point… I self-identified. I wasn’t initiated, welcomed, tested, approved, etc. I simply referred to myself as a member of the CDT community. If James Bach (yes, I’m using his name… like grown-ups do) had told me that I wasn’t a member of his CDT community, then I would have been a member of my own CDT community, with other like-minded people. You don’t need James’ approval. Sure, you can attribute a lot of what people understand CDT to be to James, but there are also MANY others who constantly contribute to it and move it forward… whether James agrees or not (and he’s the first to welcome that). Before I move on from James (because this is bigger than that)… yes, he can be abrupt, loud, intimidating, rude, and so-on… he once left me hanging on a Skype chat with “I thought you were better than that.” Ouch. However, I cannot dispute his testing intellect, passion, drive, work-ethic, and at times what appears to be pure genius. He’s not for everyone (from an interaction perspective), but you’d be silly not to at least research his work… even if you have to do so from arm’s length.

In more recent years I’ve spoken and written about the need for labels (i.e. CDT), and how I would LOVE them to not be required. I think this is partly because I can see the tension within the different ‘schools’ of testing, and the absolute waste of energy is causes – for the most part. Perhaps gradually I’ve been moving away from identifying myself or the way I test with a particular label. I just want to do good testing, or help to get good testing done. An unfortunate part of testing is the need for labels. If I want to differentiate the testing I do to the testing that someone else does, how do I do that without showing it (preferred option which is not always possible), or having a label for it as a conversation starter? Perhaps ‘good’ can be my new label. Then I can talk about what ‘good’ looks like/is in a particular context.

I’ve never been an advocate for “Can’t we all just get along?” I don’t think that is helpful when trying to move our industry forward. We need debate, different approaches, and different personalities who focus on different aspects of testing. How else would we make our ideas better? Self-critique can work, but other’s critiques are often far more powerful (never proof read your own work, etc.). However, maybe I’ve been looking at “Can’t we all just get along?” in the wrong way. We can all get along while debating and disagreeing on different approaches to testing, can’t we? Then again, we’re human. If getting along was that easy when we disagreed on something… well, news headlines would be a lot different.

After spending 8 years as a ‘factory’ tester, and almost as many in CDT, I think the time is right to move on from labels. From now on I’m going to be a tester, no… a good tester (or test manager, etc.). I’m sick and tired of the ‘politics’. I know they will never go away, and it would be ignorant of me to think I can avoid them in the future, but for me personally I think I can do way better if I put my energy towards good testing instead.

For those of you that will jump at the chance to declare me another victim being ‘pushed’ or ‘forced’ out of the CDT community, it couldn’t be further from the truth. No-one has done that, and the only person you can ‘blame’ (because some of you have to it seems) is me. Besides, while I won’t label myself, I’ll continue to interact with members of the CDT community (because most of them are awesome), and I really hope that I also interact with those that aren’t as well (because some of them seem awesome too).:)

I’m going to focus on good work and not the bullshit that often surrounds it. I’ll deal with bullshit when I have to, but no more excess energy will be spent on it. I’d like to continue helping others like Katrina has written about. For example, I started OZWST after my crew from NZ introduced me to KSWT… and I’ll continue to do cool things like that, but I will not make it about labels.

Peace…

Wonderful Words from Jerry Weinberg

Today I received some wonderful words from a man who has inspired many parts of my software testing career. Those words were in relation to my book, Software Testing as a Martial Art

“What a gift David Greenlees’ book is!

The day I received my copy, I spent all morning scanning, digging, smiling, nodding appreciatively. It’s a wise book, and I’m recommending it to all the testers (and others) I know.

But prepare yourself. This insightful book shows the reader that testing is like a martial art in a number of ways—ways essential for testers to understand. A caution though, about a way this book itself is like a martial art:

Beginners may simply not understand much of what Software Testing as a Martial Art has to say until they have practiced. Very few people begin their testing careers by applying principles they’ve read about, no more than I did when I began testing (or a martial art). So, though Software Testing as a Martial Art is a book testers should read at the beginning of their testing careers, it’s also a book they should re-read every year as their experience grows. I know I plan to re-read it every year on my birthday.

I also plan to continue my study of Aikido, my preferred martial art. Thanks to Software Testing as a Martial Art, I now understand that every Aikido practice will also improve my testing art.” – Jerry Weinberg

Thank you Jerry, I couldn’t be happier.

Tacit & Explicit Knowledge – Wha…?

tacit

Firstly I need to mention that I read this book extremely fast. Approx. 2 weeks is all it took, and for me that is a record. I think there are a couple of reason for this:

  • It’s a relatively small book – 178 pages.
  • I’ve been catching the train to work recently – reading time.
  • I was very keen to see what I could learn from it.
  • I would normally back track a lot while reading, going over paragraphs a few times to clear any misunderstanding. I didn’t do that as much with this book because not matter how many times I went over certain paragraphs I know I wouldn’t have understood it any better!

I recall telling some colleagues of mine that it was a ‘mind bender’ after reading only a few pages, and I still maintain that description. I don’t have an academic background so I’m not used to reading text such as this. It was a struggle to begin with, but about half way through certain elements began to make sense and I could start to relate them back to not only my testing, but also my martial arts training. The book prompted some tweets from me (some direct quotes):

  • “What the mistaken claim that all knowledge is tacit does indicate is that, mostly, explicit knowledge is harder to understand…” H Collins
  • “The modern world is thought of as driven by explicit knowledge – patterns.” H Collins
  • “The explicit is taken as the norm rather than the tacit – and the contrast with what is not explicit is ever present.” H Collins
  • “Education is more a matter of socialization into tacit ways of thinking and doing than transferring explicit information or instructions.” H Collins
  • #testing standards are like lookup tables, being frozen history at best… and often not even that. 1/2
  • –Little to no sensitivity to social constructs and changing contexts. #stopiso29119 2/2
  • The /rules/ of #testing are like the /rules/ of society… constantly changing. Explicit standards don’t change with them. #stopiso29119
  • So, just finished Tacit & Explicit Knowledge by Harry Collins. It’s going to take a while to digest, but some instant gems are evident.

Along with the tweets there were multiple thoughts that have found their way into my book (currently in progress); specifically related to knowledge transfer.

As soon as the book moved on from explaining the explicit, into explaining the tacit, my thoughts quickly moved to martial arts and how the many instructors I’ve work with have attempted to transfer knowledge on to me, their student. While Harry does well at explaining a very complex subject using working examples (riding a bike for example) I still found myself getting more from the book when linking it back to my own experiences. While this would seem common place, I want to make this point very clear because had it not been the case, I would have really struggled with this particular read. I found it to be a rather confusing style of writing; however with persistence I managed it.

Harry draws a very useful ‘map’ of tacit knowledge throughout the book, and this helps to analyse what can, should, cannot, and should not be explicit/explicable. My relatively naive understanding of both forms of knowledge, pre-read, appears to have been correct to some degree, but that understanding was nowhere near deep enough. The book has helped me to question further the extent of both forms of knowledge, and how they may impact the work we do, and could do, as testers.

Making something explicit can be as simple as writing it down on paper, but does that mean it will hold any meaning to the recipient? Will be useful to them? Will it afford them the understanding they need in order to do a good job? Are you making knowledge explicit when doing this, or simply writing words on paper? This book prompts a lot of great questions!

Harry, very neatly, breaks up tacit knowledge into three forms:

  • Relational Tacit Knowledge (RTK – Weak) – Contingencies of social life.
  • Somatic Tacit Knowledge (STK – Medium) – The nature of the human body and brain.
  • Collective Tacit Knowledge (CTK – Strong) – The nature of human society.

He sets out to explain how each of these forms of tacit knowledge can, or could, be made explicit, and how elements of each cannot. CTK held the most meaning for me. This is the area of tacit knowledge that calls on our society, the knowledge that remains sensitive to the varying contexts of our lives, surroundings, interactions, etc. Learning to drive a car was a great example used for this. While the instructions for interacting with the car itself could be explicable, how would you go about making explicit the knowledge required to react to varying traffic conditions, driving rules, etc. Or simpler again… while you can tell someone (make explicit) how far away they must remain from another person while walking past them on the street, what would that person do if it were a busy walkway? What would they do if the person passing them was of the opposite sex? Can they break the distance rule and bump into them because it’s busy? What if they did this when it wasn’t busy? Each time they passed a different person, in different conditions, they would need to call on their CTK in order to navigate the situation. Thinking of, and making explicit, every conceivable scenario for passing someone on the street could be possible; however the limitations (we would die first, and where would we store all the data?) would be far too great for any of us to achieve it.

Now with all of the above in mind, think about your testing. How many possible scenarios do you think you could call upon in order to make the task explicit? Exactly… don’t bother! Testing is social. Our CTK (along with RTK and STK) plays a huge part in us doing a good job. This fly’s in the face of testing that solely calls upon explicit step by step procedural artifacts (test cases). While these may add value in some contexts, doing them alone will not allow for the CTK that is so greatly required in our work.

There is much more within the covers of this book. The above is merely one learning that fell from the pages for me; and while I ‘knew’ it already, I don’t think I knew it deeply enough.

I’d like to do an analysis of some testing activities and see where they fit on the map of tacit knowledge as it’s written in this book. That will take time.

I now need to read The Shape of Actions, one of Harry’s earlier books in collaboration with Martin Kusch. It’s mentioned a few times through this book, as are polimorphic and mimeomorphic actions. While I have a high level understanding of these, I would like to go deeper.

I recommend this book to testers out there. It may be tough going, but persist like I did. There is value to be gained.

Bank 2.0 – High-level Review

bank 2.0

Not long ago I discovered my current client had a small library. The above, Bank 2.0 by Brett King, caught my attention. From memory it had something to do with the ‘2.0’ and my assumption that it had something to do with technology. The cover is also very inviting.

Firstly it’s important to note that this book was published back in 2010. While that doesn’t sound like a long time ago, both in the world of finance and technology a great deal has changed in the last 5 years. That’s not to say that the book is not worth reading. All it does is add a different dimension for the reader – How many of Brett’s predictions have come true, or likely will with the knowledge that 5 more years can bring.

When I first looked at some of the book’s early reviews I noticed a sentiment of controversy. These days I don’t believe that would be the case, but thinking about banking back in late naughties (2000’s) you can see how some of what Brett says in the book could be taken as controversial. It’s also important to keep in mind that Brett would have been writing this during and just post the Global Financial Crisis; certainly a pressure cooker of a time in the industry.

I’ve been working in finance for the majority of the last 5 years, at my current client, who, interestingly enough, get a mention in the book. Perhaps that’s why there are a few copies in the client’s library?! I can tell the book has been read by some in decision making positions, because a lot of what has been happening with my client’s business and IT is suggested in the book. I think this help me a great deal while reading the book as I could relate to much of the terminology and the processes/methodologies that are called out within it. For someone who has not worked in finance the read is still a good one, as Brett does well to explain financial concepts where required.

The book is broken up into 3 larger parts:

Part 1 – Changes in Customer Behaviour

  • What the Internet and “CrackBerry” Have Taught Customers
  • Measuring the Customer Experience

Part 2 – Fixing the Broken Bits – Channel Improvement

  • Rebuilding the Branch One Customer at a Time
  • Please Hang Up and Try Again – Call Center’s and IVRs
  • Web – More Than 10 Years Old … and Still Broken
  • Mobile – The New Internet and Death of Cash
  • ATM and Self-Service Banking – Convergence and Control
  • Navigating Rapid Change Dynamics

Part 3 – The Road Ahead – Beyond Channel

  • Deep Impact – Technology & Disruptive Innovation
  • Gridless Customer Experience – More Complexity, More Choice
  • The Emergence of the Prosumer – Collective Intelligence, Social Networking and Web 2.0
  • Future Payments and Cash – RFID, Biometrics, P2P Micropayments, Digital Cash
  • Death of Advertising – Predictive and Precognitive Sales and Marketing
  • The BANK 2.0 Road Map

I’d like to call out the common theme as I saw it throughout the book – customer experience. For those that know me this was particularly profound. I’m a big advocate of usability and the overall user experience of products and therefore took great interest in the sections of the book that concentrated on those particular subjects.

Brett does a good job of providing just enough history of a particular subject for it to make sense to the reader when he goes on to explain how it has, and may, impact banking as we know it (or knew it at the time). As previously mentioned I did have an advantage as a reader as I work in the finance industry and I think this made the read easier for me. I perhaps wouldn’t have gleamed as much from it had I not the experience in the industry, but as the book is mainly concentrated on banking I don’t see that as a negative. I do believe any industry that relies on, or would like to rely on, IT to help service it’s customers could gain from reading this book. In many areas you could simply replace the banking references with your own industry’s references as the common theme remains the same – focus on the customer’s behaviour.

This theme isn’t new of course, and I don’t believe it was new back in 2010 when the book was published, however it amazes me almost everyday that many just haven’t caught on. I’ve seen a huge shift in my client’s business to move towards this theme, but it would appear from reading the book that many hadn’t back in 2010.

One thing that did happen to me while I was reading the book, that I perhaps would not have thought in-depth about otherwise, was a confusing customer experience of my own. I had applied for a HSBC (a bank that is mentioned a great deal in the book) credit card and been approved. The online application process was pretty simple, however when it came time to register for online banking I stumbled somewhat with HSBC’s IVR system. Activating the card was easy – call the number provided and follow the prompts on the IVR. Activating cards was one of the first level choices and therefore I had that done in no time. When it came to online banking registration it was another story – The letter I had received, and the text on the website both stated to call the particular number and follow the prompts. I called and listened to the options… none of which sounded like online banking registration. After experiencing ‘Activating cards’ in such a clear and concise manner, I had the expectation that ‘online banking registration’ would be equally as clear and concise. After a few attempts at a few different options, one of which was ‘credit cards online’ I decided to wait and speak with an operator. I believe that the option I wanted was in fact ‘credit cards online’, but even after choosing that option I couldn’t work out how I registered for online banking.

What made this experience so profound was that at the time I was reading a section of the book that was all about IVRs and how they can be utilised to expedite a customer’s experience, and save the bank money. Also that it happened to be; one of the most mentioned banks in the book.

Another nice element to the book is its case studies; some of which are written by guest contributors. The case studies go along way in proving what Brett is telling the reader. They also highlight, in great magnitude, the importance of the points Brett is trying to make.

Bank 3.0 has since been written, and while the reviews aren’t as great (in general suggesting there should have been more time between the 2 books) I’m still very keen to read it. That and other writings from Brett.

I recommend Bank 2.0, more if you’re in the finance industry, but also if you’re interested in how technology can, and may, impact the business of serving customers.