Agile Software Dev Automated Acceptance Testing Automated Testing

Answer ‘Will it work?’ over ‘Does it work?’

Software teams must continually answer two key questions to ensure they deliver a quality product:

  1. Are we building the correct thing?
  2. Are we building the thing correctly?

In recent times, I’ve noticed a seismic shift of a tester’s role on an agile software team from testing that the team is building the thing correctly to helping the team build the correct thing. That thing can be a user story, a product or even an entire company.

As Trish Khoo recently wrote:

“The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end”

It’s more valuable for a tester to answer ‘will it work?‘ at the start than ‘does it work?‘ at the end. This is because if you can determine something isn’t the correct something before development is started, you’ll save the development, testing and rework needed to actually build what is needed (or not needed).

But how do we know it actually does work if we’re focused on will it work? How do we know that we’re building the thing correctly? The answer is automated tests.

Automated tests, written by programmers, alongside testers, during the engineering process validate the software does what it’s meant to do correctly. Behavior driven approaches assist to translate acceptance criteria directly into automated tests.

So, how can a tester be involved to make sure a team is building the correct thing?

  • get involved in writing the acceptance criteria for every story;
  • ensure a kick off for each story happens so the programmer(s) understand(s) what is expected and any edge cases or queries are discussed;
  • work with the programmer(s) to automate tests based upon the acceptance criteria;
  • ensure a handover/walk-through happens as soon as a story is finished in development to ensure that all the acceptance criteria are met and tests have been written;
  • showcase the finished product every iteration to the business.

You’ll soon find you can provide much greater value as a tester determining whether something will work and then working alongside the development team to ensure it works as it is developed.

0 replies on “Answer ‘Will it work?’ over ‘Does it work?’”

Great way of saying it. Lately I’ve realised I have a habit of assuming that everyone knows that solid automated testing is important, so I don’t bother mentioning it. But it definitely needs to be pointed out.

Some would argue that the job you’ve described sounds more like a Product Manager role than a testing role. But I don’t see this as a problem – in my experience I’ve been providing a service with activities that overlap with Product, Development, Project Manager and DevOps. I’m still doing a different kind of analysis from each other person in the team and bringing a different type of skill to the table, so I don’t see the need to shoehorn it into another type of role if something’s working well.

If we’d like Testers to get involved in building the right thing I would say the role of testers on an Agile team should go further than writing Acceptance Criteria & Automation.

I don’t see why Testers (and rest of the team) should not get involved in writing stories, Just provide the team with a Goal (increase amount of new sign-ups from x to y), then let the team, together with PO create the stories.

I believe that most agile teams are not realising the full potential of the team. Developers and QA have insights into technologies and processes that sometimes Business are not aware of.

With smart use of metrics to examine customer behaviour/activity and by constantly probing the interest in potential new features by using fake features and such, teams can get better at building the right thing.

Leave a Reply

Your email address will not be published. Required fields are marked *