Quality Testing

Quality is delighting customers

Hi All,

Can any one give a detailed explanation on ERP domain Testing with the sample applications ? How we perform ERP domain Testing ?

Views: 5387

Reply to This

Replies to This Discussion

ERP is an acronym for Enterprise Resource Planning, which is a category of business systems forming the primary transaction processing across multiple business functions or business units. Typical functionality may include systems such as, accounting, human resources, customer order processing, purchasing, inventory management, manufacturing/operations, and order fulfillment. Although ERP systems are an outgrowth of MRP and MRP II systems in the manufacturing sector, the term ERP is applied to cross-functional transactional systems in many other industries today.
The largest vendors of ERP systems today include SAP AG and Oracle, Infor (Infor ERP LN is the flag ship ERP Product - Ln is the latest version of Baan ERP)

ERP Testing is a procedure that usually occurs before a company fully implements an ERP software package and the software goes live. It is done in order to identify certain situations may arise after the implementation has been completed, such as determining operational responsiblies, training needs, and problem management procedures.

Testing (or Unit Testing) as we refer to it, is a very important part of development and delivering a solution to a client. First off, you need to develop a test script so that a full end to end test can be performed and ensure that the results you get are the results you expect.

In order to do this you need to have specific business specialist that can give you the business scenario. Then the business scenario can be converted to business steps. I suggest that you firstly create a process flow to diagram what you believe the process is. Remember, that this process is subject to change during the development of the test script and unit testing.

Once you have the process flow documented, you can then do a system walk through to see if the existing software will do what the process calls for. If not, then development will be needed to meets the business needs.

Once development is completed, the true unit testing occurs. You must do integrated testing on all possible scenarios that may come out of the business process (different variations of the same process)

Once unit testing is approved, then the solution can be delivered to the client. After this is done, the client should be given the details of the test plan so that they can also do scenario testing to get an agreement on the solution.

Most ERP software products like SAP, PeopleSoft, Oracle, Baan, etc., are really old file based architectures mapped to RDBMS tables with integrity and domain checks based in software application layer and not in the RDBMS. This causes many programming errors and that causes software patches. Most ERP software was designed a generation ago and does not use logical constructs like a relational design and most RDBMS constraints, instead, ERP companies rely on programmers to never make a mistake. Hundreds of thousands of hours went into these systems, to not lose this investment the same old design is carried forward perpetuating a difficult system.

This is a modest proposal to test integrity and domain using RDBMS constraints and a plea that the ERP companies could actually supply these tests to the customer. This does not fix the problem of ERP software integrity but could be a useful tool. The root of the problem is still the poor mapping of the file based architecture to the RDBMS systems and relying on programmers to write checks constraints, domain constraints and relations in the application software layer.

The ERP Testing Problem Is Difficult To Solve.

The ERP systems such as SAP, PeopleSoft, Oracle, Baan, etc., have horrible track records as "patch ware", or software that has many patches that are applied each week. The patches repeatedly break other things in domains and integrity and the administration of these products is a continuous round of patching, testing, patching, testing, patching, ..., and maybe some deployment.

The customer administration of this mess is very difficult and usually many patch levels are in testing environments waiting to be installed in the production environment. The software does not usually come with any tests to help the customer deploy this patch ware on the data set the customer uses. Instead the customer usually develops a suite of tests by trial and mostly error on the dataset created when the customer has deployed the system with all its customizations.

How Would Constraint Testing Work?

Domain constraints to check value domains and referential constraints to check the data in one table that is related to other tables would be a valuable tool for the customer. The ERP company could supply the customer with a set of database constraints that would act as test assertions. The customer could then patch the weak, cruddy ERP application code in a test environment with a copy of production data and apply the database constraints to help verify the patch works. For example, a referential constraint to check that order numbers in the "order shipped" table exist in the "order entered" table is an easy to write constraint that might help ERP customers. A domain constraint could use date range check constraints to check that calendar quarter data is in the quarter date range. Other domain constraints can check subsets of values across other domains and many types of data verification can be quickly and easily done.

The constraint testing may have to occur at stable states during a transaction as many ERP modules will violate referential constraints during a transaction. Even with this problem the testing would be useful and many domain constraints would not have a problem.

RDBMS constraints cannot test all problems, of course. And because the mapping of the file based architecture to the RDBMS is poor, it may not be able to test some data and a lot of patch testing would not be covered. But constraint testing is at least a start and an easily implemented one that needs no special software or training but uses the existing RDBMS and SQL tools that any customer installation already owns and has the expertise to run.

Why Have Constraints Not Been Used In Popular ERP Software?

A friend questioned why there is so little use of constraints in most ERP software, even when they have been widely available for more than 10 years in RDBMS products. One reason may be secrecy, a well defined data model would expose the ERP rules and programming to analysis, it is now a black box bought for a lot of money. More probably the design and architecture of the ERPs are so hacked that constraints cannot be easily added without a total redesign. Redesign of current modules using better relational design would not sell new licenses, it is the latest acronym of the month that sells, like "web enabled CRM!" As a result the ERP companies just add another layer to the house of cards built on a shaky data model.

Once an ERP company has a customer and the ERP system is in production it is difficult to change to another system, the customer is a captive. Maintenance and testing is usually an afterthought to most companies, the level of experience in software engineering of a company buying and implementing an ERP product is far less than a company making software, it is one of the hidden costs of operation and risk that is commonly overlooked by a company implementing an ERP. Another problem is that the ERP companies appear to do little testing of any kind in their own programming shops. I think that like Microsoft, it is new "features", not quality, that drives ERP development. Customers really buy beta releases and the circle of hell begins, test, patch, test, patch, ....
Hi Pooja,

Thanks for sharing it.

-Sameera
Hey Sameera,
Very good concept you introduced here... Thank you.. Here are my some more little bi information on the ERP Testing:

ERP Testing is a procedure that usually occurs before a company fully implements an ERP software package and the software goes live. It is done in order to identify certain situations may arise after the implementation has been completed, such as determining operational responsiblies, training needs, and problem management procedures.

Testing (or Unit Testing) as we refer to it, is a very important part of development and delivering a solution to a client. First off, you need to develop a test script so that a full end to end test can be performed and ensure that the results you get are the results you expect.

In order to do this you need to have specific business specialist that can give you the business scenario. Then the business scenario can be converted to business steps. I suggest that you firstly create a process flow to diagram what you believe the process is. Remember, that this process is subject to change during the development of the test script and unit testing.

Once you have the process flow documented, you can then do a system walk through to see if the existing software will do what the process calls for. If not, then development will be needed to meets the business needs.

Once development is completed, the true unit testing occurs. You must do integrated testing on all possible scenarios that may come out of the business process (different variations of the same process)

Once unit testing is approved, then the solution can be delivered to the client. After this is done, the client should be given the details of the test plan so that they can also do scenario testing to get an agreement on the solution.
Hi all

Testing on ERP( Enterprise resource planing) applications are not easy when compared to others as ERP are the huge and complcated architectures. To test the ERP application the knowdledge of the ERP is mandatory. An erp product can be tested manually as well as Automated. Data Driven frame work can be used.
QTP , Performance testing can be done by using LOAD RUNNER


Can any one pls share me links regarding the Testing of ERP applications
Testing is never an easy job, cause it ensures customer satisfaction(which never ends).

Major ERPs have in-built Testing tool to address the concerns of ERP package testing.

Other popular tools which support ERP may exists but are not conventional, in the sense they don't under stand ERP better.

Thanks,
Siddiq
Hi All!
This not related to Domain Testing but i am sharing information.
ERP of SAP a GERMAN ( Deutschland) designed software is an important course.
If one does it and becomes handy at it, jobs knock at ones doors.
______ JAY _______
Hi !
This is different from ERP Domain Testing but displayingfor knowledge purpose.

" TESTING THE DOMAIN OF A FUNCTION "

The domain of a function consists of all the possibly input (normally x) values. There are three possible scenarios that result in values not being in the domain:

1. When the denominator (if there is one) is equal to 0.

2. When taking the square root of a negative number

3. When taking the log of a non-positive (negative or 0) number.

Testing these three cases will normally eliminate all value that aren't in the domain. For example, take the function

log(10–x) / (x+4)

Testing the three cases:

The denominator ((x+4) ) is 0 when x = -4. Therefore, -4 is not in the domain.

There is a square root, and the value inside the square root is negative when x < -4. Therefore, x < -4 is not in the domain.

There is a log, and the value is non-positive when x10. Therefore x10 is not in the domain.

So, looking at these three values means the domain is -4 < x < 10.

A good visual technique while eliminating values for the domain is to use a number line and cross out the values that do not work.

<––––––––––––––––––––––––|––––––––––––––––––––––––––>
0


< XXXXXXXXXXXXX|––––––––|––––––––––––––|XXXXXXXXX >
-4 0 10

_______ JAY ________

GOOD JOB

 

RSS

TTWT Magazine


Advertisement

Advertisement

Advertisement

Advertisement

© 2021   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service