For an average professional software tester, testing is a merely rational concept.
The tester discusses the test scope, creates a test plan, defines an approach, defines the test levels, entry and exit criteria. Then they install the tools, define working instructions, test the analysis, the code, the procedures and maybe even te project members. They register bugs, shout about risks ad issues that get solved or not after which they retest, retest and retest after which they finally advise about moving to acceptance testing or go-live, and (maybe after a couple of times going trough this procedure) start the hand over to the standing organisation to start testing for another project. For a tester, most of the time, there is no life beyond the project. No fear for production issues and how they will impact maybe thousands of people after the final Go-Live is given.
For an acceptant, testing is a totally different matter. the acceptance testers are generally a representative set of constructive people that KNOW the organisation, operate or lead operations and therefore have a good influence on their business colleagues. They will have the last say about going live or not. (even when they are not formally asked - they can create a lot of commotion if their buy-in is not obtained by the time of go-live)
It's the business users that will face the issues coming from poor design, architecture, forgotten parts from analysis and also from development and testing shortcomings.
They care less about those numbers in those professional and colourful defect reports. They don't look into most of your risk assessments and don't even care about your scope descriptions.
For them, the product needs to work on an acceptable level before go live and there is no number or colour that will convince them otherwise.
Therefore those acceptants are the managers biggest nightmare as they are out of his control but will decide about the added value of the project team's work.
It's those people that will have to work with the product for the next weeks/months/years until a possible update of the product will be made available. And that can take a while when you're not working in an agile structure.
So how can we create this buy-in that managers are so desperately looking for?
It's not all that hard. It all comes down to basic things. The project needs to be able to listen. They should not abandon all those "extra feature requirements" that are constantly coming in as defects at the end of the project. Instead the project should distill those extra features as soon as possible in the project, so that they can be estimated and built in time.
It is useless to build a program that fits incorrect or incomplete requirements. The goal is to get a good understanding of what we are building and why we are building it, making sure that we deliver value. To get to a good understanding, feedback loops are of the highest importance.
Is this what you wanted and is it working as you expected? Thats what we need to find out as soon as possible.
So how can we do that?
1. Agile product delivery
Running short sprints of software delivery, focussing on the most important parts of the most important features, is one of the best ways I know to get early feedback from your stakeholders. They get involved in setting up priorities and backlog creation and can be involved in testing very early on. They need to be coached in testing though as they might expect more then they will receive in the first deliveries and are looking for the wrong defects.
If agile product delivery is not an option for you, there are still other ways to get a good and in time understanding of what your business actually really wants.
2. Dry-run
Testing for business is not only about the software, but about doing their jobs with this software.
A dry-run can be seen as a role-playing game where all business that is involved in accepting the product makes a simulation of their day to day operational work with the new software package.
This can already be done based on analysis material as for example wire frames or a prototype.
Every part that is analysed and prototyped or wire-framed, can pass a dry-run session - which can eventually lead to proper documentation of the business processes and analysis and re-used in all later testing.
3. Prototyping
Before building the actual product, it might be a good idea to build a complete prototype. Prototypes can help people understand what the development team understood they need to build.
Prototypes can be run trough from different angles
- Does this prototype support the business process?
- Do we capture all possible errors that can occur?
- Does the screen layout and setup make sense?
- Will the software be able to support the amount of users we estimate to have?
- etc...
They can be evaluated individually by the stakeholders and testers and/or used in a dry-run session.
4. Demo's
As soon as you have a feature ready that can be shown, the developers take the initiative to give a demo. A demo is a forum to receive constructive feedback. The invitees should not be the managers high up in the chain but a representative set of users.
After the developer finished the demo, the stakeholders ask the developer to show other relevant scenario's of the same feature. The developer can find and solve defects and the project leader might receive a set of changes in features or new features.
Probably there are more ways to accomplish a good relation with your stakeholders, but I found the previous four very fruitful. Engaging your business early on in the project, making them part of the project delivery, is key to successful project delivery.
