ERP Seeded functionality testing
I'm posting this question with respect to ERP testing. As we all know a company may purchase an ERP to cater its limmited set of needs. So that doesn't mean all of the features available in an ERP will necessarily be used or required by the client/organization. In a given module there will be many seeded functionalities and fields.
- If user make sure to use only the requested features we may limit our testing scope to the requited one only.
- But there is no guarantee user would do that. there is a chance he/she may go and check some unrequested features and might find it helpful.
How would we cover them and respective additional features.
I'll limit my response to SAP only, because that's what I know. Other ERP systems may differ.
Functionality in SAP can be limited in a number of ways:
- The submodule/component is not activated
- The transactions used to run a process are not included in users' roles or authorisations
- Business process says "don't do that"
Most ERP implementations involve a system integrator, and follow quite formal design processes (blueprint). Due to a combination of project timeframes (scope creep) and SI contracts, most changes to the blueprint once it's been signed off require a change request. If accepted and built then this change in functionality will show up on your test scope, so there is usually no need to cover them until they are requested (and if config or development is required then there would be no point in testing it beforehand anyway).
Excellent Answer!! i cannot add anything else!!
Originally Posted by meridian_05
Many thanks Meridian,
I think I got your point. But to elaborate it further I will explain with an example. Any memberís idea would be appreciated.
Let say a requirement is given by the client requesting a page to enter purchased product details. BA finalized the discussion and document it saying user should be able to enter products in multiple lines and each line user should provide Supplier name and Quantity.
From the scratch developer could do a page only with the exact feature and necessary fields?
But if he uses an existing module there might be an additional feature like defaulting values from header. Basically user could define the Product, Vendor or Quantity at header and get them copied in to subsequent line items.
So unless that header level defaulting feature is communicated by BA as a requested feature, hope we may consider it as an out of the testing scope.
And we might not necessarily need to force the developer to disable it.
User may use it but proper functioning of it is not certified.
Attached the sampe UI
There's two ways to look at the functionality: either this is a feature that should explicitly have been removed and wasn't, or this is such a standard feature that the BA overlooked explicitly noting it and assumed that it was a given that this feature would exist.
The easiest way to resolve which one this is, is to ask the BA whether this feature is a requirement. Depending on the feature and any underlying requirements (config, user exits, master data, hidden fields, warning/error triggers, etc) this may set off a chain of discussions with other teams along the lines of "this wasn't in the original design documents therefore it's a change request".
If it's a feature that should have been removed but hasn't, then as a tester by all means raise the defect and advocate for your bug to be fixed (by, for example, identifying any potential issues if the users use it). How the project handles this will depend on a case-by-case basis, particularly how they view the cost/benefit of removing it. Some projects will go to great lengths to remove any unnecessary functionality, and some consider it easier to update the training documents and call it an invalid process.