Hi Ronel,
You have an interesting, but not uncommon, challenge.
The testers have a good point: even though what the customer needs is documented as a requirement, the requirements in such cases should define what is NOT a requirement and how the system is supposed to behave.
I'll get to that in a second, but first let me make my point with a silly illustration. Let's say that you're in the market for a sports car and you have requirements such as: must have 2 seats, needs to be low to the ground, needs to have tires wider than x inches, it should be red, etc.... You may even say it should be a Lamborghini. When you go to pick up the car, it has everything you asked for but it also has a 18-wheeler truck permanently attached to the back of the brand new car. I'm sure it wouldn't go well with you if the salesman simply said "You didn't tell me you don't want an 18-wheeler stuck to the back of the sports car."
The users (not testers) of your system will feel the same way when they begin using your system in the production environment and encounter "features" they did not expect. These could be more than just "noise" and could cause serious technical, operational, and security issues.
For example:
- What if your parts tracking system also has an accounting module which the users did not ask for. The users could begin creating invoices in this module instead of the in the company's centralized accounting system.
- What if your system has feature (not asked for) which allows customer data to be emailed to the email address you type in. Given the corporate standards, this could be a significant breach of agreement to safeguard customer data.
- What if this new system has ability to export data to MS Excel? If needed and used properly, this could be a great feature but if it gives a salesman the ability to export all the leads from the system before they quit their job (and go to the competitor) that feature is not a flaw. This feature could also put a high load on the system and decrease performance since data export processes could be resource intensive.
So, your testers have valid concerns even though they may not have articulated them from the end user's perspective or from the organizational perspective.
Here are some thoughts on how to deal with this:
- Create an inventory of all the features which were not requested.
- Identify those which of these feature could cause issues of various types: operational, performance, security, risk, etc.
- Find out if the system has the ability to disable undesired features via configuration, entitlements, or security settings.
- If such features do not exist, request that they be added by clearly outlining the risks to the organization of not doing so.
- Work with the end users, operations group, or trainers to document (by policy) what the users should do when they encounter a feature not needed. These could become assumptions in your requirements doc that the testers can use. Example: "It is assumed and confirmed by the business that feature <x> will not be used."
You get the idea! Hope this helps!
Adrian