Business involvement in testing

Publish date:

In an assignment as a test manager it could be that you are responsible for executing the business acceptance testing (BAT). Thus, you need to align the goals and expectations with business. But why involve the business at the end only for validation? In most projects the end-users are part of the requirements gathering phase […]

In an assignment as a test manager it could be that you are responsible for executing the business acceptance testing (BAT). Thus, you need to align the goals and expectations with business.
But why involve the business at the end only for validation? In most projects the end-users are part of the requirements gathering phase but then during the rest of project phases they are not involved.

What if the business was an essential part of the most activities in a project and not only during the acceptance of functionality delivered?
If you are working in sprints the business could be involved in the:

  1. Requirements gathering phase through their business knowledge and demands from business.
  2. static verification (i.e. static testing) of IT requirements. Each of requirement is assigned to one person from business and an acceptance criteria is written
  3. exploratory testing of requirements developed in the sprint
  4. formal testing which is documented when tests are combined to form a flow. This will be the formal acceptance of the requirements which then are ready for production

The aim is to find faults as early as possible. Tasks performed by business shall be as transparent as possible for the other project members. It is beneficial if business teams are located with the other project members, i.e. they are an integral part of the project delivery organization. Members of the test team are part of all the activities above and also during the system testing which is between point 2 and 3 above. It is required that these tests performed are all documented then at the end of a sprint for each test that a report is written.

The steps above can be seen as the 3 key principles we in Capgemini state in our PointZERO® vision.

Key principles_LR.jpg
  • Fit for purpose – must do what it must do. Quality cannot be tested at the end
  • Right the first time – Quality measures needed early
  • No faults forward – people are fallible – find mistakes early.

Implement Quality Gates between activities in the application lifecycle (see previous blog post about the PointZERO® vision part 3)
So, adding business presence in the 3 key principles above will help to confirm that you are on the right track before development starts. It will also keep business teams regularly informed about the progress as they are regularly included in the delivery project.

If you want to know more you can order the your copy of the book “The PointZERO vision” here or contact Rik Marselis or Dominique Muhlbauer via Expert Connect.

Related Posts

devops

Site reliability engineering

Genesis Robinson
Date icon August 7, 2020

Due to the current state of how we monitor, alert, and log our digital ecosystem, it takes...

testing

Building a culture of quality transformation

Deepika Mamnani
Date icon December 20, 2019

Transforming from traditional testing organizations to quality engineering organizations with...

data

Zombies, wizards, werewolves, and a test automation silver bullet

Grant Volker
Date icon November 21, 2019

Expectations of technology have dramatically changed over the years, creating a demand for...