Blog post series about testing development projects, part 7/11
Articles about planning software testing and managing it.
Point of views:
- Business critical development projects, where IT plays a strong role.
- One or more outside vendors.
- Client’s business personnel as testers. They are business professionals, not software testing professionals.
- Goals for testing:
- Make sure that the implemented solution supports the needs of the business.
- Make sure the implementation doesn’t endanger the business.
Are the development benefits being realized?
Some clients have described the ERP production environment as a graveyard for development ideas. What they mean, is that some development ideas are being executed, but the benefits are never being realized for the business. Couple of common reasons, why that is:
- Development idea is executed, even though there’s no real business case behind it
- Definition of the change fails
- The original need for the change gets lost during development
- End result differs from the definition – the error is not detected during testing
Process of ongoing developments
Here is an example of the process we develop ProjectTOP with. Everyone, of course, has their own processes.
Here are a few things that are important to us:
- Fast benefits from our investments: Always develop in bite-sized pieces to realize benefits quickly.
- Real time reporting: We know always how every single development is progressing and what are the developer workloads.
- Complete audit trail: We can see the full history of each development. Who asked for what, when, the definitions and how the development went. Tester can always use the history to see if the completion matches the original development idea.
- Personal task lists: Everyone is working on more than one project at a time so a task list with all activities is a must.
- Constant evaluation of the development process. Even though we are pretty good at it, we can do it a little bit better.
1. A development is undertaken without a true business case
All developments must align with business strategy. To ensure this, a development idea needs to analysed before the decision to do it. To make sure the investment produces something of value to the company and its strategy.
A real business case also prevents personal feelings affecting the decision. “I was having lunch with the director and he happened to suggest that maybe we should…”
If the person suggesting the development won’t fill the business case form, then it’s probably not worth doing. “Little things” tend to add up and become bigger than originally intended.
Development should still be agile. The business case shouldn’t be too bureaucratic. There are different levels of development. The truly small, but impactful developments need to be undertaken and not lost in red tape.
Problems of doing irrelevant developments:
- Strategy-aligned developments are slower if resources are used on wrong things
- Changes that do not align with the strategy can be harmful and shatter the architecture
- The investments do not bring the desired benefits
2. Definition of the development fails
In the worst case the development is specified in two Excel cells and some email conversations. If the developer doesn’t receive a clear definition, it’s always going to be nothing but his best guess. This is a real human error. Someone has a great idea, but it’s hard to put it in so many words. Or the idea is so clear to one he thinks the other person understands it in the exact same way. One always needs to improve on specification. To ask question and to contest. It can and should be done in a friendly atmosphere for there to be real progress.
3. The original idea of the development is lost during development
If you are working with scattered documentation like Excel sheets, email threads and documents who knows where, decision making is often not an integrated part of the development process, but separate from it.
During the development process the idea is refined, changed. Things are added or removed. If the chain of communication is not all in one place, the original idea, the need for the change can be lost in the process. A solution is developed that does not support business.
When making a decision to develop something, one should have the history of the development on hand. The original idea, the business case, the conversations etc.
This is the way to ensure the development we are about to green light will truly benefit the business and is aligned with our strategy.
4. End result differs from the definition – the error is not detected during testing
If the tester does not have the original definition including all conversations and relevant history, he can only test it from a technical point of view. I have often been in a situation where all that’s left of the development’s documentations is the name. The client and consultant have discussed things at length, but there are no documents left. in this case you have two options:
- Hope that you grasp the full meaning behind the development from just the name -> risk that the development does not support business.
- Start trying to make sense of things -> Time may be wasted in trying to figure it out.
Since everyone has their plates full, often the first choice is taken. If there is a complex change hiding behind the simple name, you run the risk of it not doing what it is supposed to, which is support the business. One tip that I have is to make a user manual / version announcement during testing. This can help communicate with the business whether or not the changes have been successful.
The hectic pace of today presents us with a big problem: Everyone does their part with minimum effort and maximum speed. Doing this as a part of a process chain ends up with less than optimal results. Doing development systematically with the right tools is way more efficient and the end result will always be better.
