Long Chain Bugs

We’ve all seen them, your testing away, and something odd happens, application crash, unusual error message. you look back at what you were up to, retracing your steps waiting to see the same behaviour repeated, yet nothing shows, you end up digging around into system state, other applications that were running as well, other people who were in the environment as well, sometimes we can work it all out, a lot of the time, at least I, can’t. Well as I found out recently at a medical appointment I attended with my other half, it would seem that the medical community has long chain errors as well.

My partner has Lyme, she’s been very unwell with it for a number of years, and we recently had the chance to talk to a top-flight consultant about her condition. What they explained was Lyme Borreliosis Complex (LBC), as they have dubbed it, is a complex condition that has only in part to do with a single event. The system state also needs to have a variety of conditions meet for that bite to then cascade into the horrible condition that LBC is. They are not sure what the precise conditions need to be, they believe its a combination of genetics, familiar health, and environmental.

At, this point I had to try very hard not to hijack the appointment and start talking with them about how they are researching this and have they seen the very cool ted talk about a multi-disciplinary team that tackles big challenges that have eluded specialists.

It has made me think about how people who have practised testing, understand the mindset required to untangle these complex scenarios could have incredibly interesting and fulfilling jobs if we could convince other communities of the value and benefit we could bring.

Have any of you had the chance to bring your testing skill set to unexpected places?

Understanding risk from the perspective of stakeholders

A key part of getting software signed off is having the key stakeholders happy that it does or is what they wanted. So how do you make sure you address this in your testing?

There are a few different approaches that you can take to gain an understanding of the risks from the perspective of a stakeholder, at there core though there are a few skills which you need to use regardless of if you interview, produce an information gathering form, or run a brainstorming session, to name a few ways.

What you are trying to do is gain an understanding of their real needs, and the stakeholders may not understand what these are in the early stages of a project, or at least in any great detail. You need to draw these out of them with the use of open questions that lead them to think about the details that you need to understand. You have to do this without imposing your concerns on the conversation. Yes, it needs to be a conversation, it’s not a question and answer session, you have to build rapport and trust with them so that over time they will volunteer this information to you as they are beginning to trust your judgement and that you will take what they say seriously.

You need to set the initial conversation up wisely. You have to give the stakeholder plenty of warning about what you want to do, and what you want to get out of the conversation so that they can prepare. You’ll also need to prepare, make sure you can provide answers to any questions they are likely to ask that you have accurate information about, however, you have to be able to say, ” I don’t know that yet” or, “let me look into that”. nothing will damage the relationship you are trying to build faster than guessing at answers and getting it wrong.

It’s okay to go off script, when it is done for good reason, to gain greater understanding, try to bring it back on track at the appropriate time, when you have explored the topic you were discussing before you or they have started to ramble or moved too far from what you wished to talk about.

You’ll need to practice active listening, being flexible about your questions and asking questions to draw out more details, these are not easy skills and deserve a post in their own right, so I won’t go into them in detail hear. I’ll just say you need to be paying close attention to what you are being told so that you can ask the right questions, at the right time to draw greater detail out, all while writing down the important pieces of information.

you can also make great use of silent pauses to draw further details from them, people will naturally want to fill gaps in conversation, and you can use them when you think someone is holding back. Just don’t go overboard, it’s not an interrogation. You have to practice the suspension of the ego, as these conversations are not about what you think, they are about what the key stakeholders think. You have to cultivate your curiosity about what other think, this will help you forget about your opinions on the matter as you seek a greater understanding of the thoughts of others.

You have to practice the suspension of the ego, as these conversations are not about what you think, they are about what the key stakeholders think. You have to cultivate your curiosity about what other think, this will help you forget about your opinions on the matter as you seek a greater understanding of the thoughts of others.

And remember this is an ongoing conversation, you should get back in touch with these people on a regular basis, even if it’s just to let them know you are still actively using the information they have provided as a form of measure against the quality of what you are looking at. If you maintain good rapport with them, they will more naturally include you in conversations about what their concerns are, and if you have done it well they may even come straight to you when they have concerns or questions.


Let me know your experiences of build an ongoing relationship with key stakeholders, and how you went about it.





MEWT 5, my day

So at the weekend, it was MEWT, a peer workshop for exploratory testers. There was a handful of us from across the UK. the topic for this, the 5th MEWT was, “What is professional testing”. I felt ill-equipped to attempt defining such a contentious thing, so I did a brief talk on my professional growth from definitely not a professional tester towards something that could better be described as containing professional elements My talk can be found here.

This was my first time talking to a group of peers, my first workshop, and conference, (although Mewt isn’t really a conference :)) I was incredibly nervous about giving my talk, especially as the day went on and there were so many very good talks, by some very knowledgeable people.  We got to my talk towards the end of the day, and by all accounts, it was enjoyed Dan Billing kindly tweeted

DanBtweetPassion  Although  at the time the only thing I felt I was an exemplar of was nerves.  The questions were straight forwards and simple to answer, mainly focused around how I got the momentum to make changes in my workplace and the responsibility to do so.

BillMresponsibility I described it, possibly rather glibbly as “stealing” the responsibility, I did this because I was never handed the responsibility to coach my colleagues or push the company to do better at testing, or even define and overall IT test strategy. I just did it, someone had to.

So more than enough about what I did, and on to the day at large.

The venue, at Attenbourgh Nature Reserve, is an excellent location, the room is lovely, well equipped and has a beautiful view, and small balcony for eating lunch on. Well chosen, heartily recommend staying there for as long as possible.

The other attendees are a great bunch of people and it was fantastic to meet them all, there is such a variety of experiences and personalities there, an education in itself.

mewt5 attendees Dan C is the tallest tester I have met, which I’m sure he’ll be pleased about.

Dan C is the tallest tester I have met, which I’m sure he’ll be pleased about.

The talks were very interesting, from the start of the day right through to the end, the high point for me was the meta, “what is, What is professional testing” A talk by James Thomas that I’ll long remember and aspire to be anywhere near as good as, his talk and write-up can be found on his blog  we worth reading.

The direction of the day was largely driven by the differential of professional work over notions of a Profession, and testing over testers. I think it’s right to say that as a group we were far more interested in seeing a good job done by someone, rather a person specifically based in a Profession doing a job, good or bad. I wonder if our predisposition to seeing all the ways something could go, bad and good, hinders our ability to move something forwards, we spoke at great lengths about how a Professional body could be a bad thing, could go wrong, might not live up to the needs of the industry that I doubt as a group we would ever be happy that we had understood the ramifications of instituting a Professional body, and that we had mitigated all the potential pitfalls to a sufficient degree that we would ever get around to starting a Professional body, That and I think we are a contrary bunch that don’t really like being told what we can and can’t do. I do strongly believe that is why we strive to do a good job though. we answer to ourselves, and it’s hard to lie to yourself about how happy you are with the quality of your own work.

So what were my learning from the day, simply put professional work is describable in a general and non-specific sense to a degree that allows a conversation about basic principles, high quality, integrity, honesty, customer focused, etc. However, it must have a context within which its being described if you wish detail, as that context can change whether a behaviour or action is professional, or unprofessional. And that context is poorly described, we all work in a wide variety of differing environments, that constitute differing standards, expectations, drives, and restrictions, to highlight just a few of the environmental constituents. There is a high degree of tacit knowledge about our own environments that would take many workshops such as MEWT to tease out, and the value of such an undertaking is, in my opinion, low at best. So where does that leave us in our understanding of the question asked, “What is professional testing?” we can quickly point out what it isn’t. We have a framework of driving values that we broadly agree are required, they have little to do with testing, and a lot to do with conduct, but why should we expect anything different. professionalism is mostly framed in behaviours that are to do with the conduct of the person towards colleagues, employers, peers and their fellows, and rarely to do with a specific set of technical skills that are used within that profession, so you can work within a profession, and you can be a Professional. Professions in a formal sense are not something we are seeking, yet professional testing is.

By that, we mean the technical work of testing, as to be defined somewhere else, done in a way that has the characteristics of professional behaviour. As defined as conscientious, honest, integrity driven, work towards the end of getting the project completed for the customer, regardless of any sort of title, role boundary, or other arbitrary delineation of task ownership, ie if it needs doing, and you can do it to the quality required (yes quality required is a deep question in its own right. In this sense, I mean to a level that adds value to the overall project objectives with a skill commensurate to doing a “good Job” and not detrimental, to timelines, quality ,other people or the overall project), get on and do it.

I will probably come back to this question and see if I can simplify my reasoning, make the steps easier to follow once I have internalised it further and read around it some more.

Did I enjoy MEWT 5, I most certainly did, I would love the opportunity to attend more peer workshop, and would strongly recommend that should the chance be presented take it with both hands.


Feedback question and challenges most welcome.


Do you know what testing is?

So you are working on a project, large or small and you are working with a variety of stakeholders, some may know what testing is, some may think they know what testing is, and some have never even thought about it.
So what do you do?
For me this one is an easy thing to address, I tell them all what testing is to me, in small bit size pieces. Using plain English, and alway checking back with them about what they mean when they use technical language, always phrased as ” just so I can understand..” not so I can correct them, so I can make sure I really know what they mean, This goes for technical people more than any, I sat in a meeting with a system architect lead, interface lead and developer lead, and they all had a different definition to unit testing (or developer testing). If I hadn’t asked it would have gone unsaid, assuming they all meant the same things.
People who don’t know what testing is, you have to show them the value you bring, demonstrate why what you do, makes their lives easier. Telling them isn’t enough, they have to see what you bring to the table otherwise you are just some strange IT role.
Be open and inclusive invite people to see what you do, help them see why you ask the questions you do, and never fear being challenged, just make sure when you respond to that challenge its positive, clear, easy to understand and relevant, they aren’t saying your wrong, or not needed, they are really saying I don’t understand why often with little realisation that this drives what they are saying.
If you want to do well in the professional world being able to demonstrate your worth is a skill that is worth developing, as the way you demonstrate it has to change according to the audience, you have to be able to explain in terms anyone can understand and defend why you have done or are doing what you are, especially if they come with preconceptions about what it is you do.
James Bach and Micheal Bolton tester story is an invaluable tool here (These are the people who I first saw this from not sure who’s idea it was first) It gives a framework within which to think about the differing side of what you are doing, and how to address questions about it to support why you have chosen to do what you have, when you have.
It’s all about understanding, what the concerns are, and how you can provide assurance to the stakeholder who raised it, that you will be able to provide them with proof/information/demonstration of that area so they can make a judgement on how happy they are with it, for example, in my current project the speed of order entry for the trade sales team is very important, they need to be able to work through an order flow, including placing individual lines on an order at the speed of speach. We are addressing this through demonstartaions and timings of screen loading, so the Trade sales manager can see how fast it is and make a judgement of if they are happy with that.

If it’s a journey…

As those of you who have read previous posts of mine will know, at work we are installing a new ERP system, and taking out the very old one.
One of the phrases that are being used is we are on a journey, this provokes an irrational response of wanting to strangle the individual uttering it.
So I thought I’d explore what about it drives me mad.
The way it is used implies that we are following some path that leads us to our chosen end goal, and if we travel it we will discover what we need to know along the way and get to this nirvana.
However, there is no path, we don’t know what we will encounter, we are drawing the map as we go, as what we require is unique to us, as is each major software installation. We don’t even know if our compass works here, the things we have used before to direct us no longer apply, the context they worked in, isn’t this context.
This journey would be more akin to some explorers landing on a new planet and having to map it all by hand, without knowing whats safe and whats not, let alone having a known destination to head towards, best we have is large geographical features, ie it needs to me able to manage stock.
It is this apparent gap between the reality and the phrase that causes my sanity to fray.

Passion in your job

So as you may know from earlier posts I’m quite new to testing as a full-time job, it’s something I’ve been involved in for a while. As I’ve progressed in my new role as a software tester, rather than just doing some testing on the side I have come to the realisation that testing, as I now understand it, is something I really enjoy. It speaks to many parts of my mind, it’s a constant challenge, with a great deal to learn about, and a huge variety. It turns out that I am very passionate about testing being done well, and that passion is translating to work listening to what I have to say to them.
So what does this meaning for me?
Work are more willing to accept when I tell them something about testing.
They are willing to send me on courses and to conferences.
They are willing to review what I do, as defined by my job title.
But more importantly, they are willing to give me more responsibility, areas of the business that were out of my original reach, yet really needed to review how they test software are becoming places I can influence, they are falling within my remit as a software tester. This hasn’t taken long either, my passion for high-quality testing totally changed how we are approaching testing the ERP we are installing, as a knock on from that they are willing to listen to me about minor software changes. letting me help the new testers we have, in terms of coaching, and getting them on courses to help them, inviting me to meetings with the senior developers so I can input early on projects.
All of this is happening because of my highly visible passion for what I’m doing.

If you want to go further where you work, show the passion you have for your role, bring ideas to your boss, push your self-development, let people know how much doing what you do, well, means to you, and how it helps them. Passion for your job does translate to progress.