Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 5. marts 2014. Læs mere om interessegruppen her: http://infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Michael Bolton - Two Futures of Software TestingTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Two Futures of Software Testing by Michael Bolton. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Software quality improvement expert Jan Princen and XBOSoft CEO Philip Lew discuss the use of Predictive Analytics to prevent software defects in this XBOSoft webinar on Defect Prevention.
Christian Bk Hansen - Agile on Huge Banking Mainframe Legacy Systems - EuroST...TEST Huddle
EuroSTAR Software Testing Conference 2011 presentation on Agile on Huge Banking Mainframe Legacy Systems by Christian Bk Hansen. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Klaus Olsen - Agile Test Management Using ScrumTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Agile Test Management Using Scrum by Klaus Olsen. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Michael Bolton - Two Futures of Software TestingTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Two Futures of Software Testing by Michael Bolton. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Software quality improvement expert Jan Princen and XBOSoft CEO Philip Lew discuss the use of Predictive Analytics to prevent software defects in this XBOSoft webinar on Defect Prevention.
Christian Bk Hansen - Agile on Huge Banking Mainframe Legacy Systems - EuroST...TEST Huddle
EuroSTAR Software Testing Conference 2011 presentation on Agile on Huge Banking Mainframe Legacy Systems by Christian Bk Hansen. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Klaus Olsen - Agile Test Management Using ScrumTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Agile Test Management Using Scrum by Klaus Olsen. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Develop a Defect Prevention Strategy—or Else!TechWell
Defects occurring throughout the development of a software project penalize the project. The effort spent remediating these defects robs the project team of valuable time, resources, and money that could otherwise be used for further innovation and delivering the highest possible quality product to wow the customer. The occurrence of a large percentage of these defects can be avoided with preventive defect removal strategies. Scott Aziz describes various methods for removing defects during the early design and development phases―long before testing. Methods include requirements-based testing that eliminates 95 percent of requirements defects prior to the coding phase, code reviews and inspections, and establishing model-based test design practices that allow for testing business requirements before any code is developed. Take back and adopt in your environment some of the most effective early defect prevention practices known and practiced in the industry today.
Graham Bath - SOA: Whats in it for Testers?TEST Huddle
EuroSTAR Software Testing Conference 2009 presentation on SOA: Whats in it for Testers? by Graham Bath. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Michael Snyman - Software Test Automation Success TEST Huddle
EuroSTAR Software Testing Conference 2009 presentation on Software Test Automation Success by Michael Snyman. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Derk jan de Grood - ET, Best of Both WorldsTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on ET, Best of Both Worlds by Derk jan de Grood. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Thomas Axen - Lean Kaizen Applied To Software Testing - EuroSTAR 2010TEST Huddle
EuroSTAR Software Testing Conference 2010 presentation on Lean Kaizen Applied To Software Testing by Thomas Axen . See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Whether you are new to testing or looking for a better way to organize your test practices and processes, the Systematic Test and Evaluation Process (STEP™) offers a flexible approach to help you and your team succeed. Dale Perry describes this risk-based framework—applicable to any development lifecycle model—to help you make critical testing decisions earlier and with more confidence. The STEP™ approach helps you decide how to focus your testing effort, what elements and areas to test, and how to organize test designs and documentation. Learn the fundamentals of test analysis and how to develop an inventory of test objectives to help prioritize your testing efforts. Discover how to translate these objectives into a concrete strategy for designing and developing tests. With a prioritized inventory and focused test architecture, you will be able to create test cases, execute the resulting tests, and accurately report on the quality of your application and the effectiveness of your testing. Take back a proven approach to organize your testing efforts and new ways to add more value to your project and organization.
When Agile is a Quality Game Changer Webinar - Michael Mah, Philip LewXBOSoft
Accelerate your Agile success with in-depth research and smarter decisions. Michael Mah of QSM Associates shows you what it takes to find and utilize patterns of successful Agile development in this quarterly XBOSoft webinar.
Lauri Pietarinen - What's Wrong With My Test DataTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on What's Wrong With My Test Data by Lauri Pietarinen. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
This is short course on Defect Analysis & Prevention.
The course covers following main topics:
1. What is Defect Analysis?
2. Defect Prevention
3. Defect Analysis Procedure
4. Defect Prevention Action Planning
5. Summary
It discusses use of Pareto Charts & Fish bone diagrams, to focus on main causes that are causing 80% of the defects, and then perform in-depth analysis of those causes.
This helps to come up with Defect Prevention Plan for your project/product.
Otto Vinter - Analysing Your Defect Data for Improvement PotentialTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Analysing Your Defect Data for Improvement Potential by Otto Vinter. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Kasper Hanselman - Imagination is More Important Than KnowledgeTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Imagination is More Important Than Knowledge by Kasper Hanselman. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Dietmar Strasser - Traditional QA meets Agile DevelopmentTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Traditional QA meets Agile Development by Dietmar Strasser. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 6. marts 2012.
Læs mere om interessegruppen på http://www.infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 28. februar 2013. Læs mere om interessegruppen her: http://www.infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Develop a Defect Prevention Strategy—or Else!TechWell
Defects occurring throughout the development of a software project penalize the project. The effort spent remediating these defects robs the project team of valuable time, resources, and money that could otherwise be used for further innovation and delivering the highest possible quality product to wow the customer. The occurrence of a large percentage of these defects can be avoided with preventive defect removal strategies. Scott Aziz describes various methods for removing defects during the early design and development phases―long before testing. Methods include requirements-based testing that eliminates 95 percent of requirements defects prior to the coding phase, code reviews and inspections, and establishing model-based test design practices that allow for testing business requirements before any code is developed. Take back and adopt in your environment some of the most effective early defect prevention practices known and practiced in the industry today.
Graham Bath - SOA: Whats in it for Testers?TEST Huddle
EuroSTAR Software Testing Conference 2009 presentation on SOA: Whats in it for Testers? by Graham Bath. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Michael Snyman - Software Test Automation Success TEST Huddle
EuroSTAR Software Testing Conference 2009 presentation on Software Test Automation Success by Michael Snyman. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Derk jan de Grood - ET, Best of Both WorldsTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on ET, Best of Both Worlds by Derk jan de Grood. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Thomas Axen - Lean Kaizen Applied To Software Testing - EuroSTAR 2010TEST Huddle
EuroSTAR Software Testing Conference 2010 presentation on Lean Kaizen Applied To Software Testing by Thomas Axen . See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Whether you are new to testing or looking for a better way to organize your test practices and processes, the Systematic Test and Evaluation Process (STEP™) offers a flexible approach to help you and your team succeed. Dale Perry describes this risk-based framework—applicable to any development lifecycle model—to help you make critical testing decisions earlier and with more confidence. The STEP™ approach helps you decide how to focus your testing effort, what elements and areas to test, and how to organize test designs and documentation. Learn the fundamentals of test analysis and how to develop an inventory of test objectives to help prioritize your testing efforts. Discover how to translate these objectives into a concrete strategy for designing and developing tests. With a prioritized inventory and focused test architecture, you will be able to create test cases, execute the resulting tests, and accurately report on the quality of your application and the effectiveness of your testing. Take back a proven approach to organize your testing efforts and new ways to add more value to your project and organization.
When Agile is a Quality Game Changer Webinar - Michael Mah, Philip LewXBOSoft
Accelerate your Agile success with in-depth research and smarter decisions. Michael Mah of QSM Associates shows you what it takes to find and utilize patterns of successful Agile development in this quarterly XBOSoft webinar.
Lauri Pietarinen - What's Wrong With My Test DataTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on What's Wrong With My Test Data by Lauri Pietarinen. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
This is short course on Defect Analysis & Prevention.
The course covers following main topics:
1. What is Defect Analysis?
2. Defect Prevention
3. Defect Analysis Procedure
4. Defect Prevention Action Planning
5. Summary
It discusses use of Pareto Charts & Fish bone diagrams, to focus on main causes that are causing 80% of the defects, and then perform in-depth analysis of those causes.
This helps to come up with Defect Prevention Plan for your project/product.
Otto Vinter - Analysing Your Defect Data for Improvement PotentialTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Analysing Your Defect Data for Improvement Potential by Otto Vinter. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Kasper Hanselman - Imagination is More Important Than KnowledgeTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Imagination is More Important Than Knowledge by Kasper Hanselman. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Dietmar Strasser - Traditional QA meets Agile DevelopmentTEST Huddle
EuroSTAR Software Testing Conference 2008 presentation on Traditional QA meets Agile Development by Dietmar Strasser. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 6. marts 2012.
Læs mere om interessegruppen på http://www.infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 28. februar 2013. Læs mere om interessegruppen her: http://www.infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 19. september 2011.
Læs mere om interessegruppen på http://www.infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT afd. Nord den 6. november 2013. Læs mere om interessegruppen her: http://infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 28. februar 2013. Læs mere om interessegruppen her: http://www.infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 11. juni 2014. Læs mere om interessegruppen her: http://infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 6. juni 2012.
Læs mere om interessegruppen på http://www.infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 5. marts 2014. Læs mere om interessegruppen her: http://infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Processer & IT Nord den 11. juni 2014. Læs mere om interessegruppen her: http://infinit.dk/dk/interessegrupper/processer_og_it/processer_og_it.htm
Metrology & The Consequences of Bad Measurement DecisionsRick Hogan
Learn the risks of making decisions based on bad measurement data, including case studies like the torque wrench that cost NASA nearly 2 billion dollars.
As a software tester, you may often face a situation in which your customer requires completing testing faster than you can handle given your effort and the amount of test. For example, in order to complete testing 2000 test cases for a build, you need at least 10 days to complete all testing. However, your customer needs to test and release the build within 5 days. You need to make a tough decision to handle this request. This presentation offers you one of the approaches that you can pursue. The presentation discusses an approach to prioritizing test cases using the principles of value-based software engineering. The approach is based on the principle that not every test case is equally importantly, e.g., not each of the 2000 test cases has the same value. A simple Excel tool will also be provided to allow you quickly prioritize test cases and select the ones that generate best value for your customer.
Leverage Your EDC Solution to Mitigate Risk in Clinical Researchwww.datatrak.com
Every clinical trial is built upon a study protocol - the cornerstone of any trial. A well-defined and written study protocol provides the blueprint for the study, defining its purpose and goals. Studies have become more complex, creating more complicated study design, which can lead to making adherence more challenging for the study team and participants. The potential risk that some aspect of the study could be done incorrectly or not comply is inherent in all studies, but particularly present in complex research.
In order to help mitigate risk, advances in technology and the tools available today provide ways for us to mitigate some of the risk introduced in our clinical trials. While the study protocol is a cornerstone for the clinical trial, electronic data capture (EDC) applications have evolved in the broadest sense into technology solutions that provide us with a variety of tools to help mitigate risk.
Here is the Six sigma training material part 7, presented by Skillogic Knowledge Solutions. If you are looking for Lean + Six Sigma training in Bangalore / Bengaluru, Visit Skillogic and schedule you classroom training.
The anonymised slides from an old (but hopefully still relevant) talk on the case for placing a strategic focus on design testability. The material covers the technical, process and organisational considerations arising from such a strategy and is predominantly a summary of the ideas presented in Brett Pettichord's 2001 "Design For Testability' paper available here. The presentation makes a case for why a high level of design testability can be seen as a critical success factor in achieving sustained agility.
In this chapter, we will introduce you to the fundamentals of testing: why testing is needed; its limitations, objectives and purpose; the principles behind testing; the process that testers follow; and some of the psychological factors that testers must consider in their work. By reading this chapter you'll gain an understanding of the fundamentals of testing and be able to describe those fundamentals.
We have experience with testing projects, both large and small. Sometimes our test estimates are accurate—and sometimes they’re not. We often miss deadlines because there are no defined criteria used to create our estimates. Sometimes we miss our schedules due to crunched testing timelines. Shyam Sunder briefly describes the different test estimation techniques including Simple, Medium, Complex; Top Down, Bottom Up; and Test Point Analysis. To assist in better estimating in the future, Shyam has prepared test estimation templates and guidelines, which can significantly help organizations in proper estimation of testing projects. Through his work, effort and schedule variations have significantly improved from ±60 percent to ±2 percent. Shyam explains the test estimation templates in detail and demonstrates how to choose the estimation templates for your organization’s software development process. Learn why effective software test estimation techniques help in tracking and controlling cost/effort overruns significantly.
COURSE IS NOW FULLY AVAILABLE AND LIVE HERE: https://goo.gl/gVukvc
This is the first section of six parts to cover what you need to learn about ISTQB foundations exam. Broken down into pieces and examples to pass. Check out more on my blog: https://www.rogeriodasilva.com/
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
GraphSummit Singapore | The Future of Agility: Supercharging Digital Transfor...Neo4j
Leonard Jayamohan, Partner & Generative AI Lead, Deloitte
This keynote will reveal how Deloitte leverages Neo4j’s graph power for groundbreaking digital twin solutions, achieving a staggering 100x performance boost. Discover the essential role knowledge graphs play in successful generative AI implementations. Plus, get an exclusive look at an innovative Neo4j + Generative AI solution Deloitte is developing in-house.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Elevating Tactical DDD Patterns Through Object Calisthenics
Risk based QA af Michael Agerkvist Petersen, Radiometer Medical
1. 07/03/14
1
Risk
Based
QA
Michael
Agerkvist
Petersen
miap@post3.tele.dk
dk.linkedin.com/in/michaelagerkvist
Michael
Agerkvist
Petersen
• QA
@
Radiometer
Medical
• 18+
years
with
Medical
Devices
– HW
development
– SW
development
– Project
Management
– Process
Improvement
– QA
• Owner
of
MDCA
(Medical
Device
Compliance
Assistance)
–
Spare
Qme
job
J
2. 07/03/14
2
Risk
Based
QA
• Based
on
my
experience
from:
– Making
a
class
C
Medical
Device
at
Novo
Nordisk
– Working
with
Encrypted
Pin
Pads
(ATM
keyboards)
at
Cryptera
– Other
projects
• This
will
not
be
a
complete
introducQon
to
(safety)
risk
management
or
Risk
Based
TesQng.
Agenda
• IntroducQon
• Risk
Based
Quality
Assurance
– Regulatory
Risks
–
Process
Rigor
– Risk
Based
DocumentaQon
Rigor
– Risk
Based
TesQng
– ProacQve
QA
• Examples
• PiZalls
3. 07/03/14
3
IntroducQon
Some
definiQons
• Quality:
The
totality
of
features
and
characterisQcs
of
a
product
or
service
that
bears
its
ability
to
saQsfy
stated
or
implied
needs
[ISO]
– There
are
many
different
customers:
Users,
OrganizaQon,
Regulatory….
• QA:
Quality
Assurance
–
many
ways
to
implement
this
in
pracQce
– Ensuring
that
development
is
in
compliance
(with
defined
process)
– Doing
the
actual
tesQng
– “anything”
which
helps
ensuring
Quality
to
the
different
customers
4. 07/03/14
4
Soeware
today
• Today
soeware
controls
more
and
more
in
our
daily
life.
• Soeware
failures
may
negaQvely
affect
business,
human
health
or
even
human
life
• ResulQng
in
increasing
public
and
regulatory
demands
for
befer
products
and
even
more
Qme
pressure.
Regulatory
Compliance
• More
and
more
industries
gets
regulated
• Some
are
more
regulated
than
others
Accident
Injury
or
other
loss
Public
reacQon
New
laws
&
regulaQons
Regulated
Industry
Nuclear
Flight
Medical
Device
Military
Payment
systems
Public
Systems
• The
bar
is
raised
over
Qme
[Not
to
scale]
5. 07/03/14
5
TesQng
Paradox
• TesQng
is
a
structured
approach
to
reduce
the
number
of
defects
it
is
the
last
acQvity
before
release.
So
it
is
oeen
the
first
to
be
sacrificed
• TesQng
is
always
a
sample.
You
can
never
test
everything,
and
you
can
always
find
more
to
test.
• A
good
test
case
is
one
finding
a
defect
–
running
a
complete
test
suite
without
finding
a
single
defects
will
not
add
much
value.
• The
problem
with
most
systemaQc
test
methods,
like
black
box
methods
(equivalence
parQQoning,
boundary
value
analysis
,
cause-‐effect
graphing,
etc.),
is
that
they
generate
too
many
test
cases,
many
of
them
will
never
find
a
defect.
• However
–
in
a
regulated
world
it
adds
value
to
run
tests
which
does
not
find
defects
–
a
“clean
sheet”
is
needed
to
make
a
submission
without
too
many
quesQons
Risk
Based
Approach
• A
way
to
lessen
the
the
work
load.
Could
be
to
test
more
in:
– bad
areas
of
the
product.
– the
most
important
funcQonal
areas
and
product
properQes.
• And
tesQng
less
in
the
other
areas…
• But,
how
to:
– find
the
right
areas?
– PrioriQzing
other
QA
acQviQes?
6. 07/03/14
6
Risk
Based
Quality
Assurance
TradiQonal
QA
• Consist
of:
– Review
– Dynamic
Test
– StaQc
analysis
– Templates
– Source
Code
standards
– Traceability
analysis
– Checklists
– Etc
• They
are
typically:
– Time
consuming
– Passive
– Always
compromised
due
to
Schedule
pressure
7. 07/03/14
7
Balancing
QA
Too
li-le
• Safety
risk
• Poor
reliability
• AddiQonal
cost
• Project
delay
• Regulatory
failure
• Customer
complaints
Too
much
• AddiQonal
cost
• Project
delay
• Under
verificaQon
(in
the
more
important
areas)
• Increased
maintenance
Result
of
poor
QA
Liability
and
liQgaQon
Recalls
Loss
of
company
image
In-‐market
updates
ReducQon
in
performance
No
regulatory
approval
Project
delay
Death
Major
Injury
Minor
Injury
Security
violaQon
ReducQon
in
performance
Loss
of
data
Business
cost
Customer
cost
Severity
High
Low
8. 07/03/14
8
Risk
Based
QA
Approach
• Some
QA
acQviQes
will
sQll
be
Passive
– They
are
well
known
and
needed
• Some
QA
acQviQes
will
be
more
ProacQve
– We
know
we
are
going
to
release
with
defects
-‐
so
why
not
try
to
miQgate
the
impact
of
specific
types
of
defects
in
the
design?
• All
QA
acQviQes
will
be
prioriQzed
– Some
defects
or
lack
of
process/documentaQon
will
do
more
harm
than
others.
So
why
use
the
same
effort
and
acQviQes
on
every
feature
or
enQty?
• Use
the
risk
based
QA
approach
to
– Find
the
most
criQcal
defects
as
early
as
possible
at
the
lowest
effort/
cost
– Find
the
most
criQcal
classes
of
defects
and
miQgate
the
impact
of
them
in
the
design
– Balance
the
rigor
of
process,
documentaQon
and
design
Some
risk
definiQons
• Harm:
Physical
injury
or
damage
to
the
health
of
people,
or
damage
to
property
or
the
environment.
– From
project
delay
(financial
loss)
to
death
(e.g.
of
user)
• Hazard:
PotenQal
source
of
harm
• Probability:
Of
a
harm
to
occur.
– Could
correspond
to
the
frequency
of
funcQonality
usage
by
the
user.
• Severity:
Measure
of
the
possible
consequence
of
a
hazard
– Customer
cost:
Loss
of
data
-‐>
Security
violaQon
-‐>
Injury-‐
>Death
– Business:
Project
delay-‐>Recalls-‐>Liability&liQgaQon
• Risk
=
Severity
x
Probability
[IEC
14971]
9. 07/03/14
9
Probability
• Probability
of
failure
– Usage
frequency
(funcQons
used
several
Qmes
a
day
vs
once
in
lifeQme)
– For
Medical
Device
Soeware,
probability
for
SW
defects
=
100%
-‐
but
the
probability
of
Harm
needs
to
take
probabiliQes
from
the
enQre
chain
of
events
Probability
Levels
Probability
of
Harm
Probability
of
Harm
Descrip@on
Ra@ng DefiniQon
5 Frequent
Constantly
present
4 Probable
Have
been/
will
be
reported
but
no
more
than
once
per
month
3 Occasional
Have
been/
will
be
reported
but
no
more
than
once
per
year
2 Remote
Have
been/
will
be
reported
but
no
more
than
once
in
products
lifeQme
(~10
years)
1 Improbable Considered
unlikely
to
occur
This
is
not
science…
And
very
difficult
in
real
life…
So
do
spend
too
much
Qme
finding
the
right
value
10. 07/03/14
10
Severity
Levels
Severity
of
poten@al
Harm
Harm
descrip@on
# Term Descrip@on
5 Catastrophic Results
in
immediate
death
of
paQent
or
user
• Immediate
death
of
person
caused
by
Explosion,
Fire
or
Electrical
shock
4 Serious
Results
in
permanent
impairment
or
criQcal
injury
that
would
require
medical
or
surgical
intervenQon
to
preclude
irreversible
impairment
or
damage
• Incorrect
medical
treatment
of
paQent
due
to
paQent
data
mix-‐up
• Body
part
damage
(e.g.
eye
or
fingers)
3 Moderate
Results
in
temporary/
reversible
injury
or
temporary/reversible
impairment
requiring
professional
medical
or
surgical
intervenQon
• Incorrect
or
inadequate
medical
treatment
2 Minor
Results
in
temporary
injury
or
impairment
not
requiring
professional
medical
intervenQon
• Minor
incorrect
or
inadequate
medical
treatment
• Delayed
medical
treatment,
loss
of
sample/new
sample
required
or
no
result
• Equipment
damage
• Privacy
violaQon
(e.g.
data
leak)
1 Negligible Inconvenience
or
temporary
discomfort
• UnsaQsfied
user
• Loss
of
old
data
QuanQfying
Severity
&
Probability
• Amount
of
severity
should
happen
by
considering
the
different
viewpoints
of
the
system’s
stakeholders.
• The
probability
of
impact
can
only
happen
indirectly,
e.g.
by
evaluaQon
of
– frequent
of
use,
– quality
indicators
like
the
complexity
of
the
soeware
itself,
– the
quality
of
the
documentaQon
– etc.
11. 07/03/14
11
QuanQfying
Severity
&
Probability
• Do
not
spend
too
much
Qme
determining
the
exact
values
• The
relaQve
scoring
is
the
most
important
in
order
to
idenQfy
the
most
criQcal
parts.
• The
scoring
could
be
rather
informal
and
based
on
a
brainstorm
Note:
For
Medical
Device
Class
B
and
Class
C
it
is
expected
that
the
Risk
Analysis
is
more
elaborated
than
stated
here
Risk
levels
• Four
levels
(3
should
be
OK)
• Based
on
IEC
62304
safety
class
(A,B,C)
• ClassificaQon
used
for:
– Requirements
(i.e.
some
funcQons
are
more
criQcal,
e.g.
Risk
Control
Measures
than
others)
– Structural
elements
both
design
and
actual
implementaQon
(i.e.
elements
implemenQng
criQcal
requirements)
Least
criQcal
Most
criQcal
C2
B
A
C1
12. 07/03/14
12
Ploxng
the
risks
Severity
High
Low
Probability
High
Low
High
Risks
Medium
Risks
Low
Risks
C2
C1
B
A
Different
risk
perspecQves
For
a
Medical
Device:
• Safety:
Freedom
of
unacceptable
risks.
IdenQfying
and
miQgaQng
safety
risks
to
paQents
and
users.
• Effec@veness:
Fulfil
the
medical
claims,
delivering
value
to
the
paQent
and
users.
MeeQng
the
user’s
needs.
Correctness
of
the
product,
meeQng
its
specificaQons.
• Customer
sa@sfac@on:
Good
user
experience,
good
service,
ease
of
use,
free
of
defects,
reliable.
• Regulatory:
Being
in
compliance
by
meeQng
the
Regulatory
ExpectaQons
including:
Safety,
Efficacy
and
Customer
saQsfacQon.
• Project:
MeeQng
the
organisaQons
expectaQons,
including
Quality,
Safety,
EffecQveness
and
Regulatory,
but
also
Qmelines
and
other
tradiQonal
project
risk
related
stuff.
14. 07/03/14
14
Process
Rigor
Common
FDA
Warning
lefer
issues
– Lack
of
• test
specificaQons
and
test
results
• comprehensive,
up-‐to-‐date
specificaQons
(design
input)
– Inadequate
• fault
handling
and
stress
tesQng
• change
and
release
control
Regulatory
Risks
versus
ProducQvity
&
Predictability
• RegulaQons
and
standards
does
not
seek
benefits
in
producQvity
or
project
predictability
• But
they
don’t
preclude
producQvity
and
predictability
from
being
important.
• So
it
is
your
responsibility
and
interest
to
have
development
processes
focusing
on:
– ProducQvity
– Predictability
Without
sacrificing
Safety,
Customer
saQsfacQon,
EffecQveness
and
Regulatory
risks
15. 07/03/14
15
Regulatory
Risks
versus
ProducQvity
&
Predictability
• Risk
Driven
Approach:
– Regulatory
interpretaQon
–
focus
on
the
intenQon
– ConQnuously
process
improvement
within
the
intenQon
and
frame
of
the
Regulatory
expectaQons
– Align
process
with
the
different
risks
(e.g.
Safety,
EffecQveness,
and
Customer
saQsfacQon)
associated
-‐
focus
on
what
really
mafers
• “Too
much
will
always
be
too
much,
but
maybe
not
enough”
Regulatory
Risk:
When
not
in
compliance
• Compliance
is
not
created
by:
– using
a
checklist
– copying
from
the:
• standards
• regulaQons
• guidance's
• CreaQng
compliance
is
about
meeQng
the
“intent”
of
the
standards
–
not
just
following
“the
lefer
of
the
law”
16. 07/03/14
16
Regulatory
Risk
–
Don’t
climb
too
high
E.g.
Tools
validaQon
-‐
Balancing
between:
• what
is
required
and
• when
value
adding
stops
minimum
opQmum
Risk
Based
DocumentaQon
Rigor
17. 07/03/14
17
DocumentaQon
Rigor
• To
lifle
– Difficult
to
anchor
decisions
– High
regulatory
risk
– Project
delay
– Maintenance
is
difficult
• To
much
– AddiQonal
cost
– Less
Qme
for
development
(project
delay)
– Maintenance
is
difficult
– Risk
of
in-‐consistence
– Project
delay
Requirements
Rigor
Rigor of requirementsHigh
Low
Safety
UI
User
Satisfaction
Service
Risk
Low High
Efficacy
18. 07/03/14
18
Design
Rigor
• 62304
allows
soeware
to
be
decomposed
into
soeware
items
with
different
safety
classes
– if
they
are
segregated
and
segregaQon
raQonale
provided
– No
raQonale
=>
Safety
Class
is
the
same
for
all
Item/Units.
– type
of
segregaQon
could
vary
based
on
risk
and
other
factors
Design
Rigor
–
Item/Unit
Level
Higher
Risk
Level
requires,
more
detailed
and
rigorous:
• Architecture
descripQon
• Detailed
Design
If
the
enQre
SW
is
Safety
Class
C
Detailed
design
is
required,
but
it
is
sQll
possible
to
use
the
Risk
Based
Approach
and
adjust
on
details
and
rigor
Least
criQcal
Component
Most
criQcal
Component
UI
FuncQon
Model
Driver
HAL
SI
C2
B
C2
B
A
A
C1
C1
Allocate
Risk
Level
to
the
different
Items/Units
based
on
their
responsibility
19. 07/03/14
19
Risk
Based
TesQng
Risk
Based
TesQng
• IdenQfy
the
top
most
criQcal
funcQons
• Consider:
– Evaluate
whether
the
users
will
idenQfy
defects
in
funcQon
or
afribute.
– Use
historical
data
to
idenQfy
funcQon
areas
with
many
defects
• Do
extra
tesQng
in
criQcal
areas
and
areas
with
many
defects
– Use
domain
specialists
– Extend
(automated)
regression
test
when
new
defects
are
found
20. 07/03/14
20
For
System
TesQng
Risk
level
SW
System
test
ac@vi@es
C2,
C1
• FuncQonal
• Exploratory
• Consider
other
test
strategies
(Stress,
Boundary,
Stability,
State
transsion,
Recovery)
dependent
of
the
FuncQon
under
test
and
Risk
level
B
• FuncQonal
• Security
• Exploratory
A
• FuncQonal
(all
requirements
have
at
least
one
TC)
• Allocate
Risk
Level
to
the
different
FuncQons/
requirements
based
on
the
possible
severity
and
probability.
Item/Unit
Level
tesQng
Higher
Risk
Level
requires,
more
detailed
and
rigorous
QA
AcQviQes:
• Reviews,
• TesQng,
• Etc.
If
appropriate
use
historical
data
to
idenQfy
Item/Units
with
many
defects
in
order
to
adjust
the
Risk
Level
Least
criQcal
Component
Most
criQcal
Component
UI
FuncQon
Model
Driver
HAL
SI
C2
B
C2
B
A
A
C1
C1
21. 07/03/14
21
Item/Unit
Level
tesQng
Risk
level
Unit
Tes@ng
ac@vi@es
C2
• Formal
Code
Review
by
at
least
one
SW
Developer
plus
SW
Risk
Manager
• StaQc
Analysis
• Soeware
Unit
Test,
100%
decision/condiQon
coverage
• IntegraQon
test
using
decisions
tables
and
classificaQon
trees
C1
• Formal
Code
Review
by
at
least
one
SW
Developer
• StaQc
Analysis
• Soeware
Unit
Test,
100%
Statement
coverage
• IntegraQon
test
using
decision
tables
B
• Formal
Code
Review
by
at
least
one
SW
Developer
• StaQc
Analysis
• Soeware
Unit
Test,
100%
funcQon
coverage
• IntegraQon
test
A
• Informal
Peer
Code
Review
• IntegraQon
test
part
of
System
Level
Test
Note:
Risk
Level
A
not
to
be
used
for
Class
C
Soeware
Item/Unit
Level
tesQng
&
Complexity
Risk
level
Complexity
Reduce
C2
McCabe
<=
2
AND
LoC
<
10
Reduce
Unit
Test
to
100%
FuncQon
coverage
C1
McCabe
<=
3
AND
LoC
<
20
Reduce
Unit
Test
to
100%
FuncQon
coverage
B
McCabe
<=
3
AND
LoC
<
30
No
Unit
Test
necessary
(Not
for
Class
C
Soeware
A
NA
NA
• Complexity
–
root
cause
for
many
defects
–
but
low
complexity
code
may
also
require
less
tesQng.
• In
source
code
use
complexity
metrics
to
adjust
the
QA
acQviQes
• Note:
Complexity
metrics
also
part
of
the
code
standard
22. 07/03/14
22
ProacQve
QA
ProacQve
QA
• Uses
same
approach
as
for
Medical
Device
Safety
Risk
Management
(IEC
14971,
IEC
80002).
• IdenQfy
most
criQcal
SW
hazards
and
their
causes,
e.g.:
– Loss
of
configuraQon
could
make
the
SW/Device
useless
– Faulty
data
could
result
in
fault
funcQonality
and/or
results
– Never-‐ending
waiQng
loops
could
could
make
the
SW/
Device
slow
or
useless
• Implement
proper
miQgaQons
in
the
design
23. 07/03/14
23
Examples
Example
–
Keyboard
in
ATM
Keyboard
Dispenser
Display
Card
Reader
Ext
Keyboard
XFS
drv
XFS
drv
XFS
drv
XFS
Win
XP
Bank
App
PC
ATM
Master-‐key
derived-‐key
derived-‐key
derived-‐key
derived-‐key
• <1%
source
code
doing
keyboard
funcQonality
• Remaining
related
to:
• Security:
crypt,
key-‐
handling,
surveillance
• Service:
ConfiguraQon,
status
log
etc.
Reliability
wise
–
key
handling
is
very
important
• Without
the
Master
key
the
keyboard
needs
to
back
to
the
manufacturer
• Without
derived
keys
the
keyboard
needs
a
service
tech.
visit
24. 07/03/14
24
Risk
Based
QA
for
ATM
keyboard
• “Spontaneous”
loss
of
keys
in
the
field
• Risk
based
approach:
New
file
system
with
– CRC
Error
correcQon
– “Black
box
recorder”
(log
of
field
events
for
debugging)
– More
rigor
of
requirements
and
design
– Unit
tesQng
of
the
new
file
system
Risk
Based
QA
for
ATM
keyboard
• In
the
pilot
phase
-‐
several
incidences
where
keyboard
is
“completely
dead”
• In
certain
situaQons,
defects
in
both
the
CRC
Error
correcQon
and
“Black
box
recorder”
ends
up
in:
“logging
an
error
result
in
a
new
error…”
• Learnings:
– Adding
“miQgaQons”
in
soeware
increases
complexity
–
which
may
end
up
in
more
erroneous
SW
– Remember
integraQon
and
scenario
tesQng
– Consider
some
kind
of
recovery
mechanism
25. 07/03/14
25
Example
ProacQve
QA
for
VHF
radio
• VHF
Radio
stores
“vital”
data
in
EEPROM.
• During
SW
test
a
HW
design
flaw
is
found.
HW
do
not
give
“Power
Down”
in
Qme
=>
“vital”
data
is
corrupted
=>
VHF
Radio
is
useless.
• ProacQve
QA:
– CRC
protecQon
of
data
– Shadowing
of
data
– Controlled
Scheme
for
data
update
– The
approach
also
miQgates
SW
failures
Bafery
monitor
in
Medical
Device
• A
Bafery
powered
Medical
Device
have
a
bafery
monitor
to
inform
when
charging
is
needed
• ProacQve
QA
– Bafery
power
is
(also)
displayed
in
number
of
measurements
lee
– If
number
of
measurements
lee
<=
2
then
measurements
is
not
possible
– When
number
of
measurements
lee
<=2
then
it
is
always
decreased
with
1
independently
of
bafery
status
– Monitoring
algorithm
adapts
when
bafery
degrades
26. 07/03/14
26
ICU
Monitor
in
Demo
mode
• ICU
Monitor
have
a
demo
mode
to
show
realisQc
waveforms
in
sales
situaQon.
• Erroneously
a
ICU
Monitor
jumped
into
Demo
mode
during
monitoring
of
real
paQent
• ProacQve
QA
– Changing
waveform
to
non
realisQc
waveforms
– WriQng
“Demo”
where
waveforms
are
displayed
– Timeout
on
Demo
mode
–
jumping
back
to
real
mode
aeer
a
period
of
in-‐acQvity
PiZalls
27. 07/03/14
27
PiZalls
• Too
much
are
considered
criQcal
or
too
much
are
considered
not-‐criQcal
– Risk
of
not
finding
the
criQcal
defects
• Customer
and
Manufacturer
have
different
view
of
what
is
criQcal
– Risk
of
un-‐saQsfied
customer
• Management
only
buys
the
cost
reducQon
part
of
risk
based
QA
– Risk
of
poor
quality
PiZalls
• No
use
of
historical
data
–
also
within
the
project
– If
defect
trends
shows
different
than
your
risk
evaluaQon
(e.g.
un-‐idenQfied
criQcal
defects)
then
you
should
adapt
your
Risk
Based
Approach.
• Design
miQgaQons
adds
too
much
complexity
– resulQng
in
other
defects,
difficult
to
maintain
SW
• The
“system”
to
handle
Risk
Based
QA
are
too
complex.