Somewhere in the overlap between software development, process improvement and psychology

Testing is dead

Long live testing!

There’s an apparent conflict between the idea of a cross-functional team collaborating together on their work and specialist testers that only do testing. There’s an awful lot wrong with the “them and us” attitude between developers and testers (in both directions) in some organisations. One of the biggest problems in isolating testing from development is it abdicates responsibility for quality from the developers, it makes a poacher-and-gamekeeper culture driving divisions between people. There’s a well established cliché of development chucking rubbish over the wall, there’s also a well established cliché of testers being empire building bureaucrats who only ever say no.

The biggest problem from my point of view in having separate developers and testers is that it creates two teams (an example of Conway’s Law), a team of teams  and that causes all sorts of problems with communication, identity, culture, decision making, definition of done etc. If you’ve got a small team and you split it into two by having devs and testers you’re taking something that is potentially high performing and deliberately interfering to make it less likely to succeed. A typical management activity.

Testing as part of the team

In my teams we’ve always considered that we have to build quality into every activity if we have a hope of achieving quality in the product. That means our lowest levels of done aren’t that we wrote some code, or did a build but that we have done some testing. We have tested the basic and alternate flows, or the obvious paths through the stories. We don’t consider it stable/promoted/out of development until this has happened.

Ideally I like to do this two ways… using automated tests as part of my continuous integration to test the obvious paths and the various parameters that impact the system (checking different data sets against expected functionality etc.). The other is for the team to test each others stuff – not with a test script but with the requirement/acceptance criteria. This allows us to check what isn’t “normal”, some of the fringe cases, but mostly to check that our view of “normal” is consistent across the team and improve the common understanding of the product.

Testing isn’t done by a separate team using separate tools, it’s done by the team for the team, to deliver value to the customer.

So what about Testers?

So where to professional testers live in this world?  There is still a role for professional testers, but it’s not at the lowest level of development-testing, it’s a little higher up where having creative intelligent humans with a quality focus can provide the most value to the software value stream. Human testing isn’t especially useful for testing the normal flows, it’s useful for testing the “fringe cases” and doing exploratory testing.

Focus testing professionals on testing the end-to-end integration scenarios where many of the real problems tend to lie. Testers have a wealth of experience and knowledge of different test techniques that can be applied to address different quality risks, wasting that on simple stuff means they don’t have time to do the important stuff.


5 responses

  1. Nice post Mike, I like the point you’re getting across & I appreciate the recognition of value that Testers can provide, given the right conditions.

    I’d like to take it further though – as a Tester on a cross-functional team I don’t just test the software in the traditional sense of “testing”. By this I mean, we help deliver quality software by looking both upstream & downstream of the software being written.

    My scope has increased to help with requirements definition & drive out ambiguity to ensure we’re building “the right thing”, as opposed to just building “the thing right”.

    So as you mention, we do test against Acceptance Criteria, but we also ensure that the Acceptance Criteria are correct, which helps the development team to deliver what the Business stakeholder wants, not just what they asked for.

    As someone far smarter than me has stated “Testers are in the information game” & the faster we can make information available, the better.

    As for downstream, the whole development team monitors the Production environment through a series of graphs on a monitor on the wall. Any deviations from the trend prompts someone from the team to investigate the graphs & logs to see might be causing the trouble. This someone is generally a Tester on our team as we tend to be more reactive than the Programmers (who are proactively generating code!).

    I would find it very hard to go back to just “testing”, without looking upstrean or downstream to see how I could be providing information faster & with more efficiency.

    Thanks again for sharing Mike,


    September 24, 2012 at 12:52 pm

  2. Thanks for commenting Duncan, I agree that testers can add to the quality of the whole development effort by getting more involved in producing requirements and acceptance tests but I assert that developers should as well. I could just of easily written this as “Development is dead… long live development” to point out that developers shouldn’t be in a little stove-pipe where all they care about is algorithms.

    To my mind quality is the responsibility of everyone in the team, and it’s everyone’s responsibility to ensure the requirements are for the right thing and that there is a shared common understanding, after all, we’re all in the information game 🙂

    September 24, 2012 at 1:32 pm

    • Yep – agree with that as well Mike. Everyone on the team should be doing their part to “bake quality in”

      You could argue we’re all Developers & everyone should be able to effectively perform every role on the development team – who needs titles eh?!

      September 24, 2012 at 1:39 pm

      • Actually I’m really for dropping titles 🙂 They put people in narrow little boxes and encourage presumptions on the team’s skills and interactions. It’s a tricky balance though, the ideal cross-functional team where everyone can do everything doesn’t exist, people do have (and we need) specialisms and deep expertise. Getting that balance right is what team forming is all about I think and since it’s so variable based on the mix of people, culture and other team interactions that’s where the magic really is – also why one size doesn’t fit all in terms of process.

        September 24, 2012 at 1:54 pm

  3. Pingback: Five Blogs – 25 September 2012 « 5blogs

What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s