Basic rules for testing for non-testers

Even where Agile teams include expert users, there are still key vulnerabilities in their coverage of the whole end-to-end development process – especially in testing.

In mature Agile teams, developers should have good testing skills too. But given that most teams aren’t mature and the trend to retain separate development skills (business analysis, design, programming, testing) suggest this may never be the norm.

In the case of testing, then, what are the key things for users and developers to remember?

  1. Always define the expected result before carrying out the test. Make sure it’s objective and complete. Without that, the temptation to see a result as ‘good enough’ can be overwhelming, especially where time is running out – as, in testing, it almost always is.
  2. An unspoken requirement of many systems is that it should be as good as what it replaces. So if the stories you’re implementing are replacements for existing functionality, do they do at least as well as they used to – even if that’s not written into individual stories?
  3. Make sure you check any options within the main story. Have a clear list of what they are.
  4. Does the software work on the boundaries of pass and fail? Just this side of the boundary? Just the other side? And if the boundary is, say “29”, is 29 itself a pass or a fail?
  5. Check the transitions to neighbouring stories. The whole of a set of stories is almost always greater than the sum of its parts, so you need to check that the story under test is playing its full
  6. Check that the story works the way you wanted it too – that the how is right as well as the what. if it doesn’t, otherwise it’s unlikely to support your wider purposes. Make sure the relevant controls all work too.
  7. Remember who you’re testing for. Users seconded to Agile teams should be experts, but how many of its real users will be? It’s easy to take for granted your own knowledge, but will less experienced users see this software the same way as you?
  8. Experiment! No test model or script was ever complete, no test author ever thought of everything. So when you see something you weren’t expecting, try it out. If a good idea suddenly pops us – try it out!
  9. Write down any issues or defects. Any departure from your expected result is a defect. Make sure you have evidence of exactly what happened. Capture screenshots. Don’t rely on memory.
  10. And make sure that when you’ve fixed any bugs, you retest not just the bug itself but also anything you aren’t absolutely certain could have been affected by the fix. Regression testing is vital.

But the true ‘right answer’ remains the Scrum Guide’s advice:

  • Scrum recognizes no titles for Development Team members, regardless of the work being
  • performed by the person;
  • Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

In other words, even if different team members possess some specialised development skills and lack others, there is no assumption that specialisation is a good thing, and the key question is to how readily can the team bring the skills it collectively possesses to bear on the current work.

By |2018-09-06T17:45:56+00:00Thursday, September 6 2018|Categories: Agile, All, Process and method, Skills, Testing|0 Comments

About the Author:

Chief Architect,

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.