I felt like quite the badass after writing my last post “Ripe for Revolution “. Yep, I was a one-woman change agent for the entire testing profession. I was changing the world! In reality, my ego had commandeered the ship and was sailing for a figurative cliff. My thoughts are far from original. At about the same time, Christin Weidemann ran a session at STPCon Spring 2015 called Let’s Start a Test Revolution – A Team-Based Approach to Test Innovation. Lots of other folks are talking about the similar ideas. Which is a good thing! Let’s do it.
…my ego had commandeered the ship and was sailing for a figurative cliff.
In my experience, testers tend to accept the boundaries on the contributions they can make to a team. We’re pretty responsible folk, so we do the job we’re paid to do. However, perceived boundaries, or rigid role assignments, can keep us from learning or exploring outside of our comfort zone. This not my job mentality – or in some cases, not your job mentality – can lead to a diffusion of responsibility that erodes team potential.
The Houstonia highlighted diffusion of responsibility as a potential contributor to child drownings:
“…having too many supervising adults present might make a drowning more, rather than less, likely.”
Pretty shocking. More babysitters does not equal less risk. One attentive person is less risky than a crowd of distracted people.
The Houstonia quote vaguely reminded me of the too many cooks in the kitchen colloquialism - too many people trying to run the show. No one is responsible or everyone is responsible. As usual, neither extreme is ideal.
So, what does work?
Designated roles and responsibilities are often recommended as an antidote to diffusion of responsibility, e.g. lifeguards at swimming pools. Assuming a task falls within a designated area of responsibility, then someone will assume responsibility for that task. Managers will manage, developers will develop, and testers will test. Sounds very efficient, doesn’t it?
A static team structure with rigid roles and responsibilities can be very effective. Work gets cranked out, like a machine. Specialists get really good at what they do. Testers can specialize also, e.g. in automation, in manual testing, in mobile, in performance.
Do designated roles and responsibilities also work for the opposite problem – too many cooks?
I suspect so; once a leader is recognized and accepted. Then, the leader organizes and directs work. Ideally – there’s that word again! – the leader guides rather than dictates, allowing the team to self-organize around goals and deliverables and constraints. At work, organizational hierarchy, and hiring and firing responsibility, makes leadership and decision-making clear, even in ostensibly flat organizations.
My interpretation of agile principles is on the idealistic side, particularly where self-organization is concerned. The team collectively assumes responsibility for delivery. Everyone gets a voice in what gets delivered and how that happens. In my world, although team members have expertise in a particular area, the boundaries between areas are not rigid. A fluid team organization nurtures innovative solutions and skill development. A team driven by curiosity and commitment can come up with innovative solutions that get them in the Gartner magic quadrant.
A team driven by curiosity and commitment can come up with innovative solutions that get them in the Gartner magic quadrant.
A fluid tester learns enough about other team specializations to be supportive and contributory to those roles. A fluid tester understands the challenges each area of the product faces. Whether it’s business goals that product management must meet, or technology limitations imposed by hosting providers on developers, or event corporate branding on marketing/design materials.
A fluid tester looks for across the whole team for opportunities to support every aspect of the product.
Most teams fall somewhere in between.
They will tolerate a bit of experimentation on the part of testers. Whether baby steps or giant steps, here are some steps towards fluidity:
Find bugs that matter.
Trust me, the designers will make sure things are pixel perfect. Bugs that affect 1% of your users should only go in your backlog if a developer can fix them in 1% of their time.
Product manage your testing infrastructure and tools.
Need a new environment? Break it down into stories and work with your devs to own some of the work involved.
Know your developer environment.
Rails? .Net? Go to code school and learn the basics. Knowing how an app is built can help you find common issues.
Give insightful feedback on mockups and prototypes.
Distinguish between the malleable parts that can be iterated on and the backbone of the design. Nitpicky feedback in early stages is not helpful.
Understand the goals of your business.
Know how each feature is intended to impact those goals. Prioritize testing activities based on the business impact of potential bug areas. Slow performance on a new feature is hard to bounce back from - mobile and web performance are sometimes last in priority. Move ‘em up.
That’s all I know for now. Thanks for listening!