I believe that gaining the buy in of the stakeholders is an essential element for the success of ant testing activity. That buy in should include stakeholders in the widest [...]]]>

To be vested with enormous authority is a fine thing; but to have the on-looking world consent to it is a finer.
Mark Twain

I believe that gaining the buy in of the stakeholders is an essential element for the success of ant testing activity. That buy in should include stakeholders in the widest sense of the word, sponsors, users, suppliers, support staff all have a stake in your activities. The more that someone feels that they have been involved in the process, the more they feel that their views have been considered and the more they feel that their needs will be addressed, the more they are likely to support the testing and enable its fulfilment.

By engaging with these stakeholders early on, what they require of the testing and what is required of them are understood whilst there is still time to address any issues or gaps. For example, if there is a forward calendar for the use of a certain test system such as a test payment gateway, it is better to understand early on what needs to be done to book time on that system, than to discover a week before it is required that it is being used by another project, or that that the business has a requirement to test the integrity of data migration but that the project considers data migration out of scope.

Within the overall group of stakeholders, some will be more important in terms of their ability to influence testing (either because of demands they place on testing, or because of the demands testing places on them) than others and some will be more able to be involved in the process of developing the test strategy than others. Unfortunately the important are not always as available as they need to be. At the beginning it is important that a working relationship based on trust is established that ensures that best use is made of people’s time and resources. Expecting a busy stakeholder, to attend a poorly planned workshop, halfway across the country with two days’ notice and no information on what will be discussed is not likely to go down well with any stakeholder.

I tend to approach stakeholder involvement in the following manner.

Initial Investigation:

Initial discussions with the project team and a read through of all available documentation is used to gain as good an understanding of the project as possible. I note the overall purpose of the project, the scope and the technology involved. I look at the requirements of the project to begin to understand the phases and levels of testing I might be required to undertake. I then begin to list the people/departments I need to talk to.

Based on the list I then try to set up a number of one to one meetings with key players, those who have the greatest ability to influence my testing, either by placing demands on me, or being critical in supplying something that testing will rely on. The idea of these early ‘one to ones’ is to build up good will, discover what I really need to know, to allow them to point me to other people I should be consulting with, either in addition to or instead of them. It allows them to begin to think about what the testing will involve and start to make an early contribution. I also find that ‘one to one’ meetings allow people to be more honest, even brutal in their answers and contributions. I encourage such contributions as I want to understand as well and as early as possible, what obstacles I will be facing.

Wider Workshops

Having identified the people I need to talk to, and having a better idea of what I need to talk about, I then set up a number of workshops and conferences, often based on groups with a similar interest, for example, users from different departments, technical and infrastructure people, management group etc. During these workshops I focus clearly on a set of objectives designed to discover or impart specific information to allow testing to move forward.

Following on from the workshops I issue regular and meaningful reports, updates and briefings, presenting the outcomes from the workshops, reporting the progress and clearly detailing how the workshops have influenced the development of the test strategy.

The Bank of Goodwill

Regardless of whether a particular stakeholder is making demands of testing, or whether testing is making a demand of them, an element of goodwill is required on all sides to approach obstacles, differences and extraordinary requests in the most effective and helpful manner as possible. I consider the early days in a project an opportunity to build up good will, and see each positive interaction with a stakeholder as a deposit in the goodwill bank. Asking the opinion of a subject matter expert, moving a meeting to fit another’s diary, taking time to explain a difficult concept or sending out useful and meaningful information, all add to the goodwill being generated. Later, as I discover I have made a mistake here, or for whatever reason need to change something there, or am reliant on this or that person to go the extra mile in order to assist testing, I am able to make a withdrawal from that bank of good will. Involving stakeholders, listening to their concerns, adapting to their requirements, keeping them fed with worthwhile information and getting their buy-in is the most effective way of building up that positive balance of good will that will contribute greatly to the success of the testing.

I suggest that all projects should have a documented test strategy.

Here are five good [...]]]>

I am sometimes asked, “Do we really need a test strategy?” and often such a question is followed immediately with a statement such as, “We have a test plan.” “No one will read it” or “We won’t follow it anyway”.

I suggest that all projects should have a documented test strategy.

Here are five good reasons why I feel that having an appropriate test strategy, documented at the right level makes sense and represents good practice.

Please feel free to challenge them or supply other good reasons….

1: Documenting a test strategy gives you time to think about what exactly the testing has to achieve, what and who is required to achieve it, how long it might take and what stages you will have to go through. Particularly if intelligently following a checklist of items to consider it helps manage and formalise your thinking so that all elements are covered.

2: Circulating a documented test strategy allows others to review, to cross reference sections and validate the content. This is particularly useful where you do not have the level of knowledge you would like.

3: Documenting a strategy assists with the overall project planning, providing the project manager with a reference document that provides a comprehensive list, explanation and justification for the various test phases and requirements, and can provide evidence to support the testing budget you are asking for.

4: Having a documented test strategy provides a point of reference both for yourself and others as the project progresses, allowing you to be reminded of the overall goals that have been agreed as you adapt the strategic response to each new challenge.

5:: Having a documented strategy allows all stakeholders to have a say in the testing process and allows the final approach to be signed up to by all relevant parties.

Six hat thinking applied to testing

Or maybe you have actually worked on a project were you tell the powers to be that the software should not be released, but lo and behold, they go and do it [...]]]>

Have you ever come across a piece of software that just  does not work and wonder, ‘How the heck did this get released?’

Or maybe you have actually worked on a project were you tell the powers to be that the software should not be released, but lo and behold, they go and do it anyway. I had cause to reflect on this question just recently …….. why does bad code get released?

There are of course a myriad of reasons and circumstances that lead to poor code being released, however once cause can be the company culture.

If developers are highly valued, and testers are seen of less value, then it is easy to see why the voice of the tester can go unheard and their view ignored or trodden over.

If testers are no tsufficiently technical or unable to write a coherent and convincing report, their message can get shot down in the general debate, or considered of little value due to the poor presentation.

If the release decision is taken place behind closed doors with no opportunity for the test report to be presented and discussed then the information regarding the true
state of the software might never be made available to those making the decisions.

Of course, there may be a number of reasons why, even though the test report is fully understood, the release is still sanctioned and bad code is released.  However these tend to be few and far between
in my experience, the main reason is that the test department of one reason or another is excluded from the process.

Who do I blame?   The test department. We need to do more to ensure we are respected, valued and listened to.

The chart below takes a slightly tongue in cheek look at an all too familiar release decision tree.

This blog lists some of my favourite spots, old and new.

New on the block is TechWell (http://test.techwell.com), from the guys at Stickyminds (which is also a favourite of mine.) This stuff [...]]]>

.Since I started to blog, and more recently tweet I have started to discover some really great places to visit.

This blog lists some of my favourite spots, old and new.

New on the block is TechWell (http://test.techwell.com), from the guys at Stickyminds (which is also a favourite of mine.) This stuff is high quality and covers a wealth of topics. I really love the look of the site as well.

The Software Testing Club (www.SoftwareTestingClub.com) is a site that has grown at an impressive rate over the past couple of years and Rosie (the founder) should be very proud of what she has achieved. It has a relaxed home grown feel about it. Some of the content can be a bit benign, but it is a great place to go for a quick answer from your peers if you get stuck.

Utest has a nice blog page (http://blog.utest.com) and manages to provide a very lively flow of content including interviews, articles information and posts. It has a nice clean layout that makes browsing easy on the eye.

The only blog that has caused me to write ‘fan mail’ is the fantastically honest QAHatesYou (http://qahatesyou.com/wordpress). As you can imagine from the name, he pulls very few punches. Add to that he has a certain warped mind that means that some of his post are incredible funny …….check out his songs for testers videos!

A nice site from the quality frog Ben Simo, is dedicated to software failures,, and should provide material to liven up a slide or two if you need to explain why testing is important, check it out. (http://blog.isthereaproblemhere.com)

I could go on, but that’s enough of that for now I think. I have set up a Software Bloggers Group on LinkedIN (http://www.linkedin.com/groups/Software-Testing-Bloggers-3945121?trk=myg_ugrp_ovr). I am hoping a bunch of bloggers might join and use it to spark off each other. I would like to issue a blogging challenge from time to time via the group. Check it out and let me know what you think.

Also why not post you own favourite testing sites via the comment box.

Let me justify that stament by starting with a little quiz.

I will give you the question, and you mark the options below as ‘pass’ or ‘Fail’ as if this were a software test,

1: What was King George VI’s first [...]]]>

Testing is more about knowing the answer than it is about knowing the question!

Let me justify that stament by starting with a little quiz.

I will give you the question, and you mark the options below as ‘pass’ or ‘Fail’ as if this were a software test,

1: What was King George VI’s first name?

A: William
B: George
C: Albert
D: Charles

2: How long did the ‘100 year war’ last?

A: 93 Years
B: 100 years
C: 101 years
D: 116 years

3: What is the acceptable load time for a standard web page

A: 2 seconds or less
B: Under 4 seconds
C: 10 seconds if containing rich media
D: 20 seconds

Of course if you know the answers, the decision to mark any result as a pass or a fail is easy, however if you just have the questions, you may not be so sure. The question may seem obvious to you, but how do you actually know what the correct answer is to generate a ‘pass’

The correct ‘pass’ criteria for question 1 is answer ‘C’ and for 2, it is ‘D’, however for question 3, there is no universally accepted ‘correct’ answer.

So you see, knowing the answer is much more important than knowing the question when it comes to testing. Requirements can sometimes hint at the answer. Lets work though an example;

‘Website links must be obvious and accessible’

Ok so my test would be,

‘Is this link obvious?’

But what is the answer?

This link has an’ under line ….. Pass
This link does not…. Fail…. Except that the link itself is blue and all the other text is black … so Pass … or fail .. er no pass!

You see the dilemma, unless it has been agreed what ‘obvious’ for each class of link will mean, then the result is open to interpretation, just like question 3 above.

The problem is further compounded by the fact that there will exceptions from time to time, so…

‘All textual links will be underlined and coloured blue’ is great, until you decided that actually, the small footer links (privacy policy etc.) will be underlined and grey. Again, knowing the answer for each link is more important than knowing the question (Is this link obvious?).

Of course in any real project you seldom get all the answers upfront, and so asking the question is an important way of getting the answer and I am certainly not saying you should wait till everything is nailed down before you write your tests. However I am suggesting that as testers we should not get too wedded to our tests and that if as a result of a test, an answer gets changed, then we should keep in mind that the answer is the important thing that drives us.

Get the right answer and you can ask the right question.

Tony Simms is Principal Consultant at Roque Consulting (www.roque.co.uk). He can be contacted via tony.simms@roque.co.uk.