Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

QA Release Policy

No description
by

Vanessa Rodrin

on 17 July 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of QA Release Policy

Objectives
To be fam
iliar

with the dif
ferent
QA rel
ease
policies

To
kn
ow the different QA rele
as
e
types
for
projects

When should a product be released?
“Product is compiled
and can run with as few bugs as possible”
- Developers
“Product met the minimum
design specifications”
- Program Managers
“Product satisfies the minimum market expectations in a timely manner”
- Product Managers
“Pre-determined acceptable bugs have been reached.”
- http://www.softwaretestingstuff.com
“By bug triage.”
- http://www.marsdd.com
All releases
must undergo testing
Monitoring of
PM
for projects under Product Change (PC) and Product Development (PD)
Checking of
Project Coordinator
on Project Plan (PPL) and Project Member List (PML) for projects under PD
Uploading of Design Verification Report (DVR) by
QA Primary
in myTeczo
- Inclusion of Testing Activities on the schedule
QA
Release
Policies
All releases that have been
suspended
must be
re-evaluated
Severity 1 defects and blocking problems were found
Fixes for required defects to be resolved have side effects
Non-compliance to the standard operating procedures and project collaboration program process and documentation
All releases must be classified depending on their
MATURITY
Weekly monitoring of Testing

Number of test cases

Number of Bugs

Bug Triage
- Priority (PM), Severity (QA)

Number of Executed Test Cases
- Failed/Pass
All releases must complete the
PCP process and documentations
Monthly monitoring of the upper management and follow-ups by PCP Champions
PCP summary chart (PCP champions)
All
non-compliances
must be resolved
R
e
qui
rements checki
n
g by
PM
De
sign Specifications
r
evi
ew
and approval by
COS/ADT Engineers
Test plan creation wi
th REQ

and DSP ID using Traceability Matrix b
y

QA Primary
All
re
leases must be scanned fo
r

virus

ALL releases
must be scanned using
Virus Total
ALL virus total

links
shou
ld
be included
on
th
e

f
ina
l

D
VR for upload
(.exe,
.dll
,
.
mui,.dat,.log,
.sy
s,
etc
.)
All candidate releases must be archived and made available to
all
stakeholders

Back-up every after release in:
//acsmanila/QA/RELEASES
//acsmanila/QA/QUARTERLY/
2013_Q4

//Projects/Workspace
//acsmanila/Product Information Directory
myTeczo upload
TYPES
OF
RELEASES

The
Pre-Alpha
Release
All activities prior to testing were performed
Requirements Analysis
System Design
Development
Unit Testing
The product has undergone unit testing and code review
Additional features or functions are expected
The
Engineering Sample
Release
The product has undergone UIS Testing and Code Review
The product can be unstable and could crash or suffer data loss
Ends with a "feature freeze", indicating that no more features will be added. At this time it is said to be "feature complete"
Examples: SM Demo
This release is for evaluation purposes
The
Alpha Candidate
Release

All required features to be supported for the release were verified to be implemented correctly according to specifications
All Severity 1 (Showstopper) and High priority bugs were verified to be completely resolved
All significant non-compliance issues affecting the release were completely resolved
The product was verified to serve its intended purpose
The

Beta Candidate

Release
All Alpha criteria was satisfied
All medium priority bugs were verified
to be completely resolved
The
Final Candidate
Release
All reported bugs in the defect database were verified to be completely resolved
No Low and Aesthetic issues found
No pended Change request items
End - Of - Life
(EOL)
No longer
to be sold or supported. The product is said to have
reached end-of-life
, to be
discontinued
or deemed as
obsolete
, but user’s loyalty may continue its existence for some time, even long after its platform is obsolete.
General

Availability
All necessary commercialization activities have been completed and the product has been made available to the
general market
either via the web or physical media.
Any change, even a change for the better, is
ALWAYS
accompanied by drawbacks and discomforts.

Arnold Bennett
Full transcript