Friday, 20 January 2012

Textual description of firstImageUrl

Survival of the Fit-Tester (2) - Symbiotic Relationships


This is the second post in my series thinking about the threats that face testers in the current UK market. In my first post I looked at how getting engaged with the developers on the team helps to blur the interfaces between developers and test and reduce the risks of outsourcing the whole test operation. You could argue that, by getting close to the developers, we expose ourselves to the counter-risk of having our testing absorbed into the developer activities. Another possible criticism as Phil Kirkham pointed out in his comment on my last post, is that there is a risk that by getting closer to the development team we lose objectivity in our testing. What I have seen in my experience is that, by working more closely, testers and developers actually communicate more fluidly and reduce the amount of time spent negotiating the interfaces between them in the form of bugs. I certainly don't intend to criticise the excellent work on the subject of "Bug Advocacy" developed by Cam Kaner as part of the BBST syllabus, but the existence of this subject to me reveals a high level of focus on an artifact of communication between members of the same team which becomes less relevant with improved communication. By engaging with the developers and reducing the focus on those internal interfaces I find that this frees testers up to focus on other relationships in the organisation.

Symbiotic Relationships


In this second post in the series I'll discuss how forging other relationships within the organisation can work to maintain, if not tester objectivity, then at least a balanced subjectivity from the relevant perspectives. By creating relationships with other key roles we can gain a greater insight into the customer needs to improve our testing within the development team, whilst at the same time adding value to the individuals in those roles. This mutually beneficial communication creates a "symbiotic" relationship, helping to consolidate the testers position as a key member, not just in the development team but within the organisation as a whole.

Support


The support team are a fantastic potential symbiotic relationship for the tester on an ongoing product development. From the support analysts perspective, having a tester with in-depth knowledge of the product as a close contact can be a great asset. From the testers perspective the support team are a direct interface to the actual users of the system.

As well as having invaluable insight into the issues that are being reported the support staff also gain the benefit of informal perceptions of the product from speaking to the customers. If testers can tap into this knowledge then we can add realism into our testing scenarios and depth to our test personas.

In my previous role on a traditional project based development team I enjoyed an excellent relationship with the support team. I would provide help with their issues and, in turn, would learn about what the customers were really doing. In my current role this has gone one stage further with the myself and some of the other testers actually taking on the support responsibilities. This started out informally in our early implementations, where we used our product knowledge to help the customers through their initial integrations. As we have grown as a company we've formalised this into a Testing and Support Team. We've developed the need for devoted support people as the customer base has increased, but we still tackle this as a single team with the testers providing direct assistance with issues and advice to customers.

My dual role leading this function is challenging but provides myself and the other testers unparalleled insight into the customer usage of the system. We use this insight to help avoid mistaken assumptions in requirements elaboration, and to focus our testing. In addition to better testing this dual role also protects the team by ensuring that testing is an integrated part of the outbound product delivery structure.

Pre-Sales and implementation


As well as technical support, my last two product companies have also had pre-sales and implementation teams. Again there is the potential here for great mutual benefits from forging close relationships. The early stages of an implementation are a critical time for the product. Being able to inject relevant knowledge at the appropriate time can really help to drive the success of an implementation. In return, the tester can obtain early visibility of the projects in the pipeline and raise the need for additional testing should it become clear that a risky area is going to be exposed by a new project.

Implementation projects can often involve addition infrastructure work on top of the vanilla product. Gaining exposure to these gives a great insight into how the end product will be implemented and used and can be a great trigger for exploratory testing.

On the softer skills side, Pre-sales and Implementation folks are usually excellent at communicating with customers as well and I have certainly improved my own communication skills and professionalism from working closely with these roles.

Training and Documentation


I am lucky enough to have our technical author in my team. She also happens to be a fantastic tester. Through the process of documenting the system she tries out all of the syntaxes and commands that she documents, identifying many inconsistencies and bugs in the process. In turn she benefits from close communication with the testers to answer questions on target product behaviour and investigate issues that she finds. Along with the developers, the test team also review the documentation that she produces. This helps by checking her work, but can also be a great trigger for exploration. Complicated areas of documentation can indicate a confused workflow and potential for issues, I usually finish a document review with a set of notes to follow up myself of areas that I want to revisit or ideas for new avenues of exploration.

If you have a technical trainer then a good relationship with testing can work in a similar fashion. Having to train others forces you to question inconsistencies and having inquisitive testers on hand to follow up on those questions is a great help.



Building symbiotic relationships is a great way for us as testers to reduce the risks that may threaten our role. By gaining crucial insights from the outward facing teams and maintaining a balanced perspective on the product we increase our value within the team and differentiate ourselves from the developers. By using our own knowledge to add value back to these roles we increase the number of strong connections that we have in the organisation, again making it hard to isolate the team's input and reducing the risks of outsourcing.

Of course, probably the most important symbiotic relationship that a tester can develop is with the customer or product owner, which will be the subject of my next post...

7 comments:

  1. Great post!
    Completely agree with the idea that communication/building relationships is a key element in any team activity.

    However... I see problems arise in situations where the sheer number of employees in a company can become an obstacle; but also in a non-agile environment.

    Bug Advocacy comes into play whenever:
    1) Developers do not have the liberty/time to fix issues as soon as they are reported (write it down, will deal with it in a few.. weeks)
    2) There are just too many people - the tester does not know which devloper (or which team of developers) to contact with specific issues.

    Of course, even in those situations, there is still a lot to gain from symbiotic relationships.

    About tester objectivity; I have a special attitude towards this. I believe that it is a tester's job to be AWARE of biases and use his experience and skill to OVERCOME those biases, instead of relying on PROCESS to AVOID the biases (in this case, being seperated from dev).

    ReplyDelete
    Replies
    1. Rasmus,

      Thanks for commenting.

      With regard to increasing numbers of employees and longer feedback loops associated with non-agile, certainly careful bug documentation is required.

      I'm not against the idea of Bug Advocacy at all. In the situation where an issue is not going to be looked at immediately, thorough documentation of the issue is essential and am lucky that my team are very good at this. My point was more that the need to influence and "sell" bugs is less in more integrated teams and therefore the process of communicating via bugs and tracking systems becomes less of a focus.

      Great point on tester objectivity - there is a good summary of cognitive biases to be aware of here http://www.quora.com/Psychology/What-are-the-most-important-cognitive-biases-to-be-aware-of

      Cheers,

      Adam

      Delete
  2. +1 to this post. Get as many insights and as much information from as many viewpoints as you can.

    One project I worked on I became 'the expert' and tricky support calls were routed to me - which then led to me finding out even more about how the users out there were using the system. The sales guys would also come to see me to work out how to best demo the system to potential prospects. Increased my value to the the team and again, was another source of information for my testing

    ReplyDelete
    Replies
    1. Phil,

      Thanks for taking the time to comment. Your experience really shows the value that you were adding in this organisation. As a tester, not just testing the product but also helping to improve the sales demos to increase sales - perfect example of a symbiotic relationship with the sales folks!

      Cheers,

      Adam

      Delete
  3. "reduce the risks of outsourcing the whole test operation" - seems like the post has a hidden motivation also :)

    communicating is definitively a very important factor.
    however in IT field people tend to keep some distance between colleagues. some want to just focus on their part and not be too bothered. this mentality has to be taken in consideration in your described cases.

    ReplyDelete
  4. Hi Sebi,

    "seems like the post has a hidden motivation also :)"

    Hopefully not that hidden! Through various interviews and meetups I have spoken to dozens of testers in recent years and one of their main concerns is the risk of outsourcing the whole team. I think that, whatever your position, maintaining awareness of the threats that caould affect your job is sensible practice and my personal approach to trying to minimize the risks to my team are the motivation for this blog thread.

    "some want to just focus on their part and not be too bothered"

    This is a sad situation but is one that I have encountered before. When I encountered this issue it was actually the developers who weren't interested in communicating outside the bug system. In that situation I think that the tester can really show their value by stepping up and making sure that they increase their available channels of communication beyond the immediate team. People in the roles I've mentioned here generally won't turn down the opportunity to gain great information to help them with their jobs. The more relationships that a tester can develop the lower the impact of one uncommunicative individual has on our role.

    Cheers,

    Adam

    ReplyDelete
  5. I spoke on this subject at the Ministry of Testing TestBash in March 2012. Check out the details of the day here and the full video of the talk here.

    ReplyDelete

Thanks for taking the time to read this post, I appreciate any comments that you may have:-

ShareThis

Recommended