Former Member

Regression testing
Dec 03, 2008 at 02:16 PM | 325 Views
Hi all
What is a regression testing
Thanks
Ritu

Roopa,
I believe, you are not trying to use the search forum option over here... you
should try this search forum option before posting such generic questions...
Neverthless, have a look at below points:
Unit Testing
When you test every single document is called unit testing.
String Testing
One transaction full activity is called string testing . For example Vendor
invoice, goods received and vendor payment.
Integration Testing
It is purely with other modules and we have to check whether the FI testing is
working with other related modules or not.
Regression Testing
Testing for whole database. Bring all the data into another server and do
the testing is called regression.
UAT
When we test any particular document with the user and if it is ok immediately
we have to take the signature on the document, which is signed off and can be
forwarded to the immediate boss. There are some steps to be followed when
we go for user acceptance testing.
Transaction u2013 Script Writing u2013 Expected Results u2013 Compare with
Actual Results
TPR (Transaction Problem Reporting)
While doing the user acceptance testing if we get any problems then there are
some methodologies to be followed according to the companyu2019s policy
and normally as a tester we always need to write on Test Script itself.
Hrishi

o Share

Former Member
 Dec 03, 2008 at 02:23 PM

Hi there,
Regression test is done to ensure that existing functionalities / processes are
not effected by the configs / developments that you made.
For eg after you have finished your configs / developments in all domains of
yourproject SD, FI, MM etc, you will test to see that already existing processes
arenot effected by your code. If you developed a customized logic that for new
sales org 2000, delivery split is basing on warehouse num. It should not effect
any other sales org. Then you will test to see if there is a delivery split in
existing sales org 1000 basing on warehouse num.
Regards,
Sivanand
Ritu,
below are some testings-
Testing: the core team members along with endusers will test whether the
postings done in SAP is resulting as per the requirements of the organisation.
They will test whether the output documents such as purchase order, invoice
document are printed in the required format and showing the correct data.
Unit testing is refer to the module which are going to implement. SD, MM, FICO
etc. there will be test script based on that testing will be performed.
Integration testing will be cross the modules. MM-SD-FICO for example.
Integration testing is also called SIT ( System integration testing)
Testing mathologies and types: there are 6 types of testings:
1. Unit Testing
2. System Testing
3. System Integration security Testing
4. Performance Testing
5. User Acceptance testing
6. Regression Testing
Unit testing is done in bit and pieces. Like e.g. in SD standard order cycle; we
do have 1-create order, then 2-delivery, then 3-transfer order, then 4-PGI and
then 5-Invoice. So we will be testing 1,2,3,4 and 5 seperately alone one by one
using test cases and test data. We will not be looking and checking/testing any
integration between order and delivery; delivery and TO; TO and PGI and then
invoice.
Whrereas System testing you will be testing the full cycle with it's integration,
and you will be testing using test cases which give a full cyclic test from order to
invoice.
Security testing you will be testing different roles and functionalities and will
check and signoff.
Performance testing is refered to as how much time / second will take to
perform some actions, like e.g. PGI. If BPP defination says 5 seconds for PGI
then it should be 5 and not 6 second. Usually it is done using software.
Regression testing is reffered to a test which verfies that some new
configuration does not adversly impact existing functionality. This will be done
on each phase of testing.
User Acceptance Testing: Refers to Customer testing. The UAT will be
performed through the execution of predefined business scenarios, which
combine various business processes. The user test model is comprised of a
sub-set of system integration test cases.
We use different software during testing. Most commonly use are
Test Director: which is used to record requirement, preparing test plan and then
recording the progress. We will be incorporating defects that are coming during
these testings using different test cases.
Mercury Load Runner: is used for performance testing. This is an automatic
tool.
What does the following terms means :
- Technical Unit Testing
- Functional Unit Testing
- IntegrationTesting
- Volume Testing
- Parallel Testing?
Technical Unit Testing= Test of some technical development such as a user
exit, custom program, or interface. the test usually consists of a test data set
that is processed according to the new program. A successful test only proves
the developed code works and that it performed the process as as designed.
Functional Unit Testing= Test of configuration, system settings or a custom
development (it may follow the technical unit testing) These usually use actual
data or data that is masked but essentially the same as a real data set. A
successful test shows that the development or configuration works as designed
and the data is accurate as a result.
IntegrationTesting= Testing a process, development or configuration within the
context of any other functions that the process, development or functionality will
touch or integrate . The test should examine all data involved across all
modules and any data indirectly affected. A successful test indicates that the
processes work as designed and integrate with other functions without causing
any problems in any integrated areas.
Volume Testing= testing a full data set that is either actual or masked to insure
that the entire volume does cause system problems such as network
transmission problems, system resources issues, or any systemic problem, A
successful test indicates that the processes will not slow or crash the system
due to a full data set being utilized.
Parallel Testing= Testing the new system or processes with a complete data
set while running the same processes in the legacy system. A successful test
will show identical results when both the legacy system and new system results
are compared.
I would also note that when a new implementation is being done you will want
to conduct at least one cut over test from the old system to the new and you
should probably do several.
What kind of testings that are carried out in testing server?
1. Individual Testing ( Individually which we've created)
 2. Regressive Testing ( Entire Process)
3. Integration Testing ( Along with other integrated modules)
The 3 types of testing is as follows:-
1. Unit testing (where an individual process relevant to a SD or MM etc is
tested)
2. Integration testing (where a process is tested that cuts across all areas of
SAP).
3. Stress testing (where lots of transactions are run to see if the system can
handle the data)
Regds
MM

Former M emb er

Jul y 29, 2013 7 minute r ead

Types of Testing Terminologies – ASAP

FollowRSS feedLike
15 Li kes 19,201 Views 3 Comments

SAP Unit Testing

This tests isolated pieces of functionality, for example, creation and save of a sales order. The
test is done in the development by a configuration specialist and confirms that the sales order
can be saved using the SAP organization elements (sales organization, company code, credit
control area, etc.) along with the customer master data set up, partner functions, material master
data, etc. It establishes a baseline of SAP functionality.

For ABAP development, for example, unit testing shows that a report can be created from
developer generated data. Assistance in data generation may come from a functional
consultant.

SAP System Testing

This is testing where elements of related SAP functionality are linked together in the
development environment to ensure the pieces work together. For example, a quote-to-cash
flow would show that a quote can be used to create a sales order, a delivery can be created and
processed from the order, the delivery can be billed, the billing released to accounting, and a
customer payment applied against the accounting invoice. Each of the component parts is unit
tested ahead of time and the data used in testing is usually fabricated based on the knowledge of
the project team.

SAP Scenario / String Testing

this tests specific business cases. For example, there may be configuration and business
process design that is unique to a certain customer set or a given product line or a set of
services. Tangible products and services are processed very differently from each other, so you
might have different scenarios you need to test. Again this testing is usually done in the
development environment to prove out a requirement – an argument can be made to say this is a
test case you would cover in system testing. Scenario testing can also happen in the QA
environment, but I prefer to call that string testing.
This testing also includes execution of interfaces and other development objects, e.g. reports,
with fabricated data.

SAP Integration Testing

This testing is similar to scenario testing except it is typically done in the QA environment and
uses more realistic data. Ideally the data has come from a near real data extraction, conversion
and load exercise (not necessarily a full conversion) so the data has a certain familiarity to it for a
business end user, e.g. recognizable customers, materials, pricing, vendors, contracts, etc. The
testing shows that the business process as designed and configured in SAP runs using
representative real world data. In addition the testing shows interface triggers, reports, workflow
are working.

SAP Interface Testing

Testing of interfaces typically occurs at different points in a project so it is important to know what
you are testing when. During the project development phase isolated interface testing usually
refers to unit testing activities where you confirm that your code can consume a file of your own
making. You might have two development systems – one SAP, one non-SAP – where you run a
test to show that the sender can generate a file and the receiver can consume it. In the QA
environment interface testing might involve execution of business transactions on the sending
system followed by looking for automatic generation of the interface output; this is then followed
by the receiving system consuming that file and proving that a business process continues on the
receiver. Your interface testing might prove that the whole process runs automatically with
business events triggering the outbound interface correctly, automatic transfer and consumption
by the receiver.

This testing and its definition can become even trickier if you use a message bus where the idea
of point-to-point interfaces doesn’t apply and you need to consider publish-and-subscribe
models.

Whatever you are doing under the guise of interface testing, you need to be clear about the
scope of the tests and the success criteria. Typically interface testing becomes part of larger
testing activities as a project progresses. In my experiences interface testing shows that the
triggering works, the data selection (and exclusion) is accurate and complete, data transfer is
successful, and the receiver is able to consume the sent data. Wrapped around this is showing
that all the steps run automatically and that error handling and restart capability (e.g. data
problems, connectivity failures) is in place.

SAP End-to-End Testing

This is similar to scenario testing in that a specific business case is tested from start to finish and
includes running of interfaces, reports, manual inputs, workflow, etc. In short it is attempting to
simulate a real world business process and, in order to make it as real as possible, it is done
using the most realistic data. Ideally the data used was the result of a data extract, conversion
and load process. I would expect this kind of testing to occur in a QA environment: at some level
it can be seen as a way of validating that the individual unit tests, scenario tests, integration tests
and interface tests produced results that work together.

SAP End User Testing & User Acceptance Testing

I grouped these two together because they are closely related, if not identical. The goal here is
to ensure that end users are able to perform their designated job functions with the new
system(s). A crucial part of this testing is referring back to the business requirements (you have
some of those, right?) and blueprint to ensure that the expected features, functions and
capabilities are available. As part of the project user involvement along the way should have
been providing feedback to ensure the design met the requirements, so there should not be any
big surprises.

Again this is activity that usually occurs in a QA environment with realistic data and the inclusion
of end user security and authorizations.

SAP Stress / Load / Performance Testing

This kind of testing examines things like whether the system response time is acceptable,
whether periodic processes run quickly enough, whether the expected concurrent user load can
be supported. It also identifies processing bottlenecks and ABAP coding inefficiencies. It is rare
for a project to have worked out all the system performance tuning perfectly ahead and to have
every program running optimized code. Consequently the first stress test on a system can be
painful as lots of little things pop up that weren’t necessarily an issue in isolated testing.

The testing is geared towards simulating peak loads of activity, either online users or periodic
batch processing, and identifies the steps needed to improve performance. Given that the initial
test reveals lots of areas for improvement you should expect to run through this a couple of times
to ensure the results are good.

SAP Usability Testing

This testing is usually concerned with how many key strokes and mouse clicks it takes to perform
a function; how easy and intuitive it is to navigate around the system and find whatever it is that
you are looking for. In an SAP implementation using the standard GUI there isn’t much scope for
this kind of testing: end user training shows how to navigate, how to create short cuts and
favorites, modify screen layouts, etc. On the other hand a project that involves building portals
may well need to perform this kind of testing, not just for reasons mentioned earlier, but also for
consistency of look and feel.

SAP Security and Authorizations Testing

Ensuring that users are only ableto execute transactions and access appropriate data is critical
to any project, especially with today’s needs for SOX compliance. This testing is typically done in
a QA environment against near-final configuration and data from a full extract, conversion and
load exercise. Test IDs for job roles are created and used to both confirm what a user can do
and what a user cannot do. More often than not this kind of testing is combined with end user or
user acceptance testing.

SAP Cut Over / Dry Run Testing

This kind of testing is simulating and practicing certain major one-time events in the project
lifecycle. Typically the terms “dry run” and “conversion” together to mean a full scale execution
of the all tasks involved to extract data from legacy systems, perform any kind of data
conversion, load the results into SAP (and any other systems) and fully validate the results,
including a user sign-off. Most projects have several dry run conversions which progress from an
exercise in capturing all the steps, checkpoints and sign-offs in data conversion to a timed
exercise to ensure everything can be accomplished in the time window for go-live. Once it
becomes a timed event a dry run data conversion readily rolls into a cut over test, where it is one
component of an overall cut over activity sequence: a cut over test usually ensures that all the
necessary tasks, e.g. importing transports; manual configuration; extracting, converting and
 loading data; unlocking user IDs; starting up periodic processing for interfaces, etc. are all
identified and can be executed in the go-live time window.

Application Testing

This term can be construed as so broad it has no meaning as an “application” can mean a lot of
things. I have only ever heard it as generic blanket term for another kind of testing, e.g. SAP
application testing, so it needs to be refined and given context to be of use.

SAP Day-In-The-Life (DITL) Testing

This is one of my favorite kinds of testing – it really is what is says it is. Run the system the way
you expect it to be run during a regular business day. Real users, real data, real volumes, real
authorizations, real interface and periodic job execution – the closest you can get to a production
environment before you go-live with the system.

Not every day in business is the same so you might want to run a few DITL tests. However
these can be difficult to organize because of the need to have end users trained and available for
extended periods of time as well as having all partner systems able to participate in the activities
with real and synchronized data across the systems, real users, real data volumes, etc.

SAP Regression Testing

Each time you put a new release of code and configuration into your production system you want
to be sure you don’t cause any changes in any processing beyond what you expect to
change. Hence the role of regression testing: test your existing functionality to be confident it still
works as expected with the newly updated configuration and code base. Clearly you don’t want
to find you have issues in production after you make the changes, consequently regression
testing in a QA environment that has similar data to production is a good test bed. In some
cases automated testing can be effectively deployed as a fast and regular method to ensure core
business processes are not adversely affected by new releases of code and configuration

Types of testing in SAP?

May 01, 2009 at 08:57 AM | 900 Views
Dear Gurus,
Pls explain Types of testing in SAP in detail?
Thanks..

MM (Materials Management)

 Follow
 RSS Feed

Related questions
Standard Material types in SAP
By Satheesh Kumar N, Oct 15, 2018
Types of STO(Stock Transfer Order)
By amol gite, Apr 07, 2019
3 Answers
Sort by:
 Votes
 |
 Newest
|
 Oldest

 Best Answer

Govardhan Vadlapatla

May 01, 2009 at 09:14 AM

Hi
Testing phases will be depends on type of projects, however some common
phases of testing are same for all the projects.
1. Unit testing -- During development developer will do this testing
2. Assembly Testing (AT) -- Once the development is over, based on FS
functionals will prepare the
test scenarios then they will prepare the test scripts, once those scripts got
approved by the business they will execute the test scripts.
3 a. Product Testing: In this phase of testing total end to end testing of objecets
(Newdevelopments) by including the other systems (eg. with FI, PM ,SD
etc......).
b. Integration testing: Incase of project is related to Integaration with legecy,
then testing
will be end to end from sap to legecy.
4. User Acceptance Testing UAT: During UAT, business will prepare their own
test scripts and will do the end to end testing, this will be the last phase of
testing before go-live.
5. Regression testing: For example, If the project is rolleout , i.e. adding new
business unit or company code to the existing system with the new
developments, they before putting the new developments into the existing
system testing should be carried out in quality environment, to test the effect of
new code for the existing functionality.
Thanks & Regards,
Krish

o Share

2 Comments

o Govardhan Vadlapatla Former Member

May 01, 2009 at 09:25 AM
Hi
Yes we will do the Unit testing in devlopment box during realization phase.
 Depending upon availability of environment some times we will do the Assemply
testing (AT) also in development box.
But the *Proudct / Integration (PT)* testing & UAT will be carriedout during final preparation
in Quality environment.
Thanks & Regards,
Govardhan

 Like 0
 Share

Show all

Pardeep Malik

May 01, 2009 at 09:06 AM

1. Unit Testing :- check functioning of individual module.

2. Integration Testing :- Cross Module Flow for e.g. impact of MM on FI
Technical Unit Testing= Test of some technical development such as a user
exit, custom program, or interface. the test usually consists of a test data set
that is processed according to the new program. A successful test only proves
the developed code works and that it performed the process as as designed.
Functional Unit Testing= Test of configuration, system settings or a custom
development (it may follow the technical unit testing) These usually use actual
data or data that is masked but essentially the same as a real data set. A
successful test shows that the development or configuration works as designed
and the data is accurate as a result.
IntegrationTesting= Testing a process, development or configuration within the
context of any other functions that the process, development or functionality will
touch or integrate . The test should examine all data involved across all
modules and any data indirectly affected. A successful test indicates that the
processes work as designed and integrate with other functions without causing
any problems in any integrated areas.
Testing :
the core team members along with endusers will test whether the postings
done in SAP is resulting as per the requirements of the organisation. They will
test whether the output documents such as purchase order, invoice document
are printed in the required format and showing the correct data.
Unit testing is refer to the module which are going to implement. SD, MM, FICO
etc. there will be test script based on that testing will be performed.
Integration testing will be cross the modules. MM-SD-FICO for example.
Integration testing is also called SIT ( System integration testing)
Testing mathologies and types: there are 6 types of testings:
1. Unit Testing
2. System Testing
3. System Integration security Testing
4. Performance Testing
5. User Acceptance testing
6. Regression Testing
Unit testing is done in bit and pieces. Like e.g. in SD standard order cycle; we
do have 1-create order, then 2-delivery, then 3-transfer order, then 4-PGI and
then 5-Invoice. So we will be testing 1,2,3,4 and 5 seperately alone one by one
using test cases and test data. We will not be looking and checking/testing any
integration between order and delivery; delivery and TO; TO and PGI and then
invoice.
Whrereas System testing you will be testing the full cycle with it's integration,
and you will be testing using test cases which give a full cyclic test from order to
invoice.
Security testing you will be testing different roles and functionalities and will
check and signoff.
Performance testing is refered to as how much time / second will take to
perform some actions, like e.g. PGI. If BPP defination says 5 seconds for PGI
then it should be 5 and not 6 second. Usually it is done using software.
Regression testing is reffered to a test which verfies that some new
configuration doesnot adversly impact existing functionality. This will be done
on each phase of testing.
User Acceptance Testing: Refers to Customer testing. The UAT will be
performed through the execution of predefined business scenarios, which
combine various business processes. The user test model is comprised of a
sub-set of system integration test cases.
We use different software during testing. Most commonly use are
Test Director: which is used to record requirement, preparing test plan and then
recording the progress. We will be incorporating defects that are coming during
these testings using different test cases.
Mercury Load Runner: is used for performance testing. This is an automatic
tool.