Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Quality Assurance and Quality Control

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 23

Quality Assurance and

Quality Control

1
What Exactly is Quality?

 Customer’s View of Quality


 Producer’s View of Quality

2
What Exactly is Quality?

 Customer’s View of Quality


• Receiving the right product
for their use
• Being satisfied that their
needs have been met
• Being treated with integrity,
courtesy and respect

3
What Exactly is Quality?

 Producer’s View of Quality


• Doing the right thing
• Doing it the right way
• Doing it on time without
exceeding cost

4
Quality Assurance vs. Quality Control

Quality Control (QC):


 QC is the set of activities that are carried out to
verify the developed product meets the
required standards.
 reviews and testing, focus on detection/
correction of defects before shipment of
products
 QC focuses on the improvement of the product
by identifying the bugs and issues.
 QC is corrective process as it focuses on identifying
the bugs and getting them fixed.
 It is the responsibility of testing team that finds the
issues.

5
Quality Assurance vs.
Quality Control
Quality Assurance (QA):
 QA is the implementation of processes, methodologies
and standards that ensure that the software developed will
be up to the required quality standards.
 Set of activities, including facilitation, training,
measurement and analysis
 QA is preventive process as it establishes the methods
which prevent the bugs.promotes quality concepts,
quality attitudes and discipline for management and
workers
 All the persons involved in the project starting from the
requirement.

6
Quality Assurance vs.
Quality Control
Are these activities QA or QC?
QC performance testing software

conducting an internal audit of the performance test


QA
process
QC writing test plans
QA training staff on the document review process

 writing requirements documents

QC conducting document reviews on project work products

QA analyzing patterns of defects captured in


document reviews

7
QA Roles and Activities
Traditional QA Agile QA
•Independent group •Integrated with day to
•Gatekeepers who… day development
Understand testing well and •Proactive, engage in QA
know how to specify and
validate system qualities Certify activities much earlier
app functionality based upon •Team work closely with
contracts and requirements …
PO and SMEs and have
•Get involved late in the
software lifecycle
common ownership for
quality.

8
QA Mindset in an Agile Methodology

 Quality does NOT only mean System Testing but the entire
application
 Quality is responsibility of the ENTIRE Scrum Team
 Continuous Integration will Lead to Continuous QA
 Progressive inclusion of System Integration test cases from
sprint to sprint
 QA resource plays a role of BA/QA removing any gaps in
requirements communication
 Prioritize Test Cases by Risk and Frequency of Feature Usage
 Utilize the Sprint Retrospective to Identify “Where” in the scrum
process did failure of quality occur (Root Cause Analysis)

9
How Quality Scenarios and Quality
Testing Fit Into An Agile Process

10
Agile Quality Assurance and
Control

11
Testing Cycle for TDD
• PRODUCT OWNER IN THE TEAM
• RELEASABLE SOFTWARE EVERY SPIRNT
• SCHEDULED PRODUCT REVIEWS
• FREQUENT STATUS MEETINGS
• AUTOMATED UNIT TESTS
• ACCEPTANCE TESTS
• TEST DRIVEN DEVELOPMENT
• REGRESSION TESTING
• EXPLORATORY TESTING
• CODE REVIEW
• CONTINUOUS INTEGRATION

12
PRODUCT OWNER IN THE TEAM
The team is trying to build software that meet’s the Product Owner’s
intent, rather than what they wrote down, so in the Agile world the
Product Owner becomes part of the team and guides development.
Sometimes the Product Owner cannot devote 100% of their time to
the project

13
RELEASABLE SOFTWARE EVERY
TIMEBOX

Each SPRINT is meant to result in releasable code.  Although


meeting the Product Owner’s expectations is a priority it is not
the only criteria.

14
SCHEDULED PRODUCT REVIEWS

The product is formally reviewed in the Timebox Review Meeting


at the end of each Timebox. You can schedule more formal
reviews during the Timebox, and for longer Timeboxes (say 3 or
4 weeks) this is a good idea. DSDM mandates the results of
these reviews are documented. I think this is a good idea but I’m
not too tied to review documents. I recommend documenting the
reviews in the same was as I described in the Unscheduled
Product Reviews, i.e. an email to the relevant stakeholders.

15
FREQUENT STATUS MEETINGS

The team monitors project progress in the Daily Team Meeting. It is


also an opportunity to review whether the team is following the agree
approach.

16
AUTOMATED UNIT TESTS

• Automated unit tests express the internal


behaviours of the software. The total suite of
automated unit tests become regression tests and
are used to verify that the internals of the software
continue to function as designed after subsequent
changes. Agile teams aim for 100% pass rate for
automated unit tests.
• More mature teams write the tests before they
write the code in Unit Test Driven Development.

17
ACCEPTANCE TESTS

In DSDM there are documented quality criteria for all work products
(DSDM, 2002), but looser forms of Agile restrict this to the User
Stories. User Stories are the high level description of the external
behaviors and business rules of your software. Each User Story has at
least one acceptance test. The acceptance tests elaborate the brief
description provided by the User Story.  They define the scope of the
story and clarify the Product Owner’s intent with concrete examples.
This clarifies the Product Owner’s intent, points the team in the right
direction, and confirm when the intent has been met.

18
TEST DRIVEN DEVELOPMENT

In Test Driven Development the tests become the specification.


Because the tests are automated there is no ambiguity, the software
either passes the test or it fails.

19
REGRESSION TESTING

A regression test is the repeat of an earlier test.  Usually that means


Unit Tests and Acceptance tests. Regression tests ensure that changes
to the software have not broken good code.  My experience is that if
regression tests are manual they don’t happen.  It is with regression
testing that the real value of test automation is shown.

20
EXPLORATORY TESTING

Exploratory Testing uses un-scripted tests to quickly identifying new


types of problems with the software. Show stoppers (such as system
crashes or unhandled errors) are usually fixed immediately. Less
serious problems might be deferred.  This testing might also reveal
new User Stories to be scheduled into later Timeboxes.

21
CODE REVIEW

The Two Pairs of Eyes approach provides a peer review of code to


check it follows agreed coding standards, conforms to design
guidelines and is easily understood by developers other than the
author. This can be either through pair programming or more
traditional code reviews/walkthroughs.

22
CONTINUOUS INTEGRATION

Continuous Integration is about maintaining quality all the time,


throughout the project. It involves automatically integrating and
running a regression test every time somebody does a check in. This is
likely to happen several times a day. Running an automated regression
test frequently means defects are highlighted soon after they are
introduced (i.e. when the build goes Red, i.e. fails). The team’s top
priority is to get the build Green again.

23

You might also like