What if the application has functionality that wasn't in the requirements?

Question

It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it would indicate deeper problems in the software development process.

If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.

If not removed, design information will be needed to determine added testing needs or regression testing needs; and this affects productivity, wasting of time of QA team if needed in functional/regression testing. Can Management team be aware and take any added significant risks as a result of this unexpected functionality.

How much will it cost on QA, management and overall productivity of an application?

Answer 1

Undocumented features are BUGS

It doesn't matter whether the undocumented functionality appears harmful or not, it is still a bug for the following reasons:

• Because the functionality isn't documented, there is no traceability.
• Lack of documentation means that harmful consequences are much less likely to be found (if testers don't know it's there, they can't test it).
• Customers who find the functionality and use it may then be unhappy when a future release removes it (I've had to deal with this: it isn't fun).
• Undocumented functionality complicates bug investigation. I've seen cases where a bug only showed up if a customer was using an undocumented configuration setting. Nobody knew which customer was using the setting so it took much longer to track down and reproduce their problems as a result.
• Undocumented functionality creates hidden features that hide from change logs. This makes it much harder to evaluate what has changed between releases.

If you find undocumented functionality in my opinion your company has two choices:

• Document the functionality and treat it as a real feature.
• Treat the functionality as a bug and remove it

Answer 2

In my personal opinion, one classic example of unexpected functionality is Easter eggs.

Easters eggs introduce unexpected functionalities ranging from printing developers name to the standard output to leaving a backdoor only known to a few developers.

As a general rule, an unexpected functionality is introduced by either a coincidental mistake or hidden (even malicious) intention. Very occasionally, Easter Eggs are introduced on purpose.

How much it will cost on QA, management and overall productivity of an application?

• What is "it"? Did you mean unexpected functionalities or the testing effort to look for unexpected functionalities?
• It = unexpected functionalities, it is hard to measure how much it will cost on QA, management and overall productivity in terms of reputation, public confidence and etc. If an Easter egg is not malicious, some people may even find it funny and harmless. But if a hidden functionality is malicious in nature, it is basically a timed bomb.
• It = the testing effort to look for unexpected functionalities, one of the most effective ways to locate hidden functionalities is via exploratory testing. It comes down to estimate how much potential loss hidden functionalities can cause and how much effort you want to spend as well as how critical your software application is. As it is exploratory testing based, you need to take into account how experienced the testers are, the more experienced they are, the more effective an exploratory testing will be.

From my personal experience:

• Almost all hidden functionalities I have encountered so far are not malicious in nature; they were introduced by mistakes.

Answer 3

How to handle it?

First of all, I am assuming that the requirements have not been documented for this functionality. So, proper requirement analysis+ impact analysis (on intended functionality) should be done before testing team can estimate for this hidden/undesired functionality under question:

Now if the organization decides to go ahead with it then such functionality should go through the following steps:

A) Team should analyse the requirements to define the Scope of testing. So, that the testing team can have a clear distinction between a desired feature and a bug. Follow following steps:

1.Document all the requirements

2.Proper impact analysis of this functionality on the existing application should be done and the impacted areas should be carefully identified. Document the impacted areas too.

3.Clarify any open question/queries related to the functionality with the customer. Maintain a query log.

4.Finally, take sign-off from customer on requirements.

B) Testing, like every functionality, will have to be planned and performed for this new functionality. And now, as the testing team understands the scope of testing (defined in step (A)), they can plan better for the testing activities. Testing team should also plan testing activities for impacted areas identified in Step(A).

Test plan to be updated to incorporate the new functionality.

There may be new risks, dependencies, any specific third party tools etc. that might be required to test this functionality. You might have to revisit the acceptance criteria too.*

Planning and execution of manual testing of this functionality. Regression testing of impacted areas to be planned and executed. If, automated test scripts already exist for the application then regression won't be a costly affair.

Note: Management need to have some developers on stand by to fix issues are reported during the testing of this new functionality and in the regression testing of impacted areas.

Question: How much it will cost on QA, management and overall productivity of an application?

The unexpected functionality should be considered as a small testing project and should be estimated accordingly + cost of regression testing.

So, QA will have to spend effort on Step (A) and Step (B) activities listed above.

As far as productivity is concerned, I firmly believe that all this is being done in order to ensure that there is minimum impact on the productivity of application. And if well planned and executed, the impact on productivity would be minimum.

As far as the cost on Management is concerned, I am not sure about it. Because management decisions have different grounds. I mean if they have already made a good profit from the project they might not mind spending on this functionality as a goodwill gesture to the customer. Or, if the customer is giving too much business, then the management still might have to go for it in order to retain the customer. So, there are different factors that affect the management decisions.