UAT Best Practices
George Henke
the User Acceptance Testing (UAT) should take place?
1) In the developers' Integration Testing environment and conducted by
developers
2) In the Quality Assuarnce (QA) environment and conducted by QA analysts
Also where should final user signoff occur?
Thank you
George Henke
(C) 845 401 5614
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
McKown, John
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
George Henke
When you say IT, do you mean Integration Test or a QA environment and who
does the testing, developers or QA analysts.
On Tue, Jun 15, 2010 at 10:06 AM, McKown, John <
John....@healthmarkets.com> wrote:
> I can only say that we do this function in a separate Q/A (Model Office)
> section in IT.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
>
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * (817)-961-6183 cell
> john....@healthmarkets.com * www.HealthMarkets.com<http://www.healthmarkets.com/>
--
Donald Johnson
without publishing War and Peace, can you who are willing summarize your
testing? I think we can all learn from others, and improve our testing
processes to reduce unplanned "oops" outages.
For example, I know of a site that had a testing methodology similar to
this:
1. Development (coding changes) followed by unit testing in a development
region (batch programs in the developer's personal library. Minor regression
testing of inter-related components here.
2. Migration to a test environment - integration testing of the changes in
the related components and regression testing of the application. Then full
case (all possibilities covered by the change) and stress testing here. All
this done by the development/support team.
3. After documentation, report and screen presentation sign off by user,
creation of parallel "integration/QA" environment, using live production
data for QA and UAT, conducted by user team/user management. This is a
temporary, throw-away environment.
4. Finally, migration to the production environment with final UAT and
signoff conducted during an application or system outage window. This is
conducted by select users (sometimes the entire user team) and user
management, with the developer/developer's manager available for last minute
training or usage questions. Data is sometimes preserved via backups, with
"live" processing, and subsequent restore of data, or in some cases, live
processing is conducted during this test and left in place.
* Don *
Peter Nuttall
in a separate QA environment, by the user team who will be signing off the
change.
The developers integration testing is purely a place where the developer
finds out if his program plays nicely with everyone else, and normally
only has a subset of data to play with.
But, as Don pointed out it can get very convoluted, depending on when and
who gives the signoff, and how much functional and volume testing is
required to be executed.
Hope that helps ...
"George Henke" <gah...@GMAIL.COM>
Sent by: "IBM Mainframe Discussion List" <IBM-...@bama.ua.edu>
15/06/2010 03:49 PM
Please respond to
"IBM Mainframe Discussion List" <IBM-...@bama.ua.edu>
Subject
UAT Best Practices
Thank you
This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you have received this message in error, please notify us immediately and delete it from your system. Please visit our website to read the full disclaimer: http://www.euroclear.com/site/public/disclaimer
McKown, John
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of George Henke
> Sent: Tuesday, June 15, 2010 9:16 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: UAT Best Practices
>
> Thank you, John
>
> When you say IT, do you mean Integration Test or a QA
> environment and who
> does the testing, developers or QA analysts.
----------------------------------------------------------------------
George Henke
The operative word here is "best practices". Something that will survive an
audit.
--
Sam Siegel
> Thank you.
>
> The operative word here is "best practices". Something that will survive an
> audit.
To pass an audit (internal and/or external) without qualification, it
is best to have a completely separate environment (HLQ, CICS, etc.)
for the UAT system. Code and other related software changes should be
installed into the UAT system by the same means they would be
installed into your production systems.
Developers, QA and other on-call staff should be restricted from the
UAT system as the final measure to show there are proper firewalls in
place and that UAT truly represents the to-be production system.
Sam
>
> On Tue, Jun 15, 2010 at 10:28 AM, Peter Nuttall <Peter....@euroclear.com
>> wrote:
<snip>
R.S.
> Would someone please tell me what is "best practices" as to where most of
> the User Acceptance Testing (UAT) should take place?
>
> 1) In the developers' Integration Testing environment and conducted by
> developers
> 2) In the Quality Assuarnce (QA) environment and conducted by QA analysts
> Also where should final user signoff occur?
The best place is production - there you have all the data. The best
team to do it is Development team - they know better how to use it; this
is also the reason why no technical documentation is needed. There
should be no separate QA environment and separate team. <g>
Funny ? I heard some of the statements above. Spoken seriously.
OK, IMHO UAT should be conducted *before* QA. The environmnet could be
the same as UAT, but it could lead to bottlenecks - one team waits for
another.
IMHO it shouldn't be Integration Testing env. because of bottlenecks
too, even stronger.
Obviously UATs are done by the users, but watch details - who is a user
of batch? Who's responsible for checking performance?
YMMV
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
S d Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru S dowego,
nr rejestru przedsi biorców KRS 0000025237
NIP: 526-021-50-88
Wed ug stanu na dzie 01.01.2009 r. kapita zak adowy BRE Banku SA (w ca o ci wp acony) wynosi 118.763.528 z otych. W zwi zku z realizacj warunkowego podwy szenia kapita u zak adowego, na podstawie uchwa y XXI WZ z dnia 16 marca 2008r., oraz uchwa y XVI NWZ z dnia 27 pa dziernika 2008r., mo e ulec podwy szeniu do kwoty 123.763.528 z . Akcje w podwy szonym kapitale zak adowym BRE Banku SA b d w ca o ci op acone.
George Henke
do it is Development team - they know better how to use it; this is also the
reason why no technical documentation is needed. There should be no separate
QA environment and separate team. <g>
Funny ? I heard some of the statements above. Spoken seriously
Why not? You don't have to create test data, you're working with live data,
the real thing, you're testing security at the same time, and there is no
migration or cutover needed, you're already there.
One of my clients once said this facetiously. We both had a good laugh, but
there is some truth to it. ;-)
--
George Henke
(C) 845 401 5614
----------------------------------------------------------------------
Kirk Talman
them, how can you do formal in house testing before giving the code to the
customer to test? It also limits the time frames for testing in an
environment where changes come in regular waves (like releases).
If UAT is "owned" by the customer, should they not have (and want to have)
full control over the data in it? And to have that data very similar to
"real" data.
Would a customer want QA testers (much less programmers) to have access to
data which looked sufficiently like production data?
Would QA testers want data limited to the preferences and customs of just
one customer?
Auditors, both internal and external, in English speaking countries at
least, want the greatest possible distance between "real" data and anyone
not requiring access to that data.
Regression testing is not easy (or cheap) in a modern database
environment. On the other hand it is a great sleep aid.
From: George Henke <gah...@GMAIL.COM>
To: IBM-...@bama.ua.edu
Date: 06/15/2010 09:49 AM
Subject: UAT Best Practices
Sent by: IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
Thank you
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you
Galambos, Robert
Don't know if what is stated below is something that you are considering, so let me give you my 2 cents.
1) NO
2) NO
But seriously here are some of the reasons that will cause you issues
Privacy. If you have a separate environment with production data, you MAYBE in jeopardy of contravening some privacy laws. Also the increased risk of a data breach, given that normally these type of environments are not as secure as production. (you may have people outside the normal process accessing the data, and thus needing a more 'open' access rules). No one wants to be in the front page of the WSJ. 70% of data breaches are NON malicious in nature.
QA function is not the same as UAT. UAT is for the 'power user' to 'check out' the changes and make sure everything new works as expected. They have the knowledge of the business rules that are inherent within the application. Developers know the CODE and thus it is not the same thing.
QA can/should be used for regression testing. (making sure all the critical process work).
UAT can/should be used to check the business rules to make sure they work as they should. Weather the new/changed functionality.
At times they may seem similar, but in realty are not. The people involved are not the same either, nor is their experience/knowledge.
A Automated testing vehicle (a process where critical repeatable tests can be done to verify that all critical process within the application con't to work no matter what should also be considered).
More info contact me offline,
Robert Galambos CIPP/C CIPP/IT
Compuware Senior Technical Specialist
IBM Certified Solutions Expert -
DB2 UDB for OS/390 Database Administration
Certified Information Privacy Professional/Canada
Certified Information Privacy Professional/Information Technology
robert....@compuware.com
BLOG: blog.compuware.com
Tel: +1 905 886 7000
Toll Free: +1 800 263 7189
Fax: +1 905 886 7023
Quebec: +1 877-281-1888
Compuware Canada
Service is our best product
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of George Henke
Sent: Tuesday, June 15, 2010 12:18 PM
To: IBM-...@bama.ua.edu
Subject: Re: UAT Best Practices
The best place is production - there you have all the data. The best team to do it is Development team - they know better how to use it; this is also the reason why no technical documentation is needed. There should be no separate QA environment and separate team. <g>
Funny ? I heard some of the statements above. Spoken seriously
Robert: Don't