My first morning at Agile Testing Days started badly. I discovered that it was not possible to make coffee in my room at the hotel. This constituted something of a bombshell for me if I was to survive long enough to attend any of the sessions, so I set out to find some. My nose soon sniffed out a cluster of coffee pots located in the bar area. These pots of life saving elixir happened to be accompanied by Janet Gregory who was writing post-it notes and sticking them on the table. Realisation dawned that I had inadvertently wandered into the early LeanCoffee session run by Janet and Lisa Crispin. Anyone not familiar with the concept of LeanCoffee can find our the format here, but basically it is a way of raising and prioritising subjects for group discussion, KanBan style. Feeling too embarrassed to leave, I stayed for the session, and the coffee. Unsurprisingly I thoroughly enjoyed the discussions on that morning and returned again on the Thursday, this time a little jaded from late night discussions the night before, for another session (apologies to Lisa and Janet for arriving late, and a slightly funny colour, to that one).
One of the subjects that came up on that Thursday session was - how to get respect in a new team where the developers don't know you. This was one that I felt strongly about. I've felt that I have achieved a good respect for testing in previous organisations, sometimes from an initial postition of negative perception when I joined. I battled the mild nausea that was competing for my attention to give my thoughts, which I think merit expanding on here. I proposed that two characteristics that a tester should display if they are to quickly gain respect from the developers in a new team or company are integrity and pragmatism.
Testers can make an instant impression in a development team by showing integrity in how they behave towards issues that they encounter. When carrying out our work we need to consider the fact that someone else's paid time and effort went into the creation of that which we are testing. Integrity is a trait that is easily missed in testing, and its absence is costly when it comes to intra-team relationships. Finding a bug, or even lots of them, is not an opportunity for self aggrandisement at the expense of others. If you use your bugs as weapons to increase your own stock at the expense of the programmers in your company then you undermine your integrity and diminish respect in yourself and testing as a profession. If with every bug you discover you loudly bemoan the state of the product, or run to management to complain about the quality of the code and lack of developer testing, don't expect respect to come flowing from the programmers that you work with.
I've see or heard more than one account of testers who deliberately hold back the details of the tests that they are planning to run so that they can increase their personal bug counts on which their bonus structure is based. Clearly there is an inherent problem with testing cultures based on reward mechanisms that can be gamed in such a fashion. For individual testers to resort to such deceptive means to achieve these rewards, in my opinion, means that they come at the expense of the greater reward of the professional integrity of the tester and the respect of their colleagues.
Integrity for me comes through taking a principled approach based on honesty and openness. It's about being consistent and open about what you plan to do, what you do do and what you find when you do it. It's about using information for the good of the team and the business over the good of you as an individual. It is about taking the bugs that you found back to the developer and quietly discussing them rather than shouting them from the rooftops. Most importantly it is about sticking to your principles and presenting a consistent message between programmers, managers and any other business roles with whom you communicate. It is not about twisting results or outcomes to manipulate situations to your own ends. If you as a tester can demonstrate such characteristics then these will win the respect of any development team far more quickly than raw skills or self promotion will.
One working relationship in which I achieved a level of respect in a difficult situation was with a development manager who adopted a particularly confrontational approach. Many in the team found this approach hard to handle. In this relationship I ended up achieving a high level of respect in what others found to be quite difficult professional circumstances. In conversations with this manager he suggested that one of the reasons he most respected me was due to my adopting a pragmatic approach in my testing work. Some testers are inclined towards an approach based on the achievement of arbitrary quantifiable targets driven by testing dogma. I personally prefer an approach that considers levels of testing and individual bugs flexibly in context of the current business goals.
Again I find that the greatest opportunity to quickly earn respect through displaying pragmatism is in the approach to bugs. Pragmatism in handling bugs comes from being prepared to examine each issue independently on its own practical merit rather than insisting on achieving arbitrary goals. I have found that adopting such an approach quickly gains an appreciation from the development team as someone who exhibits flexibility and judgement in how they tackle their work.
Pragmatism also comes from considering feedback from real customer experiences to modify our future testing and approach to bugs. Pragmatism is about focussing on the practical outcomes rather than theoretical models. Working to gain an inisight into the real practical consideration of the users of the software and using this knowledge to help the development team as a whole is key in this endeavour. Real customer feedback allows us to focus on the most important high risk use cases. This increases the testers value to the team and helps to add gravity to their arguments when they do raise issues as a high priority.
Adopting a pragmatic approach does not mean that you are a pushover. When developers understand that you make measured decisions based on evidence and feedback then this helps others to appreciate your position when you do take a stand. In the relationship that I mention above I had to stick to my principles on more than one occasion on other issues such as protecting the work-life balance and ensuring a maintainable pace of work. The respect that I had gained for my approach to work helped in such situations to ensure that my position was respected, even if it was not agreed with.
Testers Don't 'Deserve' Respect
Given the number of times that I have seen the question raised by testers in various forums on how to get respect, certain testers seem to be particularly obsessed by it. This is probably indicative of an implicit hierarchy between developers and testers in certain organisations. I'm not going to explore the reasons for that in this post. What I will say is that I don't believe that testers deserve respect simply as a result of their role. There are jobs, from Medical Surgeons to Presidents, Prime Ministers and the Head of the United Nations, that merit the holder a degree of respect simply on having achieved that position. I am sorry to break it to you but software tester is generally not such a position. Pretty much anyone can claim to be a software tester. As a field the entry requirements are low. Whether you deserve respect in the job therefore depends on you.
You may ask whether we really need respect from developers? Surely it is possibly to operate successfully without it? Whilst I'm sure that it is possible to perform testing in a situation where the developer do not respect your role, it is not going to be an enjoyable process. As I discussed in this post , the factors that provide the greatest motivation in our work are the factors that are intrinsic to the work itself. Respect in the role is an important one of these factors. A position where respect from ones peers is not forthcoming is far less intrinsically motivating that one where it is. Additionally as I discussed in this post, one of the ways that I feel that the tester role can change in light of changing team structures and agile teams is in helping to make decisions. This only comes about if you have achieved the trust that comes from the respect of both the business owners and the development team to act with pragmatism in the best interests of your organisation.
Respect doesn't come automatically. As I've mentioned often the converse is true and in order to gain respect you first have to overcome the negative perceptions associated with testing as a role. Too many testers believe that obtaining programming skills will redress the balance and garner respect from developers. Whilst some degree of programming skills are useful you are always going to struggle to attain respect from a group based solely on a skill at which they are more accomplished than you. Instead I find that respect comes from what I do as a tester, and even more importantly, how I do it. Using critical thinking to find logical flaws and find bugs, for example, is an important and necessary skill. I believe that the displaying integrity and pragmatism in how you manage those bugs will have more of an immediate influence over the respect that you achieve from the developers in the team.
The sort of respect that I want to achieve in my work goes beyond mere professional courtesy, and relates to me as an individual. It is the respect that makes people stop and think. It is the respect that makes them mention how impressed they are with you to colleagues or managers. It is the respect that breaks down barriers between roles on a basis of professional equality. I believe that the worst way to try to achieve such respect is to go looking for it. Stick to your principles, work for the good of the team and organisation rather than yourself and show integrity and pragmatism in your approach, and respect should find you. And the more testers there are out there are earning respect in this way, the greater the respect that will develop for the role in general, which is something that we'd all like to see.