Stakeholder Engagement for Testers – The talk I never did (Part 5)

welcome to part 5 of Stakeholder engagement for testers. This is the final part in this series you’ll all be pleased to hear :)

If you have not read the rest you can start back here at part 1.

so off we go…

How to inform them?

Once we know what they want, and why they want it, the final thing is identifying how to keep them informed.

Lets start with how I believe you should not keep your stakeholders informed. Standardised reporting! Sending a standard report to every Tom, Dick and Harry across all your stakeholders is a bad idea.

The reason is this, different stakeholders want different information. Different stakeholders want information presented in different ways, some are numbers driven some are narrative oriented and some like pretty graphs. Different Stakeholders what there information and different frequencies.

Now I understand the motives for standardised reports, and I have done them myself. It’s easier to only have to do one report. It might be efficient, but I don’t think its at all effective. Standardised reports can easily end up being useless to everyone. This is because to please everyone these reports become overloaded with different bits of information, it becomes disjointed and hard to read.

They can also be dangerous, especially where metrics are concerned because unless all your stakeholders have asked for that specific metric, and all have the same understanding of what that metric is (and is not) telling then, they will be read and misinterpreted. This allows for some of your stakeholders to make false assumptions about what your message is.

So what’s the alternative? Well you could create a personalised report for each of your stakeholders, but lets be honest, that is an overhead that is not sustainable. So I tend to suggest the following:

Produce more than 1 but less than 4. Unless you are lucky enough to only have 1 stakeholder then you are going to have slightly different reporting requests. There is however going to be some overlap. Therefore group the requesting into a couple of reports. I tend to find that I end up with 3 reports; one will be a technical report, for those stakeholders that are in this space such as development managers, other test areas if needed, support teams etc. The second report will be for management stakeholders such as PM’s, IT senior managers, etc. and the final one will be for business stakeholders.

The key for each of your reports send them to the relevant people, and keep the information as concise and relevant to its audience as possible, don’t overload it with stuff they don’t care about or might not understand. This is how assumptions and unwanted noise are created.

Reports are not the only way to inform your stakeholders though. In fact some stakeholders will explicitly not want them. So for these you are going to need to use other vehicles of communication. This could be meetings, group or one to one catch-ups. Use your judgement if these meetings should be formal or informal based on who the stakeholders are.

Dashboards either on walls or on things like Wiki pages is another good way to allow your stakeholders to keep themselves informed at their pace.

A demo, if appropriate is a further way to inform and engage your stakeholders. So if possible set up the occasional “show and tell” with those stakeholders that are keen on the product itself such as users of support and sales teams.


Blogging in Shorts – WTF is a tester?!?

This is the first in what I hope to be an ongoing series called “Blogging in Shorts”.
These will be short blog posts that are things that are going around in my head about testing.

They are likely to be either rants or raw thought, so they may not be completely thought out, but I want to get them down on (virtual) paper and maybe then I, or others from the community can build upon them.

Anyway heres the first:

Im always reading articles and blogs that tell me what a tester is. The problem is they never seem to agree!

The truth is that they are all correct, in their own way. But it sure does make for a lot of confusion within our industry. whats adds to this confusion is almost all of these blog posters and article writers make there definition seem so absolute; There can be only one…and its my definition.

If we could all as test communicators/advocates stop trying to convince the rest of the IT industry, and ourselves that a tester is <your definition> and instead start to be more open and honest with a tester can be <your definition> but there are other just as valid definitions in other contexts  message then I think that we as an industry might start to be able to rid the IT industry of some of its myths and monsters that have plagued us for as long as I can remember.


Stakeholder Engagement for Testers – The talk I never did (Part 4)

Another day….another part to my Stakeholder engagement series. So far in this series I have discussed what a stakeholder in part 1, and in part 2 and part 3 I discussed who your stakeholders are and how you can find out.

Now that you’ve identified who your stakeholders are, i’d now like to go over what they want, why they want it and how we can deliver it.

What do they want?

By asking the questions mentioned at the end of part 3 and others, we can start to understand in more detail for each of our key stakeholders, what they want, why they want it and how they want it.

Lets start with understanding what they want.

Almost certainly the most prevalent mistake that I see from test managers and testers, is assuming they know what their stakeholders what.

Don’t make the same mistake. The key to understanding what they want is asking, and in some cases educating them also. I’m not saying that there is not going to be some common things that they are all going to want, but don’t assume it.

There are two elements of a stakeholders wants. The first is the physical wants. Reports and other artefacts such a testing documentation would fall into the category. Also what functionality within the product is most important to them is also going to be useful to know at this point.

The second is going to be their desires. This should have become known, at least to some degree, during your analysis of your stakeholders we talked about a in the previous parts of this series.

Understanding what they desire from the project, product, your team and you is the most important thing to do in order to make your life easier. It will allow you to get on with what you need to do without interruptions and changes in direction because a stakeholder is not happy with something that you’ve only found out about half way through your work.

Another benefit of doing this with your stakeholders is starting to identify where there are conflicts or misalignment of expectations or wants between different stakeholders. The earlier this can be identified the better. It will allow you to bring your stakeholders together and address the situation so that you are not being pulled in different directions later down the line.

Don’t expect others to do this; I have lost count of the number of times I have been the one to identify misalignment that the project managers were not aware of. Once you have your stakeholders aligned it will be much more straightforward in managing the expectations of them all.

Why do they want it?

It is not uncommon that a stakeholder will say they want something that does not make sense; a non standard metric is quite common to be asked for. I see a lot of testers saying that if its not part of their “standard” metrics pack they wont supply it.

This is not something I would ever do. I would never personally out of hand refuse to give a stakeholder something they have asked for because it’s not, in my view, something that we should deliver. What I recommend if a stakeholder is asking for something that you don’t normally produce is ask “Why?” Why do they feel that this extra information, or extra document or whatever it might be help them?

There are a number of reasons why someone will want something and you will want to spend some time understanding it.

It maybe that their boss is going to ask them something that this will answer, or something they feel they should know.

Biases and inbuilt belief systems will also play a heavy part on what they want. These can range from managers who still expected 100% defect free software, or negative views on testing due to past experiences, and therefore what to micro manager through overly details metric reporting.

By asking why, you should be able to get to the underlying driver for their request. Only then can you choose whether to help them to answer their question in a better way, educate them as to why what they are asking for might not actually give them what they believe it will, or accept that their request is valid. It might even be a wise in some situations to give them what they want even if you can’t see the real reason for it, to smooth a path for example, but this will need your judgement.


continues in part 5.


Stakeholder Engagement for Testers – The talk I never did (Part 3)

Well Hello!

Another morning is upon us, which means its time for part 3 of my stakeholder engagement series. if you have stumbled across this post and you want to start from the beginning part 1 can be found here. This part is a continuation of part 2. Today we focus on prioritisation of your stakeholders and a little bit about the physiology of  stakeholder engagement.

so without further ado…

Who are Your Stakeholders? (cont.)

Who’s important? How do we prioritise them?

After going through these various ways of identifying who the stakeholders are in this project, you are going to more than likely have a very long list. This is likely to be too many for you to realistically manage. You’re going to need to cull this list, but how?

Well the good thing is that not all stakeholders are created equal! There is a well-used, and proven technique for working out whom you need to spend more time on and whom you can leave alone.

Stakeholder Analysis is a technique that helps us to prioritise our list of stakeholders that we now have. To do this is very straightforward. We start off with a standard two by two table like this one:

Screenshot 2015-08-07 08.38.56

The y-axis is going to represent “Power” from low power up to high power. On the x-axis we are going to show the interest in what we are doing. Again the scale will go from low to high.

Now in our two by two, in the box represented by low interest and low power we have “Monitor”. These are going to contain the people we are going to spend the least amount of time managing.

The next box is the high interest, but low power. In here we put Keep informed. We are going to have to keep these people adequately informed about what is going on talk to them to ensure that no major issues are arising. These people although not powerful they can often be very helpful and are enablers.

In the high interest and high power box we have those that we will “manage the closest”. These are going to be the people that we must fully engage with and make the greatest effort in keeping satisfied.

In the final box, the low interest, with high power need to be kept satisfied. We are going to spend some effort to keep them informed because they can be both potentially helpful to us, but can also if left completely out of the loop, become an unwanted pain in the backside!

So now all we need to do is map our list of stakeholders onto this two by two.

Remember they’re not Roles they’re People!

Now that we have our priorities stakeholders we have need to find out more about those that we have prioritised as key. Information is power; so the more we know about our stakeholders the easier it is going to be to manage them. It will also help you to identify potential stakeholder conflicts early so that you can do something about it. Even if you cant do anything about it you can at least deal with it internally by accepting that there’s nothing you can do and therefore not beat yourself up about it.

The things you are going to need to know are how each of your key stakeholders are going to react to your project. For example, high interest is not automatically a positive trait. It could be that they are interested because they are not in support of it.

Also the more you know about your stakeholders the better you are going to be able to engage them and communicate with them.

Some things that you might want to know are;

  • what interest do they have in relation to the output of what you do? Is it financial or emotional? Is it positive or negative?
  • What motivates them the most? Is it quality, time to market, cost, or something else?
  • What information do they want from you and what delivery method do they prefer?
  • What is there current opinion on yours and your team’s work, and is there opinion based on good information? It’s also important to understand who influences their opinions general, and especially their opinion of you? It maybe these people need to be added to your key stakeholder list.

If the stakeholder is unlikely to be positive what is likely to win them around to support what you do? If however you don’t believe that they can be you need to understand how you can best manage their opposition.

It might seem daunting but it’s my experience the best way to start to get this information is to just talk directly with them. It will also go a long way to building the relationship you desire with them.

Part 4 can be found here.


Stakeholder Engagement for Testers – The talk I never did (Part 2)

Good Morning all!

so its time for part two of my stakeholder engagement series. If you have not read part 1 you can find it here where I talked about what a stakeholder is.

In this post we will look at who your stakeholders are. Types of stakeholders and how you identify them, so….

Who are Your Stakeholders?

So we know what stakeholders are now, they’re the people that, in one way or another give a damn(for more details see part 1 of this series). But who are these people? How do we start to identify them?

Types of stakeholders

The first thing to do is to understand the types of stakeholders. You are going to have stakeholders that are either internal or external. Project managers and IT managers most likely be internal, maybe your customer to, however it is as likely that your customers will be external. 3rd party delivery partners or service supplies will all also be external.

Also your stakeholders are going to be more focused towards either the project, such as PM’s Development Managers, and Purse String keepers, the product, Such as, end users, customers, Sales teams, shareholders, or regulators.

The key here is I said MORE focused; that is to say that most of the stakeholders are going to be interested in both. It is my experience however that they will pull to one side or the other.

The final way I like to group stakeholders are into enablers, those people that are going to help us achieve, and those that will constrain us; those that will make our life more difficult.

Putting stakeholders into groups is not black and white, but I find that it helps me to think about where my stakeholders are likely to be hiding as I venture into the process of identifying them all.

How do we identify our stakeholders?

There are a number of ways that you can start to identify who your stakeholders are, and I find it helpful to just make a long list of all the people that could have an interest in what my team or I are doing.

Organisation (org) charts are a good place to start. Most companies will have one, and it will show all the relationships between each of the people in your company, division or department etc.

A word of warning though, unfortunately org charts can go out of date very quickly as it is often the case that they are infrequently maintained. So they are rarely 100% reliable, but are still a good starting point, if it is not the only place you look.

There are very likely to be some roles that will be stakeholders every time you’re on a project. The Project Manager for example is going to be one of the first names on the list, but there are also going to be others. Over time you are going to build up a list of people and roles that are common stakeholders in your world.

I have a cheat sheet with a list of roles that are very often stakeholders. It acts as a great checklist, but I also use it as Terms of reference, putting the names against the roles as I go through it.

Here’s the current list that I use:

Screenshot 2015-08-06 19.41.41

Project documentation is going to be another good source, specifically any terms of reference, or initiation documents if your company produces these types of documents. These documents commonly hold details about who the stakeholders are for your project. Again this is not going to be a definitive list because not all stakeholders of the project are necessarily going to be stakeholders of testing.

The final, and maybe the best way of finding out who might be a stakeholder in your project is… ASK.

Get out there and speak to people to find out. Start with you project manager or test manager If that’s not you, but no one should be off limits to be able to ask who might be interest in your involvement within the project and or product.

Part 3 is here.


Stakeholder Engagement for Testers – The talk I never did (Part 1)

Hello folks!

So I’ve decided that after a year away from my blog, I should probably try to be a bit more active again. But what to write about? Well I’ve had this talk on stakeholder engagement – “Why Test Stakeholders need to be engaged and how to make your relationship work!” – written for about the same time as i’ve not posted to this blog. But due to me being a little bit apprehensive about talking in public, and on the rare occasions its been submitted its been declined its just collected dust on my Macbook.

To be honest I had almost forgotten about it until Mike Jarrad and I met up for some beers and food on Tuesday evening and he asked me about it. He suggested I convert it to a “white paper”, but to me that sounds all a bit to formalised, and Im not sure it justifies it, so instead I’m going to throw it up on here.

If I posted it all here in one post I think it would be two long, so I am going to put it up in a short series of posts.

This post will cover my views on what a stakeholder is.

Part 2 – how to identify who your stakeholders are can be found here

Part 3 – how to prioritise your stakeholders can be found here

Part 4 – what does your stakeholders what, why do they want it and how to deliver information can be found here

Part 5 – how to deliver information to your stakeholders can be found here

So what are stakeholders?

In short, a stakeholder is a person, or a group of people that have a vested interest in the project and/or the product being delivered.

These people will have a set of expectations of what should be met. They will demand certain things, such as demanding specific functionality within the product, demanding the level of quality required, demanding the audience it should appeal to, or demanding the timeframes in which it must be delivered.

Stakeholders are also going to have some kind of fear. They might be fearful that the project wont get delivered, fear that the quality will not be good enough or fear that the budgets gets out of control.

The challenge with stakeholders fear is that not all stakeholders will make their fears know. There are always going to be those that put on a brave face, and pretend that everything’s fine. In fact in a lot of cases they subconsciously don’t want to admit it to themselves.

A lot of the time this makes it very difficult to know about the existence of these fears; that is at least until the fear is realised and you get the “I saw this coming” statement from them!

Stakeholders’ fears can have damaging consequences by causing them to become a saboteur. They will appear positive and upbeat with you and the project team, but go back to their teams or managers with negative feedback.

That feedback will come in one of two forms, Overt and Passive. Overt feedback being when stakeholder’s comments are about things that are going wrong or they don’t like including sometimes you or your team. Passive feedback on the other hand, is the lack of any positive comments or feedback about what is going on in the project and with the product.

Either of these types of negative feedback can mean that even when we deliver something that is fit for purpose, the products audience already has a negative opinion. This in turn will make them all the more picky and critical of even the smallest of issues.

It’s really important to understand that stakeholders are people, and people are complex. Therefore it is really important that we don’t treat all stakeholders in the same way, present the same information to all stakeholders or present information in the same way.

In my opinion, it is often underestimated how much human psychology plays a part, if we want to manage our stakeholders successfully we need to have some understanding of how physiology effects those people we have identified as stakeholders.

Getting this wrong can be an absolute nightmare which will make your job at best more difficult than it need be, and at worse cause real stress and potential anxiety. Get it right however and being able to offer the best possible service to your project is going to be so much easier to achieve.

continued in Part 2


Test Coverage or Ass Coverage

So today was the start of CAST 2014 and as it always the case, my twitter account blew up with all the tweets from those lucky bastards that are there, while muggins here is working in the UK! but I’m not bitter of course :)

Anyway I was happy reading through the tweets, when I spotted a conversation regarding why some organisations are so resistant letting go of the notion that “Everything” must be scripted.  As is so often the case Michael Bolton was in there like “swimwear” with a great comment that really resonated with me.  In essence the point that he made (I believe) was that heavy script based testing is often seen in environments where there is a lack of trust in the testing and or the testers. Michael pointed out that as such there was more of a focus on covering ones posterior rather that truly looking at test coverage , hence the title of this post (hope you don’t mine me stealing it Michael)

So as I said, this hit home with me because this is something I am often seeing and apart from the fact that it winds me up no end, it also often leads to substandard testing.  So given that I was inspired to detail two of the main ass covering tactics I see from testers .

1. Asking for permission to test.

This is often where a tester is going to a Business Analyst, Developer or stakeholder to ask if it is OK for them to test function x or something akin to this.  In these situations, its not  that the tester was trying to gain information to better form their models of the System they are testing,  but instead they are looking for permission on what to test, or not so that if/when issues are found later the tester can say, well I was told not to test X by Y, without having done any of the risk assessment themselves to back up there reasoning for doing X and not Y.

2. Shirking responsibility for scope

This is similar to number 1, in that I often see testers write out their long list of test scenarios and then ask for them to be “signed-off” by a Business Analyst. This activity is in my view another attempt to avoid being accountable for your decisions as a tester, which in my opinion makes you lazy in your analytical thinking as testers that do this often are both looking for someone else to fill in the gaps (“why are you not testing X?” or “You might want to also test Y”) as well as having a fall back position when the enviable question of scope is asked when issues are found.

I would be interested to hear if other see these same things, or see other ways that testers cover their ass at the expense of test coverage.


Embrace your testing ignorance

What is ignorance? Well most people will think of ignorance as the following:

  • Wilful stupidity
  • Callow indifference to facts
  • Stubborn devotion to uninformed opinions
  • Ignoring of contrary ideas , opinions or facts
  • Uneducated, unaware, unenlightened, uninformed

I think you’ll agree that none of these are good. There is also another, less pejorative type of ignorance however. This is more of a common ignorance. The absence of facts, understanding, insight or clarity about something. This is where data does not exist or more communally does not make sense, or add up to a coherent explanation.

Ignorance can be a positive tool. It helps to frame better questions, which in turns produces better answers. It’s this ignorance that drives the scientific world. In his book “Ignorance: how it drives science”, Neuroscientist Stuart Firestien goes into great detail about this very subject, and I recommend reading it. In his book he, humorously, goes into details of why ignorance is at the heart of science; how in the day-to-day process of scientific activities it’s not what is already know that gets discussed, but more the what is still to be discovered that scientists discuss amongst themselves in the bars at night after a hard day in the labs. What he calls the “exhilaration of the unknown”.

“One never notices what has been done; one only notices what remains to be done…” – Marie Curie

Science has for 500 or so years systematically pursued knowledge using the scientific method; a body of techniques for acquiring new knowledge, interrogating and correcting previous knowledge, and investigating phenomena, that is based on evidence which is both empirical and measurable. But Firestien points out that the belief that this amalgamation of facts is what science is all about as a bit of a misconception woven by the media, and educational system, and argues that science is more like bumbling around in the dark. As Mathematician Andrew Wiles describes: It’s groping and probing and poking, and some bumbling and bungling, and then a switch is discovered, often by accident, and the light is lit, and everyone says, “Oh, so that’s how it looks.” And then it’s off to the next dark room. Stuart Firestien jokingly says science is less scientific method, but instead more “farting around…. In the dark.”

“It’s very difficult to find a black cat in a dark room, especially when there is no cat” – Ancient Proverb

Testing in many peoples eye is very closely aligned to the world of science; I am one of those that feel there are a large number of parallels, and after reading this book I could not help but feel that this all seemed so familiar and aligned with how I feel about, and see testing. That is to say that for all the “procedures” that are in place in testing most of the good information that comes from testing in my experience is when I or one of my team have been bumbling around in the dark, even if at the time we were afraid to admit that to anyone, including ourselves.

We like to think that testing is all controlled and process driven, even those that are in the Context driven school to some extent (just those processes change depending on situational context). But the reality is that for all that control a large part of the day to day activity of testing is the same as in science, you are looking in a dark room for bugs based on some rumour that one might be in there, or they might not; if you’re lucky you might stumble across it. If not you move on to the next dark room.

In testing we must embrace our ignorance. We must use what we don’t know as the fuel to drive our testing. We should use the facts from our results from previous testing as the raw material for new, better quality ignorance as we learn about what we are testing, but not so we can say what we know about it, but to better articulate what we are still to discover.



The lift to work: an estimation story

I have a little story to share with you.

Brian is sitting at home watching the football with a beer one Sunday afternoon, when in the middle of the second half the phone rings.

Slightly disgruntled at the interruption, Brian answers the phone to find his best friend and co-worker Simon on the other end. After some some catch up chit-chat Simon asks if Brian can drive him into work the following morning.

Brian agrees to giving lift to Simon. but then the following conversation happens:

Simon: Brian, how long will it take to drive from your home into work?
Brian: 45 minutes.
Simon: Hmm that’s not going to do, I need you to drive it in 30 minutes maximum, can you drive in that time?
Brian: No Simon, like I said the journey takes 45 minutes.
Simon: Can you do it in 30 mins if you leave at a different time?
Brian: Well maybe, but I need to be into work at my normal time so that’s not an option, but I could leave earlier if you need to be there 15 minutes earlier than I normally get into town; would that help?
Simon: No its not the time that I get there, I don’t want the drive to last more than 30 minutes. What if you used a faster car?
Brian: Given the time of day the heavy traffic will mean that a faster car will make no difference.
Simon: But Brian, I was talking with Stacy at a BBQ yesterday afternoon, and she told me that the journey should take no longer than 30 mins
Brian: Simon, Stacy cycles into work, she does not even drive!
Simon: Brian, that really not good enough. unless you can dive it in 30 minutes don’t bother.

In this little story Simon is being very unreasonable. He is taking advice from someone who does not have any experience in this Journey, but is not listening to advice from someone who does.

This story is obviously made up, but if you replace Brian with one of my test leads, and Simon with one of my Project managers then it becomes a real conversation I over heard last week. The subject was not  drive to work however, it was a test estimate for a well known piece of software.


Are these really lame reasons not to hire tester? (part 2)

This is the second part of my blog series looking at the “lame” reasons why companies do not hire testers as published by bughuntress. You can see the original post here:- LINK.

just to remind you, or if you have not read part 1; the general gist of the post by bughuntress is giving details of 5 lame reasons why companies do not hire competent testers. Through this series of blog posts I will look at each of those 5 “Lame” reasons and assess whether they are as lame as proclaimed by the original post.

This post I look at:

We don’t need to test a product until it is finished.

What bughuntress says:

Waiting for product to be finished is not rational, as it becomes more expensive and too difficult to make changes. The sooner you find and fix bugs the less expenses you will have and the better your reputation will be. Even if you release Beta versions before the final one, your customers would not be pleased by the product full of lags and defects. Do you need to take such a risk to lose your precious customers? Hardly.

OK, so lets start with the positives. I agree with the sentiment of the title, testing certainly does not need to wait until the product is finished. Testing can be, and often should be involved as early as possible in my view, although in my experience this does have its limits which I wont go into details here, but I may in a future post.

Now for the negatives. Firstly I have never in my life heard this given as an excuse for not hiring testers, so I am going to have to take their word for that. My bigger problem is with what the actual details of this section on their site is stating.

The details go into the old view point that defects found late in the development lifecycle cost more. If I said this was being excessively generalised I feel I would be being overly nice. People much more knowledgeable and qualified to explain why this is not (always) true have written plenty on this and a quick Google will find information on it, but to say that all defects found late in the process cost x times more to the project is just as incorrect as saying all defects found early in the life cycle cost x times more.

I would say that a more valid reason for wanting to start testing as early as possible is to allow for more opportunity to examine and find out useful information about the product. This can then feedback into the process which will help shape and maximum value the product provides to those that will use it. Might it save you some cost and headaches by finding something earlier than if you found it later? possibly but that is not always going to be the case.

My Verdict: A lame excuse (if it were used).  Not hiring a tester because you are not going to test until everything is completed does seem to me an ill-informed reason, which is probably why in 15 years I have never heard it being used as one. This excuse is more likely to be used as one for not hiring “right now” on a project. Do I agree with Bughuntress justifications for testing early? No, but I do agree there are benefits to be had by testing early.