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...

Survival of the Fit-Tester (1) - Get Engaged

There seems to be a lot of discussion in the testing community at the moment over the future of testing. A series of recent blogs and conference keynotes have even broached the subject of the death of testing. Personally I'm not convinced by the level of threat suggested, but I do believe that there are growing threats to what many perceive as a traditional role of a tester, certainly in the UK community in which I work:-

• The increase of XP and agile adoption has embedded a focus on testing into programming practices to the extent that some believe there is no longer a need for separate testing other than that done by programmers.
• The increased maturity of outsourcing provision makes the offshoring of testing activities a tempting alternative from a management perspective

In this and one or two subsequent posts I'll discuss how both my role and, more importantly, my personal opinions have changed and try to identify ways in which I see testers can evolve themselves to reduce the impact of these threats on their livelihood.

Getting Engaged

Six years ago it was my firm belief that it was desirable to have the test team located separately from the programmers. This is a viewpoint I have encountered more than once - for example I interviewed for a job around that time where the test team were actually located in a separate city from the developers, and remember thinking that this was a great idea.

The stance of a distinct and isolated testing service has a number of advantages to many people, not least testers themselves. I believed separation from the programmers would permit me to adopt a position of distinct objectivity. Testing can rightly be perceived as a very critical activity and the temptation in this situation is to isolate ourselves from the creators of that which we are criticising. This isolation gives us the freedom to dispassionately criticise the software, protected from the pressures of having the authors of that software in the same room.

Testing is also an activity which can come under heavy criticism itself, particularly in the scenario where bugs are not detected before release. By propogating the idea that our testing activity arises from a series of well defined and standard best practices we can abstract blame from our own personal decisions and walk away indignantly from project failure with our self satisfaction in tact - a stance exemplified by some of the opinions in discussion forums such like this one.

By defining interfaces and artifacts through which to absract ourselves from direct communication, requirements documents coming in and test scripts and bug reports coming out, we protect ourselves from the personal feedback that comes from criticism in both directions.

The problem with this type of stance, and the focus on testing artifacts as our deliverables, is that it is the very idea of an isolated service that makes it so ripe for outsourcing. By selling this idea of a discrete entity characterised by well known best practices and clearly defined, standardised interfaces we serve directly into the hands of the outsourcer and the service provider the opportunity to offer cheaper replacement services in direct competition.

A Personal U-turn

Having worked with the team that I do now, my opinion has come full circle from my beliefs just a few years ago. In order to achieve success in my current team as a tester I have found it necessary to alter my stance with regard to the relationships between testing and programming activities to have a much greater focus on a closer collaboration between the two. I think that the most effective testing comes about through working amongst and alongside the programmers, developing software as a whole team activity.

For their part in this process, Testers help to identify future requirements, we help to elaborate user stories, we identify test accepance criteria, we highlight risks and assumptions, we exploratory test early deliverables, we automate regression tests, we raise bugs at each and every stage of this process and work with the developers to identify the best solutions. I'm not stating anything new here, but I do think it worth highlighting two key elements:-

• There is no clear deliniation across which the testing activity can be defined
Last month I raised a bug in a whiteboard discussion on a proposed product change. No code had been written, no test case defined, I simply used my knowledge of the application and the customer usage to highlight a potential problem during early exposure of a proposed solution to testing. By making this type of testing intrinsic to our design and development activities it becomes very difficult to define where testing starts.


• There is clear value in what we deliver to the developers
The nature of our relationship with the application developers gives me the confidence that they would be the first to speak up in defense if anything threatened the testing team. In fact, some time ago when it was suggested that my counterpart on the development side take on two more programmers, he actually lobbied senior management to consider taking on one programmer and one tester instead due to the benefits that an additional tester would bring to him.

Closer collaboration between development and test is hardly a new concept, yet having interviewed and spoken to dozens of testers in the last few years, it also seems to be quite rare. I've spoken to a number of testers who report to be working in agile developments yet still receive infrequent builds from a remote development team and communicate through bug databases. As well as having a very positive impact on my professional relationships I believe that my change of position in this regard has also served to help to protect myself and my team from the threats mentioned earlier. While it would be foolhardy of me to suggest that I am immune, I do firmly believe that the strong relationships that we have in the development team offer far more protection from than is enjoyed by these more discrete testing operations. We also offer a better testing service because of it.

In subsequent posts I'll investigate other complementary relationships and related responsibilities that have helped to redefine my current role from the tester job that I once thought I knew...