Tuesday, 10 January 2012

Textual description of firstImageUrl

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

5 comments:

  1. Nice post, looking forward to reading the others. Having someone lobby to get another tester in is great vindication of the work you've done.

    What do you say to those who argue that you're too close to the developers and become blind to the defects that a totally independent team might find ?

    ReplyDelete
  2. It's so cool that you share this personal journey of how you changed your views.

    I find the whole "testing is dead" debate silly and distracting. Testing has always been an integral part of software development. That isn't going to change. We should all stop philosophizing, and focus on finding better ways to test and "bake quality in".

    ReplyDelete
  3. Phil - thanks for the comment. I appreciate the sentiment regarding the risks of losing your objectivity working closely with the developers. I'd argue that this close relationship actually means that I spend less time navigating the politics between the two disciplines, which affords me more time to build on my external communications with other stakeholders and align my testing more effectively with the needs of the customer. I intend to cover this idea more in my next post in this thread ...

    ReplyDelete
  4. Lisa,

    Thanks for taking the time to comment and the kind words. I'm with you on the "testing is dead" debate, which I think relies on arguments that are limited to specific markets of consumer software. At the same time I think that it is important that we maintain awareness of the risks that face us, particularly as permanent employees where the temptation can be not to look beyond the borders of your own organisation until it is too late. In maintaining awareness of these risks we can act to avoid them, and also work to take advantage of the many great opportunities that I think are arising as roles and boundaries change in the software development field. Again I hope to expand on this idea in subsequent posts.

    Thanks again,

    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