Sunday, February 22, 2015

A lone tester's guide to her developers

Agile... the best and the worst thing that has happened to my professional life. The best in the sense of what we can create iteratively and incrementally focusing on value, collaboratively. The worst in the sense that so much of my energy goes into fighting for my right to exist and feeling isolated, different.

Here's what I keep hearing around agile:
  • We just automate all testing - there is no testing we would not automate. 
  • Only non-programmers in or close to the teams are the product owners. Testers must be programmers (because automation is all there is).
  • We can just release and monitor production and fix quickly (there's no other information we can recognise testing would give)
  • We don't recruit testers anymore at all and no one else should either
The numbers of testing specialists working with agile teams have been clearly going down over the years. Some people have become generalising specialists, working on heavily on test automation. Others have changed careers away from software. There's again fewer women working with software, as testing was the specialty with a lot of women within software. 

I kind of like the ratio of 1:8 of non-coding testing specialist (well, coding-avoiding would be more accurate) to coding developers in my team. Looking at the big picture, I wouldn't add more testing specialists, although I wouldn't have a team completely without one either. I wouldn't add more testing specialists in my team since one can already find so many problems that the whole team cannot find enough time to fix them, I would add people who fix (and would not break) things.

But the ratio has a downside: I've never felt as alone.

I'm social, and I hang out with my team. I listen to them getting very excited about technologies (SignalR is so cool, sure...), I participate in discussions about designs and value to deliver. We work great as a team but I'm not satisfied.

I miss colleagues that would be not only listen to me getting very excited about testing and bugs, but would actually share my excitement. I share my excitement with my team, only to see the same sympathetic look in the developers eyes that I have when we talk about cool technologies. So I go look for other testers that want to talk and share as my means of coping. I participate (and organise) peer conferences on testing. I go for drinks and dinners with my testing colleagues from other companies to share stories. I consume (and create) a lot of testing content online and in conferences. And I realise I'm doing this to cope and to be happy with work, not only to share what I learned as I did in the past.

Whenever testers meet, a common topic is tester-developer relations. I don't see anything being particularly wrong with my relation to developers, we are just interested of different things while sympathetic to the other's viewpoint. I again reread James Bach's A Tester's Commitments (to Developers) -blog post, and starter missing a developers guide to testers. As the single test specialist, the only one who is different in interests (and the only one that happens to be a woman in this team), it would be great if all the advice isn't about how I deal with you, the developers, but also the other way around.

Here's my lone tester's guide to my already wonderful developer colleagues, draft 0:
  1. Recognise we have different, valuable viewpoints into creating our product. You don't want to think like me and I don't want to think like you, but together we're better. Continue to listen sympathetically, just like I do.

  2. When I tell you about a bug, keep taking it as a positive thing, a puzzle we're solving together. Don't leave all the sugar-coating work to me, assume I mean well when I'm happy that it does not work quite as we wanted it to. As a stretch, try seeing things my way: finding information we did not know of it kind of cool and we could all together celebrate the fact that it was found and can be fixed.

  3. When the product works in production, I let you get the fame. You get the thanks for delivering a product that works, I don't deliver any metrics that would make us adversaries to emphasise my contribution. It would be nice that in return you actively recognised my contribution, even to a degree that you would talk about it outside our organisation for people who think that my kinds are not needed.

  4. Actively pair with me. Pair on your code. Pair on my tests. Pair on test automation. Pair on splitting the features. Don't always leave the invitation to pair as something I need to do. While I'm only sympathetic about your excitement towards details of technology, there's a lot of things I'd like to participate on without turning into a programmer.

  5. Deliver me software you think that might work. If you did not test it yourself, you're not making me feel special by noticing simple things, you're just wasting time for both of us. If you know of problems, tell me and don't keep secrets just to tell me later that you "checked if I would notice".

  6. Share with the things you have learned and what you considered difficult in creating our product. You know I will always ask for things like that, volunteer that information, help me work less to get inside your heads.

  7. Go with me to testing conferences and meetups without me forcing you to do so. Be the rare developer who shows interest in understanding testers. Listen sympathetically and seek to understand what makes us tick.  When we accidentally talk in words that exclude you, point that out so that we can be better together. Try to see our good intentions even when sometimes the ways we tell our stories offend you. And when someone talks about testing in a developer conference, go listen and tell me what you learned, show you care. 

  8. Dedicate a year of your life to learning to be good at exploratory testing, understanding organisational systems and dwelling into details of how business works. That way, I will have a colleague that would be interested in the same things I'm interested in for that year. The product owners tend to keep more distance to practicalities and believe in us just getting it to work, so they won't help me much as great as they otherwise are. And if you all do it, one after another, I will have true colleagues for years.
I still miss having people like me around, and will seek out bigger products with many teams to find the connection I'm missing now. I don't miss the times when we had siloed test teams and adversary relationships with developers, but I don't like hearing that my contributions are not needed when they clearly are.

As a minority of one, it could be nice that for just a while, the majority would work more on making the minority feel included and appreciated, welcome. My team tends to do that, while my community - agile - tends to have more challenges in that. If I wanted to stay where I am, I wouldn't feel bad about what happens in the world. But there's still many more places for me to contribute at, as I serve 2-3 years per organisation.

This tweet seemed very appropriate addition:
Stop trying to make testing go away when it still delivers relevant value. Checking is not testing. We need both, in a skilled manner.


  1. What I'm seeing is a Lone QA's Guide, highly relevant to security folks as well. Would you agree?

  2. After you start thinking like you wrote, your are starting the fight in your team - tester vs devel.
    All your points are showing that team is missing one important thing of so called agile - team mindset.
    Your team mindset is still in 90's - I code you click.
    People should ask why she/he is a tester/developer? And why she/he is in a team?
    If the first answer is money and good job, then i think people with that mindset are not Team players.
    And the second answer was like "they put me here and now I have to deal with it". Then there is nothing to discuss more about that person in this team.
    If You are not a team player and are in team then leave the team or fix your mindset to be a team player.
    For me the mindset means
    * We are team.
    * We all are responsible for what we do on all roles in team.
    * We want to create better product then we can
    * We improve team ( work process/flow , technical tools )
    * We are not afraid to learn more about other skills ( tester=>dev , dev =>tester )
    * ...

    All teams have n members where all of them have one skill that is the main skill. For developers it is writing code , analyze, write unit tests ... But same time in team everyone should know base things of other member main skills or they should know from where they can find help if they are "alone" and have to deal with other member main skill tasks ( for example tester(s)/developer(s) is sick ). If team can handle this situation and client gets what was promised then they are really great team :)

    People should care more about what they do and how they do and if they can somehow be helpful to other members.
    For example If developer codes some business functionality and will not document it or tell it to anyone, then :
    a) tester time is wasted - first tester will try to find it from spec and then will ask from developer
    b) developer time is wasted - developer will try to explain what was done and why and then will document it if it was a correct solution. If not then the wasted time will double.
    c) client is not happy - time/money wasted and still no product

    That simple example happens everyday everywhere and is one reason why that team is not a team.

    I just wanna to say that sometimes teams where we are, are not for us and sometimes we can not do anything to change that except changing team :) In most cases the last thing is the best solution - You will shine and others will open ther eyes and shine also :D

    It sounds great but Testers/QE/SQE/QA should start to carry the world fix role and teach others also to do things better every day :)

    Best Regards

    1. My team isn't fighting even as of now, we work together quite nicely. Not into something is not the same thing as not being afraid - as in learning new skills. While everyone could do everything, seems people have stronger areas of skill, and we also like working on things we like working on, collaborating. Your idea of what "team player" means seems very narrow and as such, I do not agree with you.

      Product owners are team players focusing on business aspects of the common goal. I suggest that the type of "tester" I am, I'm much closer to a product owner than a developer. Not because of what I can do, but what I'm interested in.

      Your simple example seems also a little peculiar to me: without a word being said, I could see from version control that a change has been checked in. Without documenting it in spec, I could still see if it fits the context of the product vision we work on in general. And since probably we're designing it together, it's not about telling or documenting.

      I agree on helping fix the world though. Seems that my idea of what the world looks like when it is fixed does not seem to match yours.