Knuckling Down

Having attended this year's TestBash conference in Brighton I come away from it with mixed feelings. It was fantastic to see so many testers who were clearly passionate about testing, and the atmosphere was vibrant. On the other hand I felt that there wasn't quite as much variety around the talks as the previous year, in terms of both gender of presenters and subject matter, the latter noticeable particularly the middle of the day. At least three of the speakers' opening gambit was to admit a history of ISQTB before discovering a more enlightened path of a context driven approach. (As anyone who has read this post will appreciate I am not a fan of ISQTB, however this repetition, combined with the intensity of multiple half hour talks with no breaks and no natural light, evoked a mild feeling of being in a recruitment meeting for a religious cult).

One of the messages that came up in more than one of the talks during the day, most strongly in Huib Schoots talk on Context Driven in Agile, was the need to stick to the principle of refusing to do bad work. The consequential suggestion was that a tester should leave any position where you are asked to compromise this principle. As anyone who has read my previous post will be well aware, I am a strong believer in taking an approach based on integrity, and I have a lot of sympathy with what was being presented here. Saying that, I think that we need to be very careful as an industry of the message that we are portraying, as the one interpreted could be very different from that intented.

Leaving so soon?

On the face of it the idea of leaving projects on the grounds of principles rather than doing what they perceived to be poor testing is a sentiment that I agree with. If you are working on a project where the limitations placed on your ability to do good testing with no avenue to circumnavigate these then I can totally understand that moving on should be considered.

What was missing for me in the sentiments presented at TestBash was any suggestion that testers should attempt to tackle the challenges faced on a poor or misguided project before leaving. In the examples I noted from the day there was no suggestion of any effort to resolve the situation, or alter the approach being taken. There was no implication of leaving only 'if all else fails'. As an employer of testers though I'd like to see an attitude more around attempting to tackle a bad situation head on rather than looking at moving on as the only option. Of course we should consider moving if a situation in untenable, but I'd like to think that this decision be made only after knuckling down and putting your best effort in to make the best of a bad lot.

Inform Decisions

Huib in his talk highlighted the need to restrict testing to being the providers of information to business stakeholders to inform decisions, not to be part of the decision making process, which is a common sentiment in testing circles and one that I generally agree with (although I do feel that in an empowered team, testers can take on some of the decision making responsibilities in collaboration with the other roles).

I felt that this presented an interesting juxtaposition for testers. On one hand we are saying that we should restrict our activities to providing information to informing decisions. At the same time we are refusing to perform bad work, where a major factor in the quality of the testing work that is possible will be the decisions that are made. Whilst I can see that these principles are not contradictory, I think that there is room for confusion in the interpretation that could lead testers to the conclusion that moving on is the only option when decisions have been made which present challenges for testing.

The root of that ambiguity lies in the phrase 'bad work' and the possible interpretations of what could constitute bad work for testers. In many scenarios testing projects have constraints or limitations in place that restrict testing activities that some might see as 'bad work', but I feel that it is still possible to do good testing in these situations. In fact it is in the more challenging and time constrained projects that knuckling down to perform excellent testing to quickly expose information is most valuable.

• Not having sufficient time to test?

One situation which causes concern for testers is when they feel that there is insufficient time for testing. This is typically the result of a business decision to impose time constraints, sometimes based on rigid deadlines, often arbitrary targets, but outside of the control or influence of the tester.  As long as they clarify the risks imposed in the limited information that they will be able to uncover, then a skilled tester can still add a great deal of value in uncovering as much information as possible in the limited time available. These presentation slides from STARWest 2011 by Lynn Mckee and Nancy Kelln provide an excellent summary of test estimation issues and predefined project constraints, and also a superb set of references to further reading including a lot of writings on the subject by Michael Bolton.

• High risk approaches

Testers provide information to inform decisions. If those decisions involve unneccessary risks this can have dire consequences for the project, but does not mean that the tester has done bad work. I've certainly been involved in projects where I've not been in agreement with the risk decisions that were made regarding the product in question. As I've discussed in this previous post, the levels of risk adoption in a business are unlikely to change, however there are various approaches that I've adopted in the situation where I felt that the decisions had a negative impact on the testing and the project as a whole. These primarily involved exposing and presenting risk information to the business that may not have been available previously. I'll expand on some examples of these below.

• Inappropriate test approaches

Some projects may be characterised by the business decision makers dictating the testing approach. This is a more challenging situation, and one that I've been fortunate to avoid for most of my career. I have been in the situation where I was being told what to test, which involved focussing on the obvious user interface features at the expense of investigating more fundamental server stability issues. I've also been on projects where the development manager was advocating a lightweight manual testing approach where the use of appropriate automation tools would have dramatically improved the testing effort. In these situations I've had to take steps to address the situation, and this has not always been easy.

One of the most difficult skills I've found to learn as a tester is the ability to justify your approach and your reasons for taking it, and being able to argue your case to someone else who has a misguided perspective on what testing does or should involve. Having these discussions, and changing peoples minds, is a big part of what good testing is.

Avoiding Bad Work

I certainly don't believe in knowingly doing bad work, but I do believe in attempting to put in every effort to improve a situation. Having worked flor a long time as a permanent employee in small reactive technology companies I've been involved in a variety of projects, some better conceived and delivered than others. In situations where the testing risked being compromised I have had to dig deep on more than one occasion to try to recover a bad situation and deliver a successful result. Here are some of the approaches that I've found to be useful when trying to change the direction of a project towards better testing.

• Pointing out the Risks

I've found a risks map to be a useful tool in highlighting the problems faced on a testing project. For example with the utility that I wrote about in this post on Testability where the testability was limited, I explained the situation to the management with the use of a Testability map that broke down the types of exploratory and automated testing that I felt was appropriate on that product, with icons highlighting areas which were inaccessible to testing in the time available. This formed the basis of a discussion around the approach to be taken and an agreement around improvements needed to progress the testing work.

• Stories on the backlog

In an agile approach we tackle work in the team through the scheduling and prioritisation of user stories. If we feel that the testing of a certain feature is inadequate then an effective approach is to add stories to the backlog targeting the customer value that comes from the extra confidence that the testing can provide. This places into the hands of the business the decision to prioritise that testing work based on the value that is derived from it.

• Using groups

A group discussion or exploratory testing session can help build confidence and cohesion in the testing group before raising concerns with management. In situations where myself and the testing team have had concerns over the suitability of a product for customers then I have arranged group exploratory testing sessions in the form of tours from the perspective of the relevant users. Discussing openly and critically the value of the product helped to gain a group understanding and provide confidence in raising our concerns to product manager at the time.

• Just doing it

If the approach that is imposed on a testing effort is invalid for the context, then I'm a strong believer in taking the time and using a dose of professional flexibility to do what I feel is right anyway. Sometimes it is necessary to go the extra mile to do enough to demonstrate the value of a different approach. I was once being pressured to take a very limited testing approach on an API integration that was highly volatile and I felt that a level of automation around the interface was appropriate. I freed up some time during the working day to create a simple harness and then spent my evenings learning Java to develop a more extensive test suite. This was invaluable in helping to highlight basic regressions in further deliveries of the integration and also as a tool in facilitating further exploratory testing.

A Ray Of Sunshine

This is the kind of thing that wanted to see more of in the talks at TestBash - practical examples of how people have avoided bad testing by tackling difficult testing challenges. Thank goodness then for Chris George from RedGate in the penultimate talk of the day. Chris recounted a story of himself and a developer getting stuck into a test automation problem that had been estimated and needing 6 months of work, and through a can do attitude and a healthy dose of intelligent hard work, achieved a successful result in a short time.

The testing community is going through a fantastic period at present with more and more testers passionately promoting testing as a skilled profession. With the best will in the world, not every project that we work on or role that we step into is going to be initiated from an enlightened position of appreciating testing as a highly skilled role. Working on improving the testing effort on poorly conceived projects could be an opportunity to demonstrate the value of testing and the information that we can provide to a new audience. If testers capable of changing peoples' perceptions about testing and thereby improving the status of the testing profession take the approach that they will move on as soon as they are presented with a request that offends their testing sensibilities then that is an opportunity lost.

Image: http://gimp-savvy.com/cgi-bin/img.cgi?noabSlKvExKIYUk1200