sitemap
AllSapLinks.com   
Creating Unit Test Plan (UTP) for Abapers
1        Introduction
   
The Unit testing is the lowest level and the most important elements of testing. To ensure that all programs paths and
conditions are adequately tested. The expected results of each test are derived from the design specifications to ensure
that the program performs exactly as specified.   
   
   The execution and review of a test ensure the following:
   
·        Component design and configuration meets design specification
·        Individual system procedures are defined and conforms to specification
·        Define and validate all data sources
·        Test data element at a field level including exception tests at the unit level; test all possible errors
·        Error recovery procedure conforms to defined specifications.

A Unit Test Plan is developed for each program or procedure, which includes testing of input, output, and screen and
report s created by the program or procedure. All interface programs and custom-coded programs have Unit Test Plans
prepared also. Prior to execution, the plans are reviews and approved by the team leader. The Unit Test Plans define all
conditions and steps to be tested, required test data and expected results of each test.
2        Unit test plan (UTP) detailed definition - Field Usage

The following table lists all the fields that will be used on the Unit Test Plan (UTP) and explains how each field will be used.
The R/O column is used to indicate whether the field is required (‘R’), optional (‘O’), Defaulted (’Defaulted’ - indicating the
system assigns the value).  When a field on a form is required, but the information is not known at the time the form is
initially created, enter ‘TBD’ in the field until a more meaningful value can be entered.
Field name
 Req’d/ Opt
 Description
Test Condition
 R
 A phrase that briefly describes the
condition/functionality to be tested.  Test
Conditions should be numbered
sequentially.  The number should be
indicated with the description.  (i.e.:  1.
Validate Material Number Screen Field).  
A Test Condition should comprise one
unique test, not multiple tests that are
similar.  For example, a correct test
condition would include validating one
selection screen field, not validating all
the selection screen fields and then listing
them as steps of the condition.  Each Test
condition should appear in its own table
row.
Step #
 R
 The step number within the condition.  
Each condition will probably have several
steps.  Steps are the individual actions the
unit test controller must perform in order
to test the condition.  You can reference
previous condition(s) steps as required
(for instance, you've already opened the
transaction in the first test condition and
now you need to validate the Plant so
you'd indicate something like:  2.1  After
step 1.5, enter a valid Plant in the Plant
field and press return.  Steps within each
condition should also be numbered
sequentially and include the condition
number first.  (i.e., 1.1, 1.2, 1.3, 1.4, 2.1,
2.2, 2.3, 3.1, 4.1, 4.2, etc)
Step Description
 R
 The description of the action to be
performed for each step number.
Test Data
 R
 The actual data to be used for the test
step or, if data is not available, give a
business description of the data needed to
test the step (i.e., customer number =
40389).  Actual data used during final
test run should be recorded here if only a
business description was provided
initially (this can also be done by
referencing a screen shot of the selection
screen showing the inputs)
Expected Result
 R
 The output or action that should occur
according to the specification.  Expected
Results should describe the screen or
output appearance, indicating the fields,
lists, etc. with expected values, error
messages with message text, etc.  Also
indicate where to verify the data.  This
verification should be made via SAP
transactions (not just table) whenever
possible.  For example, for an output that
displays purchase order information could
refer the UTP controller to transaction
ME13 (Display Purchase Order).
Actual Result
 R
 What actually happens.  By the time
you're done testing and fixing this should
match your expected result.  If actual
result matches expected result, enter 'As
Expected' in this column.  If you're really
spiffy, you'll indicate the page number
your screen shot(s) for the test occur on
in the UTP Results Document.  Other
possible entries include "Failed", "Not
Tested", "Partial Failure", and "Not as
expected but acceptable".  Remarks –
Comments on the test (indicates specific
work around to be performed, if the test
couldn't be performed adequately
because of data, etc.)  Difference from
expected results should be indicated.  The
implications of a not "as expected" test
should also be noted. (What problems
might result because the condition
couldn't be tested or failed.)
Executed By/Date
 R
 Date executed and test controller's initials
     
Additional UTP Guidelines
Unit test results should be screen-printed using SnagIt (if available), reduced to monochrome, and included in the UTP
Results Document.  Results should be cross-referenced to the appropriate unit test plan step by indicating 'Step 1.1',
etc. plus a description.  This step number and description should be placed just above the screen print in the UTP
Results Document (see the instructions in the UTP Results Document for more details).  All selection screen entries
and corresponding results appearing during execution of the UTP should be screen-printed and cross-referenced.

The following should be tested in the UTP:
·        Defaults
·        All calculations
·        Check that database selects are returning the correct data
·        Screen flows are correct
·        Screen information is correctly displayed
·        Database updates/modifications are correct
·        Standard header is used (if applicable)
·        Sorts are correct
·        Subtitles are correct
·        Negative signs on numbers are in the right place
·        Any rounding is occurring correctly
·        Any truncation is occurring correctly
·        If there is no data to be displayed, an appropriate message occurs
·        Any error checks and/or validations performed by the program etc.
All of the  product names here are trademarks of their respective companies.  The site
www.allsaplinks.com no way affiliated with SAP AG. We have made every effort for the content
integrity.  Information used on this site is at your own risk.
Google