Riding a horse requires the involvement of the horse!

Riding a horse requires the involvement of the horse!

Effective testing scenarios require a tester to work with users, product owners, business analysts, developers and others to determine whether a deliverable is what it is supposed to be, whether it meets the definition of done and standards of quality. Testing is a collaborative enterprise. Testing is less effective when the right people are not involved in testing. In order to meet the basic level of collaborative involvement for effective testing, testers need interaction with the broad stakeholder community in three broad categories of activity. They are:

  1. Developing requirements – Requirements, whether written as user stories, use cases or paragraphs of text, are a critical input into the testing process. Requirements become the basis of comparison to determine if what is being developed is what the the business wants. Business and technical stakeholders provide the input that becomes the requirements. Testing provides feedback to challenge the assumptions of the stakeholders and development teams as the requirements are formed, groomed and transformed into functional code.
  2. Defining realistic acceptance tests and criteria – A well-formed user story includes not only the story itself, but a set of acceptance criteria. Acceptance criteria provide the development team both with a deeper understanding of how to interpret the story and with a tool to understand when development is complete. Business and technical stakeholders provide the diversity of knowledge to develop relevant acceptance tests and criteria. When testing is a silo’ed task the development team will have to make assumptions that will need to be validated later in the process (later is never better than sooner when it comes to validation). Agile roles such as the product owner and techniques like the Three Amigos are tools to codify involvement.
  3. Participating in reviews, discussions, demonstrations and acceptance testing – I have written a few lines of code, managed a few projects and teams and tested a few projects in my career. In most of those cases a business facing product owner and/or user(s) where involved in validating and verifying the work as it progressed toward completion. I can’t count the number of defects or poor assumptions that were caught and fixed along the way. In those scenarios where real stakeholders did not participate in reviewing, refining and testing the product, the quality was generally lower. Colleagues over the years have expressed similar observations.

When you look in a cube and see a developer or tester reading a user story or use case while typing out a test or perhaps even executing a specific test, it might seem that testing is a solitary event. But you would probably be wrong. What you would have missed is the interaction between developers, testers, product owners that preceded those events, in which knowledge and perspectives were shared. You would have also missed the involvement of users, product owners, developers and stakeholders to review the results so that what gets delivered is not only technically correct, but also has business value. Without involvement, testing provides far less value than possible.

Advertisements