The document provides proprietary information for a presentation by Joseph Ours of Centric Consulting on metric-driven test management. It notifies that the material contains trade secrets and confidential information solely owned by Centric Consulting and is for the client's internal use only. Questions about Centric's software quality assurance and testing services can be directed to Joseph Ours via email or phone.
This document discusses a new approach to defect triage that focuses on prioritizing defects based on their severity and impact. It introduces a priority system with four levels - fix now, fix this sprint, fix this release, and product backlog. For each priority level, it provides criteria for assignment, such as whether the app is dying or a defect is critical to functionality. The goal is to make timely disposition decisions to either have the team fix defects or add them to the backlog. Benefits include more effective prioritization of testing and development work.
CoverMyQuality: Implementing a Quality Program by Rick Neighbarger and Susan ...QA or the Highway
Follow the Quality Assurance journey taken by CoverMyMeds as it transitioned from a start-up to a growth company. Founded in 2008 with a mission to help patients get the medication they need to be healthy, CoverMyMeds has doubled its staff and revenue every year since inception. As the company expands, quality processes have become paramount in protecting Patient Health Information (PHI) and mitigating risk. Implementing Juran’s concept of Big Q, CoverMyMeds has begun its journey in creating its own quality center of excellence.
Test beyond the obvious- Root Cause AnalysisPractiTest
Kevin Wilkes - Senior Test Consultant at QualiTest and Richard Morgan - UK Delivery Manager at QualiTest, Co-present "Test beyond the obvious- Root Cause Analysis" at OnlineTestConf.com
Testing fundamentals in a changing worldPractiTest
This document discusses testing fundamentals in an agile environment. It emphasizes that testing is a team responsibility and should be integrated throughout the development process, with automated and non-functional testing. Frequent testing and integration is needed to provide early feedback and reduce dependencies. Documentation needs are reduced as testing shifts from a separate phase to being embedded in development.
The Risk Questionnaire - by: Adam KnightPractiTest
This document discusses developing a test strategy based on understanding risk perception. It conducted a risk questionnaire that showed differing views of acceptable risk levels. This identified a need for greater testing rigor than currently applied. The strategy established clear development, product owner and testing responsibilities. It positioned testing as a consultancy to the business to provide expertise needed based on the risk appetite identified.
The document discusses moving from a defect reporting approach in software testing to a defect prevention approach using lean principles. It notes that preventing defects from the beginning is far more effective than finding faults later. It asks questions about the current state of testing and defect handling to determine opportunities to focus more on prevention activities like exploratory testing earlier and removing the root causes of defects.
This document discusses a new approach to defect triage that focuses on prioritizing defects based on their severity and impact. It introduces a priority system with four levels - fix now, fix this sprint, fix this release, and product backlog. For each priority level, it provides criteria for assignment, such as whether the app is dying or a defect is critical to functionality. The goal is to make timely disposition decisions to either have the team fix defects or add them to the backlog. Benefits include more effective prioritization of testing and development work.
CoverMyQuality: Implementing a Quality Program by Rick Neighbarger and Susan ...QA or the Highway
Follow the Quality Assurance journey taken by CoverMyMeds as it transitioned from a start-up to a growth company. Founded in 2008 with a mission to help patients get the medication they need to be healthy, CoverMyMeds has doubled its staff and revenue every year since inception. As the company expands, quality processes have become paramount in protecting Patient Health Information (PHI) and mitigating risk. Implementing Juran’s concept of Big Q, CoverMyMeds has begun its journey in creating its own quality center of excellence.
Test beyond the obvious- Root Cause AnalysisPractiTest
Kevin Wilkes - Senior Test Consultant at QualiTest and Richard Morgan - UK Delivery Manager at QualiTest, Co-present "Test beyond the obvious- Root Cause Analysis" at OnlineTestConf.com
Testing fundamentals in a changing worldPractiTest
This document discusses testing fundamentals in an agile environment. It emphasizes that testing is a team responsibility and should be integrated throughout the development process, with automated and non-functional testing. Frequent testing and integration is needed to provide early feedback and reduce dependencies. Documentation needs are reduced as testing shifts from a separate phase to being embedded in development.
The Risk Questionnaire - by: Adam KnightPractiTest
This document discusses developing a test strategy based on understanding risk perception. It conducted a risk questionnaire that showed differing views of acceptable risk levels. This identified a need for greater testing rigor than currently applied. The strategy established clear development, product owner and testing responsibilities. It positioned testing as a consultancy to the business to provide expertise needed based on the risk appetite identified.
The document discusses moving from a defect reporting approach in software testing to a defect prevention approach using lean principles. It notes that preventing defects from the beginning is far more effective than finding faults later. It asks questions about the current state of testing and defect handling to determine opportunities to focus more on prevention activities like exploratory testing earlier and removing the root causes of defects.
S.M.A.R.T & F.O.C.U.S Testing - Increasing the value provided by your testing...PractiTest
1. The document discusses how testing teams can increase the perceived value of their work by better understanding how their work is perceived by others and communicating the right information to stakeholders.
2. It identifies that issues with perception of value come from not providing the value stakeholders need and not effectively communicating the value brought to projects.
3. The document provides recommendations for testing teams to focus on communicating information to stakeholders through things like information schedules, alternative reporting methods, and ensuring communication is smart, fast, objective, condensed, user-centered and serves the customer.
This document discusses challenges and best practices for CAPA (corrective and preventative action) programs. It outlines common pitfalls such as implementing actions that don't address the root cause, focusing on timelines over deliverables, and overusing "operator error" as a root cause. Best practices include using a multidisciplinary team approach, evaluating trends, and identifying all relevant inputs to the CAPA process. Effectiveness is best measured by metrics like recurrence rates and timeliness rather than just pass rates of proof of effectiveness. The document provides guidance on how to conduct a robust CAPA process.
CAPA - Corrective and Preventive Action Management TrainingTonex
"CAPA Management training covers the rationale, concepts, tools, techniques, and practices of RCA and Corrective and Preventive Action (CAPA) management in FDA field".
TONEX RCA and CAPA Management Training Format
The course is fun and dynamic
The training is a blend of hypothesis and practice
The hypothetical area is conveyed as intuitive introduction
The reasonable area incorporates practicing with genuine precedents, singular/bunch exercises, and hands-on workshops
Learn About:
CAPA application and implementation
CAPA management
FDA’s requirements for CAPA systems
Importance of CAPA systems
CAPA system main components
The definition and differences of the terms corrections, corrective actions, and preventive actions
CAPA data sources
Methods of data analysis
CAPA data flow charts
CAPA tracking tools
Medical device reporting and tracking
FDA guidance for failure investigations and root cause analyses
FDA’s trending principals / ECI
Non-conformances or deviations
RCA tools and methods
Brainstorming methods
Problem solving tools
Process mapping / Regulatory resources
Corrective action plan development steps
Defining the problem statement properly
Isolating and containing the problems
Identifying the root cause
Developing an effective corrective action
Executing and validating the corrective action
Preventing recurrence
Preventive Action process
Communication
Course Outline
Overview of CAPA
RCA Definition
Non-Conformances or Deviations
Nonconformance Classification
Problem Solving Process
Creative Thinking Approaches
FMEA Application in Clinical Devices
Analysis and Prioritization Techniques
Digging Down for the Root Causes
Gathering Valuable Data for RCA and CAPA
Analyzing Data
Accidents Analysis and Role of Human Error
Role of Management Behaviors in the Success of RCA/CAPA
Implementing Corrective and Preventive Action Plans (CAPA)
Elements of Effective CAPA
Trending Requirements and CAPA
CAPA Regulatory Requirements
Call us today at +1-972-665-9786. Learn more about this course audience, objectives, outlines, seminars, pricing , any other information. Visit our website link below.
CAPA (Corrective and Preventive Action) Management Training
https://www.tonex.com/training-courses/capa-management-training/
Effective CAPA Implementation in a Management System - Praneet SurtiPraneet Surti
The document discusses the Corrective Action and Preventive Action (CAPA) process. It defines CAPA as a structured way to investigate non-conformities, determine appropriate corrections and actions, and measure their effectiveness. It outlines the key steps in the CAPA process including defining the problem, investigating the root cause, determining corrective and preventive actions, implementing solutions, and measuring effectiveness. The document emphasizes that the goal of CAPA is to eliminate causes of issues in order to prevent recurrence and notes that a mature CAPA system can help continuously improve products, services, and compliance.
The document discusses corrective and preventive actions (CAPA) for recurring problems. It explains that CAPA is a structured process required by ISO 9001 to investigate nonconformities, determine appropriate corrections and actions, and measure effectiveness. The CAPA process involves defining the problem, investigating the root cause, developing solutions, verifying the solutions address the root cause, and checking effectiveness. Root cause analysis tools discussed include 5 whys, cause-and-effect diagrams, IS/IS NOT analysis, and the 8D (eight disciplines) approach. The document emphasizes finding facts over fault to properly solve problems.
Risk-based testing is a commonly-performed technique for prioritizing tests that must be performed in a short time frame. However, this technique isn't perfect and has some risks in itself. This presentation lists 13 ways a tester can be "fooled by risk."
ABOUT THE TRAINING PROGRAM :-
Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to address, correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is more probable that problem recurrence will be prevented.
DESIGNED FOR :-
Managers, Engineers, Supervisor and officers engaged in maintenance operation and engineering activities.
OBJECTIVE :-
At the end of the training program, participants will be able
- To gain a basic understanding of the problem solving and decision-making process and the applicable quality tools that support this process.
- To develop specific competencies to use the structured approach to problem solving and decision making and the supporting quality tools.
TRAINING PROGRAM COVERAGE :-
- Basic knowledge about RCA program.
- What are the RCA tools ?
- More about Why- Why analysis ?
- Videos and case studies on RCA
A good tester uses communication not only to 'let others know', but also to get the information they need. An even greater tester knows how to use communication as part of their actual testing, to focus their process and achieve better results.
In this Webinar we will go over all the advanced aspects of communication and how to leverage them as part of your testing:
- The communication process in testing - a 360 Degree view.
- How to leverage communication as an ongoing part of your process.
- Tips and tricks on how to communicate effectively with your project stakeholders.
This document discusses IBM's approach to advanced defect management. It introduces two of IBM's analytical predictive capabilities: the IBM Defect Reduction Method, which classifies and analyzes defects to find and fix them early, and the Test Planning and Optimization Workbench, which delivers an optimized test strategy and project planning through defect predictions. Using these capabilities, IBM has achieved substantial gains for clients such as reduced costs, accelerated schedules, improved quality, and lower risks. The document provides examples of how IBM has helped validate testing estimates and select accelerators for clients to reduce production defects.
Root Cause Analysis (RCA) is a process to understand the underlying causes of problems in order to prevent future issues. It involves asking "Why?" repeatedly to determine the root cause, typically requiring around 5 iterations. RCA principles include making it continuous, focusing on prevention over blame, and always searching for the root cause rather than stopping at surface explanations. Common leakage reasons for defects include requirements ambiguity, insufficient testing, and outdated test coverage. RCA stats can be used to measure quality and determine where to focus process improvements.
The RCCA PPT is an excellent training tool to implement into your functional group or business.
It basically forces you to peel the onion on a failure as far back until you’ve reached the root cause whereas in some cases it could be several.
It incorporates the 5 whys and the problem solving technique.
This Template is created for helping the quality or continuous improvement professionals to generate a step by step problem solving report, which include the guidance on each steps in a 8D process, also include the templates of popular quality tools such as 5-Why and Fishbone Diagram.
想学习六西格玛?可以看看ucourse.org的网上课程。
http://ucourse.org/ssgb
Operating Excellence is built on Corrective & Preventive ActionsAtanu Dhar
This document provides an overview of Corrective Action Preventive Action (CAPA) and how to implement an effective CAPA process. It defines CAPA and explains the difference between corrective and preventative actions. It outlines the benefits of a mature CAPA system, including increased quality, reduced costs from problems, and improved customer satisfaction. The document then discusses various tools that can be used in the CAPA process, including root cause analysis techniques like 5 Whys, fishbone diagrams, and Pareto charts to identify causes and prioritize actions. Examples are provided for how to apply these tools to analyze specific business processes.
- Risk based testing (RBT) is an approach that uses product risks to guide the testing process and reduce risks. It involves identifying product risks, analyzing their likelihood and impact, and using risk levels to prioritize test design and execution.
- Implementing RBT involves 10 steps: selecting RBT, identifying stakeholders, identifying risks, extending risk identification, rating impact, rating likelihood, creating a risk matrix, selecting test approaches and techniques, designing test cases with traceability to risks, and risk-based reporting and defect correction.
Practical Application Of Risk Based Testing MethodsReuben Korngold
This document summarizes the experience of National Australia Bank implementing a risk-based testing methodology. The methodology provides a formalized approach to evaluating requirement risks and using those risks to plan testing efforts. It involves workshops to determine likelihood and impact of failures for each requirement. This information is then used to prioritize testing order and guide the scope of testing, focusing on high-risk areas first. The methodology aims to find important problems quickly while reducing low-value testing and justifying testing costs and efforts to stakeholders based on business and technology risks.
CAPA (Corrective and Preventive Action) Management : Tonex TrainingBryan Len
CAPA Management training covers the rationale, concepts, tools, techniques, and practices of RCA and Corrective and Preventive Action (CAPA) management in FDA field. Root Cause Analysis (RCA) and Corrective and Preventive Action (CAPA) Management training course teaches you to develop an effective RCA investigation, and develop a corrective and preventive action plan suitable for the identified problems.
Learn About:
CAPA application and implementation
CAPA management
FDA’s requirements for CAPA systems
Importance of CAPA systems
CAPA system main components
CAPA data sources, Methods of data analysis
CAPA data flow charts, CAPA tracking tools
Medical device reporting and tracking
FDA guidance for failure investigations and root cause analyses
FDA’s trending principals, ECI
Non-conformances or deviations
RCA tools and methods, Brainstorming methods
More...
TONEX RCA and CAPA Management Training Format:
The course is fun and dynamic
The training is a combination of theory and practice
The theoretical section is delivered in the form of interactive presentation
The practical section includes exercising with real-world examples, individual/group activities, and hands-on workshops
Audience:
CAPA Management is a 4-day course designed for:
CRAs
Project Managers/CRA Managers
Principal Investigators
Site Research Directors/Managers
Clinical Research Coordinators
QA/QC staff
GMP personnel
All individuals who are involved in investigations in a pharmaceutical, clinical manufacturing, biologics and medical device environment.
Training Objectives:
CAPA Management training course, the attendees are able to:
Describe what RCA and CAPA are
Identify the non-compliance, Define the investigator
Discuss performance management concepts
Know the purpose of Corrective and Preventive Action
Improve their RCA and CAPA executive skills for effective site risk management
Understand the requirements in 21 CFR 820 Quality
System Regulation
Foster prevention actions
More...
Course Outline:
Overview of CAPA
RCA Definition
Non-Conformances or Deviations
Nonconformance Classification
Problem Solving Process
Creative Thinking Approaches
FMEA Application in Clinical Devices
Analysis and Prioritization Techniques
Digging Down for the Root Causes
Gathering Valuable Data for RCA and CAPA
Analyzing Data
Accidents Analysis and Role of Human Error
Role of Management Behaviors in the Success of RCA/CAPA
Implementing Corrective and Preventive Action Plans (CAPA)
Elements of Effective CAPA
Trending Requirements and CAPA
CAPA Regulatory Requirements
TONEX RCA and CAPA Hands-On Workshop Sample
Learn more. Request more information. Visit Tonex training website link below. Ask for anything related to CAPA (Corrective and Preventive Action) Management Training.
CAPA (Corrective and Preventive Action) Management Training
https://www.tonex.com/training-courses/capa-management-training/
The document provides training on the Global 8D (G8D) problem solving approach. G8D is an 8-step systematic approach developed by Ford Motors to solve problems. The 8 steps are: (1) plan to solve the problem, (2) make a team, (3) define the problem, (4) contain the problem, (5) determine the root cause and escape points, (6) verify corrective actions, (7) implement corrective actions, and (8) monitor effectiveness of the actions. The training covers the goals and tools to use at each step of the G8D process, including root cause analysis tools like fishbone diagrams, 5 whys, scatter plots, and control
A 15-minutes oral presentation that was given in ISQua's 32nd International Conference, Doha, October 2015 by Dr. Yasser Amer under the track: "Quality and Safety in Developing Countries"
The document discusses elements of an effective Corrective and Preventive Action (CAPA) process. It outlines key aspects such as having a documented procedure, risk assessment, investigation techniques, defined action plans, effectiveness checks, and management review. The goals of a CAPA process are to determine the root cause of problems, implement corrective actions to address the cause, and verify that the actions were effective in preventing recurrence. An effective CAPA system relies on analyzing various quality data sources, taking actions to continuously improve products and processes, and demonstrating the ability to meet business and compliance needs over time.
Quality Assurance & User Experience: Friends or Foes? by Richard DouglassQA or the Highway
Is it possible for User Experience (UX) and Quality Assurance (QA) professionals to work well together? At times, both can struggle to effectively communicate what they need in order to do their jobs well. However, opportunities exist for the two to work well together. For example, QA professionals often struggle to obtain quality requirements in order to write effective test cases. Whereas, UX professionals typically struggle when after they do their work early in the project they often hand off their work only to find it mangled in the final stages of the project when they are no longer involved.Yet, great things are possible when UX and QA teams work together. The UX professionals can ensure that requirements are well written early in the project when they are heavily involved in the project. In addition, QA professionals can be very helpful by making sure UX team members are invited to review the final product before it goes live and are part of the final reviews.
Cucumber is a popular tool that is commonly used for writing and running functional tests that can drive the BDD (Behavior Driven Development) process on a project development team. Just as commonly, what started as a nice little garden of cukes can become overgrown and difficult to manage as a project’s life advances. This talk will cover several useful tools that can help you keep your Cucumber suites in shape.
S.M.A.R.T & F.O.C.U.S Testing - Increasing the value provided by your testing...PractiTest
1. The document discusses how testing teams can increase the perceived value of their work by better understanding how their work is perceived by others and communicating the right information to stakeholders.
2. It identifies that issues with perception of value come from not providing the value stakeholders need and not effectively communicating the value brought to projects.
3. The document provides recommendations for testing teams to focus on communicating information to stakeholders through things like information schedules, alternative reporting methods, and ensuring communication is smart, fast, objective, condensed, user-centered and serves the customer.
This document discusses challenges and best practices for CAPA (corrective and preventative action) programs. It outlines common pitfalls such as implementing actions that don't address the root cause, focusing on timelines over deliverables, and overusing "operator error" as a root cause. Best practices include using a multidisciplinary team approach, evaluating trends, and identifying all relevant inputs to the CAPA process. Effectiveness is best measured by metrics like recurrence rates and timeliness rather than just pass rates of proof of effectiveness. The document provides guidance on how to conduct a robust CAPA process.
CAPA - Corrective and Preventive Action Management TrainingTonex
"CAPA Management training covers the rationale, concepts, tools, techniques, and practices of RCA and Corrective and Preventive Action (CAPA) management in FDA field".
TONEX RCA and CAPA Management Training Format
The course is fun and dynamic
The training is a blend of hypothesis and practice
The hypothetical area is conveyed as intuitive introduction
The reasonable area incorporates practicing with genuine precedents, singular/bunch exercises, and hands-on workshops
Learn About:
CAPA application and implementation
CAPA management
FDA’s requirements for CAPA systems
Importance of CAPA systems
CAPA system main components
The definition and differences of the terms corrections, corrective actions, and preventive actions
CAPA data sources
Methods of data analysis
CAPA data flow charts
CAPA tracking tools
Medical device reporting and tracking
FDA guidance for failure investigations and root cause analyses
FDA’s trending principals / ECI
Non-conformances or deviations
RCA tools and methods
Brainstorming methods
Problem solving tools
Process mapping / Regulatory resources
Corrective action plan development steps
Defining the problem statement properly
Isolating and containing the problems
Identifying the root cause
Developing an effective corrective action
Executing and validating the corrective action
Preventing recurrence
Preventive Action process
Communication
Course Outline
Overview of CAPA
RCA Definition
Non-Conformances or Deviations
Nonconformance Classification
Problem Solving Process
Creative Thinking Approaches
FMEA Application in Clinical Devices
Analysis and Prioritization Techniques
Digging Down for the Root Causes
Gathering Valuable Data for RCA and CAPA
Analyzing Data
Accidents Analysis and Role of Human Error
Role of Management Behaviors in the Success of RCA/CAPA
Implementing Corrective and Preventive Action Plans (CAPA)
Elements of Effective CAPA
Trending Requirements and CAPA
CAPA Regulatory Requirements
Call us today at +1-972-665-9786. Learn more about this course audience, objectives, outlines, seminars, pricing , any other information. Visit our website link below.
CAPA (Corrective and Preventive Action) Management Training
https://www.tonex.com/training-courses/capa-management-training/
Effective CAPA Implementation in a Management System - Praneet SurtiPraneet Surti
The document discusses the Corrective Action and Preventive Action (CAPA) process. It defines CAPA as a structured way to investigate non-conformities, determine appropriate corrections and actions, and measure their effectiveness. It outlines the key steps in the CAPA process including defining the problem, investigating the root cause, determining corrective and preventive actions, implementing solutions, and measuring effectiveness. The document emphasizes that the goal of CAPA is to eliminate causes of issues in order to prevent recurrence and notes that a mature CAPA system can help continuously improve products, services, and compliance.
The document discusses corrective and preventive actions (CAPA) for recurring problems. It explains that CAPA is a structured process required by ISO 9001 to investigate nonconformities, determine appropriate corrections and actions, and measure effectiveness. The CAPA process involves defining the problem, investigating the root cause, developing solutions, verifying the solutions address the root cause, and checking effectiveness. Root cause analysis tools discussed include 5 whys, cause-and-effect diagrams, IS/IS NOT analysis, and the 8D (eight disciplines) approach. The document emphasizes finding facts over fault to properly solve problems.
Risk-based testing is a commonly-performed technique for prioritizing tests that must be performed in a short time frame. However, this technique isn't perfect and has some risks in itself. This presentation lists 13 ways a tester can be "fooled by risk."
ABOUT THE TRAINING PROGRAM :-
Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to address, correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is more probable that problem recurrence will be prevented.
DESIGNED FOR :-
Managers, Engineers, Supervisor and officers engaged in maintenance operation and engineering activities.
OBJECTIVE :-
At the end of the training program, participants will be able
- To gain a basic understanding of the problem solving and decision-making process and the applicable quality tools that support this process.
- To develop specific competencies to use the structured approach to problem solving and decision making and the supporting quality tools.
TRAINING PROGRAM COVERAGE :-
- Basic knowledge about RCA program.
- What are the RCA tools ?
- More about Why- Why analysis ?
- Videos and case studies on RCA
A good tester uses communication not only to 'let others know', but also to get the information they need. An even greater tester knows how to use communication as part of their actual testing, to focus their process and achieve better results.
In this Webinar we will go over all the advanced aspects of communication and how to leverage them as part of your testing:
- The communication process in testing - a 360 Degree view.
- How to leverage communication as an ongoing part of your process.
- Tips and tricks on how to communicate effectively with your project stakeholders.
This document discusses IBM's approach to advanced defect management. It introduces two of IBM's analytical predictive capabilities: the IBM Defect Reduction Method, which classifies and analyzes defects to find and fix them early, and the Test Planning and Optimization Workbench, which delivers an optimized test strategy and project planning through defect predictions. Using these capabilities, IBM has achieved substantial gains for clients such as reduced costs, accelerated schedules, improved quality, and lower risks. The document provides examples of how IBM has helped validate testing estimates and select accelerators for clients to reduce production defects.
Root Cause Analysis (RCA) is a process to understand the underlying causes of problems in order to prevent future issues. It involves asking "Why?" repeatedly to determine the root cause, typically requiring around 5 iterations. RCA principles include making it continuous, focusing on prevention over blame, and always searching for the root cause rather than stopping at surface explanations. Common leakage reasons for defects include requirements ambiguity, insufficient testing, and outdated test coverage. RCA stats can be used to measure quality and determine where to focus process improvements.
The RCCA PPT is an excellent training tool to implement into your functional group or business.
It basically forces you to peel the onion on a failure as far back until you’ve reached the root cause whereas in some cases it could be several.
It incorporates the 5 whys and the problem solving technique.
This Template is created for helping the quality or continuous improvement professionals to generate a step by step problem solving report, which include the guidance on each steps in a 8D process, also include the templates of popular quality tools such as 5-Why and Fishbone Diagram.
想学习六西格玛?可以看看ucourse.org的网上课程。
http://ucourse.org/ssgb
Operating Excellence is built on Corrective & Preventive ActionsAtanu Dhar
This document provides an overview of Corrective Action Preventive Action (CAPA) and how to implement an effective CAPA process. It defines CAPA and explains the difference between corrective and preventative actions. It outlines the benefits of a mature CAPA system, including increased quality, reduced costs from problems, and improved customer satisfaction. The document then discusses various tools that can be used in the CAPA process, including root cause analysis techniques like 5 Whys, fishbone diagrams, and Pareto charts to identify causes and prioritize actions. Examples are provided for how to apply these tools to analyze specific business processes.
- Risk based testing (RBT) is an approach that uses product risks to guide the testing process and reduce risks. It involves identifying product risks, analyzing their likelihood and impact, and using risk levels to prioritize test design and execution.
- Implementing RBT involves 10 steps: selecting RBT, identifying stakeholders, identifying risks, extending risk identification, rating impact, rating likelihood, creating a risk matrix, selecting test approaches and techniques, designing test cases with traceability to risks, and risk-based reporting and defect correction.
Practical Application Of Risk Based Testing MethodsReuben Korngold
This document summarizes the experience of National Australia Bank implementing a risk-based testing methodology. The methodology provides a formalized approach to evaluating requirement risks and using those risks to plan testing efforts. It involves workshops to determine likelihood and impact of failures for each requirement. This information is then used to prioritize testing order and guide the scope of testing, focusing on high-risk areas first. The methodology aims to find important problems quickly while reducing low-value testing and justifying testing costs and efforts to stakeholders based on business and technology risks.
CAPA (Corrective and Preventive Action) Management : Tonex TrainingBryan Len
CAPA Management training covers the rationale, concepts, tools, techniques, and practices of RCA and Corrective and Preventive Action (CAPA) management in FDA field. Root Cause Analysis (RCA) and Corrective and Preventive Action (CAPA) Management training course teaches you to develop an effective RCA investigation, and develop a corrective and preventive action plan suitable for the identified problems.
Learn About:
CAPA application and implementation
CAPA management
FDA’s requirements for CAPA systems
Importance of CAPA systems
CAPA system main components
CAPA data sources, Methods of data analysis
CAPA data flow charts, CAPA tracking tools
Medical device reporting and tracking
FDA guidance for failure investigations and root cause analyses
FDA’s trending principals, ECI
Non-conformances or deviations
RCA tools and methods, Brainstorming methods
More...
TONEX RCA and CAPA Management Training Format:
The course is fun and dynamic
The training is a combination of theory and practice
The theoretical section is delivered in the form of interactive presentation
The practical section includes exercising with real-world examples, individual/group activities, and hands-on workshops
Audience:
CAPA Management is a 4-day course designed for:
CRAs
Project Managers/CRA Managers
Principal Investigators
Site Research Directors/Managers
Clinical Research Coordinators
QA/QC staff
GMP personnel
All individuals who are involved in investigations in a pharmaceutical, clinical manufacturing, biologics and medical device environment.
Training Objectives:
CAPA Management training course, the attendees are able to:
Describe what RCA and CAPA are
Identify the non-compliance, Define the investigator
Discuss performance management concepts
Know the purpose of Corrective and Preventive Action
Improve their RCA and CAPA executive skills for effective site risk management
Understand the requirements in 21 CFR 820 Quality
System Regulation
Foster prevention actions
More...
Course Outline:
Overview of CAPA
RCA Definition
Non-Conformances or Deviations
Nonconformance Classification
Problem Solving Process
Creative Thinking Approaches
FMEA Application in Clinical Devices
Analysis and Prioritization Techniques
Digging Down for the Root Causes
Gathering Valuable Data for RCA and CAPA
Analyzing Data
Accidents Analysis and Role of Human Error
Role of Management Behaviors in the Success of RCA/CAPA
Implementing Corrective and Preventive Action Plans (CAPA)
Elements of Effective CAPA
Trending Requirements and CAPA
CAPA Regulatory Requirements
TONEX RCA and CAPA Hands-On Workshop Sample
Learn more. Request more information. Visit Tonex training website link below. Ask for anything related to CAPA (Corrective and Preventive Action) Management Training.
CAPA (Corrective and Preventive Action) Management Training
https://www.tonex.com/training-courses/capa-management-training/
The document provides training on the Global 8D (G8D) problem solving approach. G8D is an 8-step systematic approach developed by Ford Motors to solve problems. The 8 steps are: (1) plan to solve the problem, (2) make a team, (3) define the problem, (4) contain the problem, (5) determine the root cause and escape points, (6) verify corrective actions, (7) implement corrective actions, and (8) monitor effectiveness of the actions. The training covers the goals and tools to use at each step of the G8D process, including root cause analysis tools like fishbone diagrams, 5 whys, scatter plots, and control
A 15-minutes oral presentation that was given in ISQua's 32nd International Conference, Doha, October 2015 by Dr. Yasser Amer under the track: "Quality and Safety in Developing Countries"
The document discusses elements of an effective Corrective and Preventive Action (CAPA) process. It outlines key aspects such as having a documented procedure, risk assessment, investigation techniques, defined action plans, effectiveness checks, and management review. The goals of a CAPA process are to determine the root cause of problems, implement corrective actions to address the cause, and verify that the actions were effective in preventing recurrence. An effective CAPA system relies on analyzing various quality data sources, taking actions to continuously improve products and processes, and demonstrating the ability to meet business and compliance needs over time.
Quality Assurance & User Experience: Friends or Foes? by Richard DouglassQA or the Highway
Is it possible for User Experience (UX) and Quality Assurance (QA) professionals to work well together? At times, both can struggle to effectively communicate what they need in order to do their jobs well. However, opportunities exist for the two to work well together. For example, QA professionals often struggle to obtain quality requirements in order to write effective test cases. Whereas, UX professionals typically struggle when after they do their work early in the project they often hand off their work only to find it mangled in the final stages of the project when they are no longer involved.Yet, great things are possible when UX and QA teams work together. The UX professionals can ensure that requirements are well written early in the project when they are heavily involved in the project. In addition, QA professionals can be very helpful by making sure UX team members are invited to review the final product before it goes live and are part of the final reviews.
Cucumber is a popular tool that is commonly used for writing and running functional tests that can drive the BDD (Behavior Driven Development) process on a project development team. Just as commonly, what started as a nice little garden of cukes can become overgrown and difficult to manage as a project’s life advances. This talk will cover several useful tools that can help you keep your Cucumber suites in shape.
At some point, some people decided to give “error”, “defect” and “bug” slightly different meanings for a slightly more detailed context. For some time now, some folks have been trying to do the same with “testing” and “checking”. Let me attempt to share that point of view and together, let’s see if our perspective changes...
Improving Test Team Throughput via Architecture by Dustin WilliamsQA or the Highway
A lot of modern testing teams are built from people with some automation experience, developers, and people who think code is something used to open a safe. These diverse backgrounds bring a diverse set of ideas, but don’t always find optimal division of work. With some fairly small changes in automated test design, we can leverage the best skills of all team members to not only improve throughput, but to end up with a better overall product. These design principles help isolate truly challenging code problems and help separate the concerns of test structure and test execution. If your team has ever said (with sad faces) “We’re still automating that”, then come discover how tomorrow you can exclaim “That’s Done!”
“Automate everything you can.” This DevOps principle propels automated testing into a primary enabling position for any organization that embarks on a DevOps journey. No longer an option. No longer something we *should* do. Either we automate testing or the bright promise of DevOps will remain out of reach.
In this session, we will examine the multiple ways that automated testing is the lynchpin that enables the flow of software through the DevOps pipeline. And we will see how it changes – but does not eliminate – manual testing. (After all, “everything you can” is not everything.)
Testing within a closed system is easy. Everything is generally accessible and can be interacted with freely. But what happens when the application requires integration with one or more third parties in order to function? In unit tests, we can use mocks and there are many Ruby libraries to make that happen. However, this doesn’t help us much when we’re testing deployed code in end-to-end scenarios or exploratory tests. The solution I found was to build a mock application to mimic the third party. This talk will cover the process and tools used to build the application, the advantages/disadvantages it provides, and explain how this mock is utilized in real-world situations.
Anton Muzhailo - Practical Test Process Improvement using ISTQBIevgenii Katsan
Here are a few potential questions from the document:
- What is the true value of ISTQB certifications beyond just checking a box for management? How can the knowledge be applied practically?
- How can metrics be designed and used effectively to assess quality and test coverage in an agile environment? What are some examples of valid and invalid metrics?
- What artifacts or information are useful to include in a test plan even for agile teams using tools like JIRA? How can a test plan provide value beyond just additional paperwork?
- What techniques can be used to effectively estimate defect severity when multiple testers with different perspectives are involved? How can consistency be achieved?
- How can root cause analysis be applied
20220621 Project Management Innovation Conference Harrisburg PA Seatbelts and...Craeg Strong
Organizations large and small use application lifecycle management tools like Jira, Azure DevOps, VersionOne, Rational Team Concert, and others to manage their Agile products and programs
Every day in large organizations, ALM data is used to make forecasts and key decisions about budgeting, staffing, and risk management. Organizations increasingly rely on ALM tools to generate alerts to proactively warn about variances, risks, and shortfalls. Unfortunately, due to late, inaccurate, and incomplete data entry, ALM tools often end up emitting a large volume of false positives, while the real risks remain hidden.
We would like to propose a new approach that automates governance for ALM tools, leveraging the same proven approach used by linting tools like FxCop, stylecop, eslint, pylint and pmd. Rather than expecting perfection, let's provide some guides and seatbelts to enable mere mortals to use alm tools successfully!
Gerlof Hoekstra - OMG What Have We Done - EuroSTAR 2013TEST Huddle
EuroSTAR Software Testing Conference 2013 presentation on "OMG What Have We Done" by Gerlof Hoekstra.
See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Recorded webinar: http://slidesha.re/1tGIZaH
Subscribe: http://www.ksmartin.com/subscribe
Purchase the book: http://bit.ly/TOObk
Effective problem solving is not an innate skill that most people are born with.
Even for those few few lucky ones who are born with natural problem-solving talent, it is often drummed out of them by parents, teachers, and bosses. And those whose academic preparation would lead you to believe that they're highly skilled in this area (such as engineers and physicians) regularly fall prey to sloppy problem solving.
The good news is that effective problem solving is a skill that can be developed. Everyone can learn to solve problems effectively given the will and ample practice with a skilled coach/teacher.
This webinar focuses on the P (plan) phase of the PDSA/PDCA cycle (plan-do-study-adjust), which is the most difficult phase of scientific problem solving for people to master. Topics include:
• Setting a target condition
• Problem clarification
• Scoping and qualifying the problem
• Root cause analysis
Watch this lively discussion and learn the important first steps for closing the gap between where you are and where you'd like or need to be.
As preparation for the webinar, you may want to read the Discipline chapter in Karen's Shingo Award-winning book, The Outstanding Organization. www.ksmartin.com/TOO
This document provides an overview of Lean Six Sigma in 3 phases:
1) Pre-Define phase explains that Six Sigma helps improve quality and customer satisfaction while reducing costs, and Lean helps eliminate waste and improve efficiencies. Lean should be applied before Six Sigma to reduce waste before improving efficiency.
2) Define phase involves understanding customer wants, translating them into measurable requirements, identifying critical needs, and defining the project charter.
3) Measure phase focuses on validating measurement systems, collecting baseline data, understanding input variables, analyzing process stability, and calculating process capability.
Manual Testing real time questions .pdfTiktokIndia2
The document provides interview questions and answers related to manual testing. It is divided into 4 parts with a total of 27 questions. The questions cover topics such as the tester's role and responsibilities, software testing concepts like SDLC models, regression testing, quality assurance vs quality control, verification vs validation, and testing techniques like black box testing and white box testing. Sample scenarios are also provided to test applications like a login window, chair, mobile and a calculator.
If testers sit passively through agile planning, important testing activities will be missed or glossed over. Testing late in the sprint becomes a bottleneck, quickly diminishing the advantages of agile development. However, testers can actively advocate for customers’ concerns while helping the team implement robust solutions. Rob Sabourin shows how testers contribute to the estimation, task definition, clarification, and the scoping work required to implement user stories. Testers apply their elicitation skills to understand what users need, collecting great examples that explore typical, alternate, and error scenarios. Rob shares many examples of how agile stories can be broken into a variety of test-related tasks for implementing infrastructure, data, non-functional attributes, privacy, security, robustness, exploration, regression, and business rules. Rob shares his experiences helping transform agile testers from passive planning participants into dynamic advocates who address the product owner’s critical business concerns, the team’s limited resources, and the project’s technical risks.
This document discusses using a Kanban/Scrum mashup approach to execute fixed price projects. It proposes using Kanban boards to visualize work in progress, limiting work in progress, and tracking progress through burndown charts. It also discusses adapting earned value management techniques to track budget and schedule by defining productivity factors that account for team ramp-up. The approach aims to bring benefits of agile and lean thinking to fixed price projects while addressing needs for budget control and commitment to timelines.
Kata skill @ novice: 5 Common Themes of Novice SkillBeth Carrington
Here are 5 common themes I've seen when a Learner and a Coach have Kata Skill at Novice, this presentation shares those illustrated with a Healthcare Example.
The document provides guidance on creating daily status reports for testing teams. It recommends including information such as the number of test cases planned and executed for the day, defects encountered and their status, critical defects still open, environment issues, and attachments linking to the test management tool and bug reports. It also suggests enhancing the report with metrics like pass percentages and defect densities to provide insight into product quality. Lastly, it offers tips for making the report concise, accurate, and readable while maintaining an even tone during any accompanying status meetings.
Process Change: Communication & Training TipsTKMG, Inc.
Subscribe: ksmartin.com/subscribe
Recorded Webinar: http://bit.ly/1Gl23Hm
Rolling out process improvements is a common point of failure in organizations.
This document outlines a Six Sigma project to improve the operations of a bank call center. It presents the problem statement of deteriorating call center performance, outlines exercises to analyze first call resolution data using process capability indices and measurement system analysis, and proposes potential failure modes and their effects using a Failure Modes and Effects Analysis. The conclusion is that Lean Six Sigma tools can help improve first call resolution and reduce costs by eliminating waste and non-value-added activities in call center processes.
CTO Summit NASDAQ NYC 2017: Creating a QA StrategyRainforest QA
Creating a QA Strategy - a 20m talk presented originally at CTO Summit NASDAQ NYC 2017. You should learn how to think about QA, measure it, not test too much, etc.
This document summarizes an agile assessment tool called Evolutionary Stages that enables teams to evaluate their current agile practices and track progress over time. The tool provides teams with transparency into best practices and their organization's goals. It helps teams understand their starting point, create action plans to improve, and increase collaboration. When using Evolutionary Stages, facilitators work with teams to complete a questionnaire, generate heat maps and progress charts, and develop action plans to address gaps at the team and organizational level. The overall outcome is a report presented to stakeholders to discuss findings without identifying individual team results.
Taking Splunk to the Next Level - ManagementSplunk
Your team is up and running with Splunk. Now you want to maximize your investment and solve additional business problems. Attend this session led by a Splunk expert on how to expand beyond the initial use case. Learn how to how to capture, document and present Splunk's data and present impactful ways to calculate ROI using concrete metrics; cost savings, time savings, efficiency gains, and competitive advantage.
This document provides an agenda for a training program on enhancing product quality through Six Sigma and 7 quality control tools. The program will take place over 4 sessions covering topics like Six Sigma approach, objectives, measurement, identifying vital vs. trivial factors, developing objectives, and calculating first time yield. The goal of Six Sigma is to minimize defects by identifying and removing causes of variation in processes. It aims to "do it right the first time" through disciplined data collection and analysis to determine the best solutions.
Sagi Smolarski ITG - Enterprise Metrics on AgileAgileSparks
The document discusses metrics for measuring agile teams and processes at an enterprise level. It outlines why metrics are needed, including for teams to inspect and improve, for coaches to help teams, and for executives to understand productivity and quality. It describes various types of metrics including quality, process health, and productivity proxies. Specific metrics discussed include defects found in production, defects debt, work in progress, acceptance rates, velocity stability, and a process health dashboard. It notes challenges with metrics like potential dysfunctions if used improperly and sensitivity to how the tracking tool is used. The overall goal is continuous improvement through transparency and data-driven conversations.
Adaptive Delivery at Scale With the Scaled Agile Framework (SAFe)Martin Burns
It is not enough to want adaptive delivery; you need to know what to do.
Traditional Agile Delivery does not map the territory of Scale well. We need a better map.
The document compares four automation tools: Selenium, Playwright, Cypress, and TestCafe. It provides a detailed comparison matrix covering aspects like supported languages, browsers, speed, APIs, fault tolerance, CI/CD integration, communities, learning curves, and ecosystems. The conclusion is that Playwright is a solid pick for end-to-end testing due to its flexibility, auto waits features, large and active community. Cypress can be easily adopted but has some limitations. While Selenium is widely used, newer tools like Playwright are faster and more reliable. The best tool depends on an application, team and test requirements.
The 2022 World Quality Report surveyed 1,750 professionals from 32 countries and 10 sectors to identify key trends in quality assurance. The report found that while agile adoption has improved delivery times and costs for many organizations, some still struggle with quality in agile projects. It provides recommendations for organizations to improve quality practices like implementing agile quality orchestration, focusing on test automation and data strategies, integrating quality into sustainable IT initiatives, and defining quality metrics aligned with business value. The report suggests quality teams will play an important role in emerging technologies and should develop new skills to ensure seamless user experiences.
1) The document discusses different types of testing "buckets" and argues that overcategorizing tests can be counterproductive. It advocates combining ideas from different buckets to improve testing.
2) Several examples of "semi-automated" testing are provided, where scripts automate parts of a test that are repetitive or complex, but humans still provide some input.
3) The document questions strict definitions of "end-to-end" testing, arguing that tests can focus on parts of a system rather than every component from start to finish. The goal should be to test behaviors, interactions and risks specific to different areas.
Thomas Haver is an ex-scientist and ex-baker who hates sand. M&T Bank needed a better way to test their mobile banking apps and ensure a good user experience. They lacked centralized testing practices and resources. Perfecto was selected as their primary mobile testing tool to help standardize practices and provide metrics. The manual testing features would help train teams, but automation capabilities were also important for maturity.
The document describes an example mapping group activity to help clarify acceptance criteria and examples for a user story. The group is provided a sample user story about adding and editing contact details in an Amazon mobile app. Participants will generate rules and examples for the story, which will be reviewed by the group. Example mapping is presented as a way to facilitate collaboration and ensure a shared understanding of user stories before development begins.
Joe Colantonio - Actionable Automation Awesomeness in Testing Farm.pdfQA or the Highway
The document discusses the benefits of exercise for mental health. Regular physical activity can help reduce anxiety and depression and improve mood and cognitive functioning. Exercise causes chemical changes in the brain that may help protect against mental illness and improve symptoms.
Sarah Geisinger - Continious Testing Metrics That Matter.pdfQA or the Highway
The document discusses the importance of tracking the right metrics in continuous testing to improve collaboration, efficiency, and impact. It recommends measuring factors that cause pain for the QA, development, and user teams, as well as metrics focused on by leadership like deployment frequency, lead time, change failure rates, restore time, and reliability. The document advocates integrating QA metrics into the development pipeline for continuous improvement, and using dashboards for transparency.
This document outlines Jeff Sing's approach to establishing a quality roadmap through quarterly service delivery reviews. It discusses collecting the right data to understand quality trends, showcasing data during reviews to facilitate discussions, and iterating on initiatives based on review outcomes. The goal is to use a data-driven approach and collaborative discussions to continuously measure and improve how well an organization fulfills its customers' needs.
- The document discusses using small "Chihuahua-sized" load tests versus large "Big Ass Load Tests (BALT)" and argues that smaller load tests are better for continuous integration pipelines.
- Chihuahua-sized load tests are described as small, lightweight, manageable, and easy to include in pipelines without disrupting environments or requiring many resources.
- In contrast, BALTs are characterized as heavy, disruptive, resource-intensive, and only suitable when needed outside of pipelines. The document recommends focusing on small, lean, and friendly load tests that can be run continuously.
The document discusses the importance of effective incident management processes when technical issues arise. It emphasizes the need to properly determine if an actual problem exists, communicate the incident to relevant parties, assign roles to responders, document all actions and decisions, provide updates to stakeholders, conduct a post-mortem analysis to identify root causes and preventative measures, and ensure lessons are learned to improve processes. The goal is to resolve incidents quickly while establishing practices that reduce the likelihood of future occurrences and build trust through transparency.
The document discusses using ChatGPT as a testing tool. It outlines the author's assumptions and research using ChatGPT to generate code, improvements, and unit tests for Angular applications and APIs. The author notes positives include ChatGPT's ability to suggest code improvements and generate unit tests over 50% of the time. However, the author cautions that evaluating ChatGPT's responses requires knowledge and experience to determine usefulness.
This document discusses extra-functional testing and how testers can improve their ability to observe non-functional aspects of a system during functional testing. It covers key concepts like observability, and how to incorporate testing of performance, security, and accessibility. Specific tools are recommended for each quality factor, and ways to automate extra-functional tests are described. The presentation aims to help testers expand their skills and collaborate more with other testing teams.
Andrew Knight - Managing the Test Data Nightmare.pptxQA or the Highway
The document discusses strategies for managing test data, including static and dynamic data preparation approaches. Static data preparation involves creating test data before tests run, which can make tests faster but also more brittle. Dynamic data preparation creates test data during test execution, avoiding brittleness but slowing down tests. The document recommends considering both approaches and their tradeoffs when setting up a test data management strategy.
Melissa Tondi - Automation We_re Doing it Wrong.pdfQA or the Highway
The document discusses common mistakes made in test automation and provides recommendations to improve practices. It notes that automation should not replace humans but make them more efficient. Common errors include creating large test suites that run overnight and are vetted by few people, focusing only on automation metrics without consideration of test landscape, and treating automation as the sole responsibility of test teams rather than involving developers. The document recommends breaking suites into smaller focused runs, prioritizing types of tests, using standards aligned with development, and providing self-service tests maintained by cross-functional teams. The goal is to apply learnings from failures to drive innovation through a collaborative approach.
Jeff Van Fleet and John Townsend - Transition from Testing to Leadership.pdfQA or the Highway
This presentation discusses transitioning from testing roles to leadership roles. It provides an overview of common career paths from manual tester to positions like test lead, test automation engineer, test manager, and quality assurance analyst. It encourages attendees to learn, apply, and share knowledge; look for opportunities to contribute and suggest improvements; and work with their manager to create a development plan. The presentation emphasizes that leadership opportunities exist in everyday work and recommends books on leadership and culture improvement.
DesiradhaRam Gadde - Testers _ Testing in ChatGPT-AI world.pptxQA or the Highway
The document discusses testers and testing in the context of ChatGPT. It provides an introduction to ChatGPT and discusses how it can be useful for software testers. The document outlines the typical roles and skills of testers, both currently and how they may evolve in the future. It suggests that artificial intelligence like ChatGPT will help enhance how testers do their jobs rather than replace testing roles. The conclusion emphasizes the importance for testers to increase their technical skills and learn how to work with AI tools to help improve testing performance.
This document discusses semantics and word choice in testing. It explores the phrase "Testers [do|don't] (help) [prevent|detect] 'problems'" through deconstruction and analysis of the individual words. Key points made include: the definition of words like "testing", "problems", and the verbs used can impact meaning; problems are subjective and relative; and word choice around prevention versus detection reflects different perspectives. Consideration of context, definitions, and subjective views of different stakeholders is important to understanding the full meaning of statements involving testing.
Lee Barnes - What Successful Test Automation is.pdfQA or the Highway
The document discusses effective test automation and dispels common myths. It argues that test automation is a process, not just a tool, and should support business goals by automating high-value, reliable tests. Effective test automation provides fast feedback and allows testers to focus on critical tasks rather than repetitive work. The document broadens the definition of test automation to include activities beyond just automating user actions, like creating test environments and data.
This document discusses API testing with Cypress. It includes an agenda that covers a quick intro to Cypress and API testing. Cypress is a test runner that allows for API testing and has features like time travel debugging, automatic waiting, and screenshots/videos on failures that make testing easier. The presenter then demonstrates API testing with Cypress.
Carlos Kidman - Exploring AI Applications in Testing.pptxQA or the Highway
This document discusses how AI can be applied to testing in multiple ways, either with hands-on or hands-off approaches. It explores various tools that use AI for UI testing, API testing, code analysis, test data generation, and test integration. For UI testing, tools that use record and script, describe and NLP, or hands-off capabilities are listed. Similarly for API testing and code, specific tools are outlined. The document also discusses companies that provide test data solutions as well as ways to generate synthetic test data. It concludes by mentioning the potential to identify duplicate tests and automatically add data identifiers.
Ready to Unlock the Power of Blockchain!Toptal Tech
Imagine a world where data flows freely, yet remains secure. A world where trust is built into the fabric of every transaction. This is the promise of blockchain, a revolutionary technology poised to reshape our digital landscape.
Toptal Tech is at the forefront of this innovation, connecting you with the brightest minds in blockchain development. Together, we can unlock the potential of this transformative technology, building a future of transparency, security, and endless possibilities.
HijackLoader Evolution: Interactive Process HollowingDonato Onofri
CrowdStrike researchers have identified a HijackLoader (aka IDAT Loader) sample that employs sophisticated evasion techniques to enhance the complexity of the threat. HijackLoader, an increasingly popular tool among adversaries for deploying additional payloads and tooling, continues to evolve as its developers experiment and enhance its capabilities.
In their analysis of a recent HijackLoader sample, CrowdStrike researchers discovered new techniques designed to increase the defense evasion capabilities of the loader. The malware developer used a standard process hollowing technique coupled with an additional trigger that was activated by the parent process writing to a pipe. This new approach, called "Interactive Process Hollowing", has the potential to make defense evasion stealthier.
Gen Z and the marketplaces - let's translate their needsLaura Szabó
The product workshop focused on exploring the requirements of Generation Z in relation to marketplace dynamics. We delved into their specific needs, examined the specifics in their shopping preferences, and analyzed their preferred methods for accessing information and making purchases within a marketplace. Through the study of real-life cases , we tried to gain valuable insights into enhancing the marketplace experience for Generation Z.
The workshop was held on the DMA Conference in Vienna June 2024.
Discover the benefits of outsourcing SEO to Indiadavidjhones387
"Discover the benefits of outsourcing SEO to India! From cost-effective services and expert professionals to round-the-clock work advantages, learn how your business can achieve digital success with Indian SEO solutions.
2. QUESTIONS?
Contact Centric
2
To learn more about Centric Software Quality Assurance and Testing (SQA&T)
Services:
CentricConsulting.com
Joseph Ours
Email: joseph.ours@centricconsulting.com
Phone: 614.668.2306
5. ● Subjective Sentiment
● Good versus Bad
● Seen as Red, Yellow, Green status
● Bolstered by Defect Metrics
WHAT DO THEY COMMUNICATE?
Given that status reports are used to drive a point, do we really understand what they
communicate? What “things” do we communicate most often?
5
Evaluation
Progress
Coverage
● Work Completion (against Plan) - What is done versus what is not done
● Seen as On, Behind, Ahead of Schedule (Waterfall)
● Seen as Stories “Done Done”, “In Testing/Verifying”
● Bolstered by Tests run with pass/fail, tests run versus not run
● Scope of effort
● What will be covered, what will not be covered
● Seen as Requirements Traceability Matrix, Story Acceptance Criteria
● Bolstered by Coverage Metrics
8. ● What’s left to do?
● Anything that’ll get in my way?
Who is the Audience?
Since status reports communicate a point, who are we communicating them to? More
importantly, why them?
8
Other team members
Team Management (PM/SM)
Executives
● Are we on schedule or not?
● Does everything work?
● When can we release?
● What do we need to work around
14. Our industry is inherently critical. As
such, we want people to believe our
perspective especially when people push
back defensively. Numbers are our way
of making irrefutable, objective
arguments.
14
16. The Early Years
Snippets of a Neophyte
Current Cycle Script Execution Status
Scripts # %
Total 319 100%
Executed 278 87%
Passed 268 96%
Failed 10 4%
Unexecuted 41 13%
Not Completed 0 0%
Blocked 25 61%
No Run 3 7%
N/A 6 15%
Deferred 7 17%
Overall Project Defect Status by Severity
Defects Total 1-Critical 2-High 3-Medium 4-Low
Total 103 19 37 36 11
Total Active 12 3 3 5 1
New 1 0 0 1 0
Open 0 0 0 0 0
In Progress 5 2 0 2 1
Fixed 0 0 0 0 0
Ready for Retest 2 0 0 2 0
Re-Opened 0 0 0 0 0
On Hold 4 1 3 0 0
I wanted transparency, so I provided all
the numbers I had.
17. The Toddler Years
Snippets of an Neophyte
I realized no one read the numbers, so I
started using graphs
0%
20%
40%
60%
80%
100%
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day8
Day9
Day10
Day11
Day12
Day13
Day14
Day15
Test Case - S- Curve
Unexecuted
Blocked
Failed
Passed
Critical
Major
Medium
Minor
Non-Essential
I’d even experiment with metrics I didn’t
understand, such as DRE
I found Excel’s nifty regression line tool,
and hey, it looked awesome for
predicting!
18. I moved from high level numbers to
visualization of those same numbers.
Early on I focused on information being
digestible.
18
19. The Teen Years
Snippets of a Initiate
Then I started to
realize that people
needed to know a
finer level of detail.
Graphs became too
cluttered, so I went
back to charts of
numbers.
Functional Area
Test Cases
available for
execution
Executed
test
cases
Passed Failed
Not
executed Blocked
No longer
applicable
Cutover testing 66 54 54 0 0 0 12
Existing Devices (Copier, Vending, Laundry) 66 63 63 0 0 0 3
MF4100 20 20 20 0 0 0 0
SW Configuration 439 189 165 24 143 98 9
Swipe Tracking 93 93 88 5 0 2 0
JSA 6 6 6 0 1 0 0
Meals Auditor 10 10 3 7 0 0 0
IDM 20 20 14 6 0 0 0
TIA-Micros 15 14 13 1 0 1 0
HERO 9 9 6 3 0 0 0
TIA-Verifone 3 3 3 0 0 0 0
Customer Conversion 2 1 1 0 1 0 0
Grand Total 749
482
(65%)
436
(90%)
46
(10%)
145
(19%)
101
(13%)
24
(3%)
20. The Young Adult Years
Snippets of a Initiate
So, I went full on workbook. Dashboard
with underlying detail.
65,
9%
651,
91%
Test Case
Execution…
Done
Executed
12,
2%
639,
98%
Execution
Breakdown
Fail
Pass
23,
28%
55,
66%
5, 6%
Bug Status
Open
Closed
Not a
Bug
System Overall Progress Status By System Test Case Status
Row Labels Tests Written Tests Executed Tests Estimated Test Case Status
BAG MEAL 0 0 8 Done Executed Grand Total
BBTS Device 85 85 75 BBTS Device 85 85
BBTS Report/Query 29 29 78 BBTS Report/Query 29 29
BBTS SW Config 288 245 92 BBTS SW Config 43 245 288
BBTS Swipe Tracking 93 92 48 BBTS Swipe Tracking 1 92 93
BBTS TIA 23 23 22 BBTS TIA 23 23
HERO 11 11 15 HERO 11 11
HUDS DW 0 0 28 IDDM 20 20
IDDM 20 20 10 JSA 10 10
JSA 10 10 20
Meals Auditor
Replacement 1 10 11
Meals Auditor Replacement 11 10 8 Cutover 65 65
SharePoint 0 0 48 UAT 20 61 81
Cutover 65 65 40 Grand Total 65 651 716
UAT 81 61 0
Grand Total 716 651 492
Execution Status
Fail Pass Grand Total
BBTS Device 85 85
BBTS Report/Query 29 29
BBTS SW Config 8 237 245
BBTS Swipe Tracking 2 90 92
BBTS TIA 2 21 23
HERO 11 11
IDDM 20 20
JSA 10 10
Meals Auditor
Replacement 10 10
Cutover 65 65
UAT 61 61
Grand Total 12 639 651
21. I realized that visualization of numbers
was of paramount importance.
But detail was needed across multiple
aspects of testing to ensure the
information was informative.
21
22. Grown Up
Snippets of a Adept
Agile made much of prior approaches
obsolete. Additionally, the data overload
turned off many stakeholders.
So I went contextual with some graphs.
Implementation Team Weekly Status Report
1. Author/Team
Joseph Ours, Quality Assurance and Testing
2. Status
Identify each status as green, yellow, or red, and give short explanation. If status is yellow or red, provide plan to get back to green.
Overall Status – Yellow
Story Completion Status
Sprint 2 Sprint 3 Sprint 4
Total 16 9 30
Closed 11 3 1
Open (Not Closed) 5 5 2
Stories missing test cases 0 0 18
We are still testing stories in Sprint 2 and 3, and just starting testing in Sprint 4
The testing team isn’t staffed sufficient for the project to be successfully tested
o We rolled off 1 testing resource without replacing them
o One testing resource will be leaving the team to be replaced by internal resource
One Vitamix resource has been asked to join the testing team, but only has 50% utilization.
This represents a 120 man-hour deficiency.
Reporting limitations in Jira is making it nearly impossible to manage testing efforts efficiently (e.g. no way
to query stories with remote links).
Defect Status
Scope Status – Yellow
BA’s are assigning stories back to testing that don’t meet their review. The original process had BA’s
conducting meetings with CA/QA to understand what was missed. This has not happened.
In scope or Out of Scope
o The new process is better, still working out kinks.
Sprint 2 Status
o Testing is done, awaiting defect fixes and retesting to close out Sprint
Sprint 3 status –
o Testing is done, awaiting defect fixes and retesting to close out Sprint
Sprint 4 Status
o Still need to write test cases for 18 stories. Only 3 stories are ready for testing.
No firm process for moving stories in/out of scope for a given sprint that is well communicated.
Schedule Status - Red
While we’re slowly catching up, the inability to test Sprint 4 with only 2 days left in the sprint is concerning.
Cost Status
Testing budget not managed by QA team.
1. Accomplishments
Completed tasks for past week
Sprint 2, 3 testing complete, aside from retesting from defect fixes (awaiting)
Enhanced defect process to use of affects and fix version.
Wrote test cases for Sprint 4
Began assigning Sprint 5 stories to testers
2. To Do’s
Planned tasks for next week
Facilitate resolution of outstanding defects and stories from sprint 2, 3
Test user stories in sprint 3
Finish writing test cases for Sprint 4, test sprint 4
Write test cases for Sprint 5
3. Risks
Identify any possible project risks for us to discuss at the next Program Leadership Meeting. List date/milestone risk is associated with.
Testing resources – lack of availability placing testing schedule at risk
o Understaffed for work assigned – have asked BA’s to assist to help catch up.
o One resource rolled off – We are down at least 1 resource
o New resource onboarding – Didn’t happen as resource was not available. When resource available will
be ramping up on process and procedures. Is not 100% allocated to vitamix, placing testing at risk.
o New Vitamix resource – Still not 100% available over the reporting period.
Sprint scope documentation – placing testing effectiveness and efficiency at risk
o Inability of project team to document what is in scope and out of scope by sprint is a significant risk to
the overall success of the project. This is getting better. Will need to run a few sprints to close out risk.
4. Milestones
23. Ultimately, I developed the philosophy of
being an information broker, focusing on
facilitating decision making.
23
26. Understanding
Testing has a Mission
Testing leverages Assets to accomplish the
mission
Testing Evaluates and reports on observations
27. mis·sion
ˈmiSHən/
noun
• a specific task with which a person or a group is charged
• a pre-established and often self-imposed objective or
purpose <statement of the company's mission>
What is a Mission?
29. Testing Missions
Example Mission Chart
Area
Happy
Path/Functional
Edge,Corner,
NegativeCases
Performance*
Security+
Login
Search
Checkout
Registration
Social Media Integration
Global Solution
*Performance – includes Peak, Normal Responsiveness, and Stress
+Security – includes Penetration testing, IAM/Roles, and Manipulation
30. Testing Missions
Example Mission Chart
Area
Happy
Path/Functional
Edge,Corner,
NegativeCases
Performance*
Security+
Login X X
Search X X
Checkout X X
Registration X X
Social Media Integration X X
Global Solution X X
*Performance – includes Peak, Normal Responsiveness, and Stress
+Security – includes Penetration testing, IAM/Roles, and Manipulation
Digestible
Informative
Facilitative
31. What is an Asset?
as·set
ˈaset/
noun
a useful or valuable thing....
"quick reflexes were his chief asset"
32. ?What are some testing assets
32
Let’s see a possible way to make
asset status
Digestible
Informative
Facilitative
33. Testing Assets
Asset Readiness – Regression Readiness – Current Work
People [Individual]
Unit Automation Framework
Functional Automation Framework
CI Framework
Manual Reporting Framework
Manual Test Cases
Automation Suite [Tagged]
Unit Suite [Tagged]
Security Scanning Tools
Performance Suite
< Ready
9 In Progress - On Track
9 In Progress – Behind
9
In Progress - Not Going to
Make It
Broken
Example Asset Chart
34. Testing Assets
Asset Readiness – Regression Readiness – Current Work
People [Individual] < <
Unit Automation Framework <
Functional Automation Framework <
CI Framework 9 9
Manual Reporting Framework < <
Manual Test Cases < 9
Automation Suite [Tagged] 9
Unit Suite [Tagged] < <
Security Scanning Tools < <
Performance Suite < <
Example Asset Chart
Digestible
Informative
Facilitative
35. What is an Assessment?
as·sess·ment
əˈsesmənt/
noun
the evaluation or estimation of the nature, quality,
or ability of someone or something.
"the assessment of educational needs"
36. ?Is Testing an assessment
36
Let’s see a possible way to make
our assessments
Digestible
Informative
Facilitative
37. Testing Assessment
Example Solution Assessment
Area
Happy
Path
Edge
Cases
Login
Search
Checkout
Registration
Social Media Integration
Normal
Peak
Stress
Solution
Penetration
IAM/Roles
Manipulation
Solution
Performance Security
Business Functions
O Unable to Fulfill Mission
Degraded Capabilities
P Able to Fulfill Mission
] Not Evaluated
38. Testing Assessment
Example Solution Assessment
Area
Happy
Path
Edge
Cases
Login P P
Search
Checkout P P
Registration P O
Social Media Integration P
Normal
Peak
Stress
Solution
P P P
Penetration
IAM/Roles
Manipulation
Solution
] ] ]
Performance Security
Business Functions
Digestible
Informative
Facilitative
40. Real Project - Sanitized
Multi Page Status Report - Highlights
Test Area Pass Rate Pass Fail
Area A 99% 13208 13
Area B 99% 2378 5
Area C 100% 8709 0
Area D 100% 1968 0
Area E 100% 564 0
Area F 100% 1057 0
Area G 99% 5791 2
Area H 99% 28586 22
Area I 99% 199 1
Area J N/A 0 0
Area K 100% 138 0
Area L N/A 0 0
Area M N/A 0 0
Total 62598 43
14
12
10
18
27
Critical
Major
Medium
Minor
Other
81
76
77
78
79
81
83
72
74
76
78
80
82
84
0
50
100
150
200
250
300
350
400
450
Current-1-2-3-4-5-6
RemainingOpen
Total
Total Defects
Closed
Remaining Open
99.5%99.3%
98.7%
98.2%98.2%
93.0%93.0%
88.0%
90.0%
92.0%
94.0%
96.0%
98.0%
100.0%
Current-1-2-3-4-5-6
Overall Test Pass Fail Rate
41. Real Project
Key Findings:
•5 new defects logged, 2 critical
•Area B lose key attributes under a single identified common scenario
•Area G will drop sign indicator under 2 common scenarios
Key Risks:
•Automation suite is behind in the refactoring schedule due to the pull of
existing team work
•Automation reporting framework needs deployed to internal docker
publisher – currently running in a user’s VM
Key Issues:
•Data is being consistently dropped in a random fashion
Multi Page Status Report - Highlights
43. Real Project - Sanitized
Multi Page Status Report - Highlights
Test Area Pass Rate Pass Fail
Area A 99% 13208 13
Area B 99% 2378 5
Area C 100% 8709 0
Area D 100% 1968 0
Area E 100% 564 0
Area F 100% 1057 0
Area G 99% 5791 2
Area H 99% 28586 22
Area I 99% 199 1
Area J N/A 0 0
Area K 100% 138 0
Area L N/A 0 0
Area M N/A 0 0
Total 62598 43
14
12
10
18
27
Open Defect Categories
Critical
Major
Medium
Minor
Other
81
76
77
78
79
81
83
72
74
76
78
80
82
84
0
50
100
150
200
250
300
350
400
450
Current-1-2-3-4-5-6
RemainingOpen
Total
Defect Trends
Total Defects
Closed
Remaining Open
99.5%99.3%
98.7%
98.2%98.2%
93.0%93.0%
88.0%
90.0%
92.0%
94.0%
96.0%
98.0%
100.0%
Current-1-2-3-4-5-6
Overall Test Pass Fail Rate
Progress
Barriers
Readiness
Digestible
Informative
Facilitative
44. Real Project - Sanitized
Multi Page Status Report - Highlights
Test Area Pass Rate Pass Fail
Area A 99% 13208 13
Area B 99% 2378 5
Area C 100% 8709 0
Area D 100% 1968 0
Area E 100% 564 0
Area F 100% 1057 0
Area G 99% 5791 2
Area H 99% 28586 22
Area I 99% 199 1
Area J N/A 0 0
Area K 100% 138 0
Area L N/A 0 0
Area M N/A 0 0
Total 62598 43
14
12
10
18
27
Open Defect Categories
Critical
Major
Medium
Minor
Other
81
76
77
78
79
81
83
72
74
76
78
80
82
84
0
50
100
150
200
250
300
350
400
450
Current-1-2-3-4-5-6
RemainingOpen
Total
Defect Trends
Total Defects
Closed
Remaining Open
99.5%99.3%
98.7%
98.2%98.2%
93.0%93.0%
88.0%
90.0%
92.0%
94.0%
96.0%
98.0%
100.0%
Current-1-2-3-4-5-6
Overall Test Pass Fail Rate
Progress
Barriers
Readiness
Digestible
Informative
Facilitative
45. Real Project - Sanitized
Multi Page Status Report - Highlights
Test Area Pass Rate Pass Fail
Area A 99% 13208 13
Area B 99% 2378 5
Area C 100% 8709 0
Area D 100% 1968 0
Area E 100% 564 0
Area F 100% 1057 0
Area G 99% 5791 2
Area H 99% 28586 22
Area I 99% 199 1
Area J N/A 0 0
Area K 100% 138 0
Area L N/A 0 0
Area M N/A 0 0
Total 62598 43
14
12
10
18
27
Open Defect Categories
Critical
Major
Medium
Minor
Other
81
76
77
78
79
81
83
72
74
76
78
80
82
84
0
50
100
150
200
250
300
350
400
450
Current-1-2-3-4-5-6
RemainingOpen
Total
Defect Trends
Total Defects
Closed
Remaining Open
99.5%99.3%
98.7%
98.2%98.2%
93.0%93.0%
88.0%
90.0%
92.0%
94.0%
96.0%
98.0%
100.0%
Current-1-2-3-4-5-6
Overall Test Pass Fail Rate
Progress
Barriers
Readiness
Digestible
Informative
Facilitative
46. Real Project - Sanitized
Multi Page Status Report - Highlights
Test Area Pass Rate Pass Fail
Area A 99% 13208 13
Area B 99% 2378 5
Area C 100% 8709 0
Area D 100% 1968 0
Area E 100% 564 0
Area F 100% 1057 0
Area G 99% 5791 2
Area H 99% 28586 22
Area I 99% 199 1
Area J N/A 0 0
Area K 100% 138 0
Area L N/A 0 0
Area M N/A 0 0
Total 62598 43
14
12
10
18
27
Open Defect Categories
Critical
Major
Medium
Minor
Other
81
76
77
78
79
81
83
72
74
76
78
80
82
84
0
50
100
150
200
250
300
350
400
450
Current-1-2-3-4-5-6
RemainingOpen
Total
Defect Trends
Total Defects
Closed
Remaining Open
99.5%99.3%
98.7%
98.2%98.2%
93.0%93.0%
88.0%
90.0%
92.0%
94.0%
96.0%
98.0%
100.0%
Current-1-2-3-4-5-6
Overall Test Pass Fail Rate
Progress
Barriers
Readiness
Digestible
Informative
Facilitative
47. Real Project
Key Findings:
• 5 new defects logged, 2 critical
• Area B lose key attributes under a single
identified common scenario
• Area G will drop sign indicator under 2
common scenarios
Key Risks:
• Automation suite is behind in the refactoring
schedule due to the pull of existing team work
• Automation reporting framework needs deployed to
internal docker publisher – currently running in a
user’s VM
Key Issues:
• Data is being consistently dropped in a random
fashion
Multi Page Status Report - Highlights
Progress
Barriers
Readiness
Digestible
Informative
Facilitative
49. Revamped Report
Area Functionality Localization Security Performance
Area A X X
Area B X
Area C X
Area D X X
Area E X X
Area F X X
Area G X
Area H X
Area I X X
Area J X
Area K X
Area L X
Area M X
Global Solution X X
Mission Coverage
50. Revamped Report
Asset Readiness
Asset Regression Current Sprint
People [Individual] < <
Manual Test Suite < 9
Automation Suite [Tagged] <
Exploratory Charters 9 9
Localization Test Suite < <
Old Functional Automation
Framework < 9
New Functional Automation
Framework 9
CI/Automation Integration < ]
Manual Reporting Framework < ]
Automation Reporting Framework < ]
Security Scanning Tools ] ]
Performance Suite ] ]
51. Revamped Report
Asset Readiness
Asset Regression Current Sprint
People [Individual] < <
Manual Test Suite < 9
Automation Suite [Tagged] <
Exploratory Charters 9 9
Localization Test Suite < <
Old Functional Automation Framework < 9
New Functional Automation Framework 9
CI/Automation Integration < ]
Manual Reporting Framework < ]
Automation Reporting Framework < ]
Security Scanning Tools ] ]
Performance Suite ] ]
Context
• Automation suite is behind in the refactoring schedule due to the pull of existing team
work
• Automation reporting framework needs deployed to internal docker publisher – currently
running in a user’s VM
52. Revamped Report
Testing Assessment
Area Regression Current Sprint Localization
Area A P P P
Area B O
Area C P P P
Area D P P P
Area E P P P
Area F P P
Area G P
Area H P P P
Area I P P
Area J P ]
Area K P P
Area L ] ]
Area M ] ]
53. Revamped Report
Testing Assessment
Area Regression Current Sprint Localization
Area A P P P
Area B O
Area C P P P
Area D P P P
Area E P P P
Area F P P
Area G P
Area H P P P
Area I P P
Area J P ]
Area K P P
Area L ] ]
Area M ] ]
Context
• Area B lose key attributes under a single identified common scenario
• Area G will drop sign indicator under 2 common scenarios
• Data is still being consistently dropped in a random fashion
54. Revamped Report
Area Functionality Localization Security Performance
Area A X X
Area B X
Area C X
Area D X X
Area E X X
Area F X X
Area G X
Area H X
Area I X X
Area J X
Area K X
Area L X
Area M X
Global Solution X X
Mission Coverage
Digestible
Informative
Facilitative
55. Revamped Report
Asset Readiness
Asset Regression Current Sprint
People [Individual] < <
Manual Test Suite < 9
Automation Suite [Tagged] <
Exploratory Charters 9 9
Localization Test Suite < <
Old Functional Automation Framework < 9
New Functional Automation Framework 9
CI/Automation Integration < ]
Manual Reporting Framework < ]
Automation Reporting Framework < ]
Security Scanning Tools ] ]
Performance Suite ] ]
Context
• Automation suite is behind in the refactoring schedule due to the pull of existing team
work
• Automation reporting framework needs deployed to internal docker publisher – currently
running in a user’s VM
Digestible
Informative
Facilitative
Progress
Barriers
Readiness
56. Revamped Report
Testing Assessment
Area Regression Current Sprint Localization
Area A P P P
Area B O
Area C P P P
Area D P P P
Area E P P P
Area F P P
Area G P
Area H P P P
Area I P P
Area J P ]
Area K P P
Area L ] ]
Area M ] ]
Context
• Area B lose key attributes under a single identified common scenario
• Area G will drop sign indicator under 2 common scenarios
• Data is still being consistently dropped in a random fashion
Digestible
Informative
Facilitative
Progress
Barriers
Readiness
58. SaaS with Custom Configuration
Row Labels Tests Written Tests Executed
BAG MEAL 0 0
BBTS Device 85 85
BBTS Report/Query 29 29
BBTS SW Config 288 245
BBTS Swipe Tracking 93 92
BBTS TIA 23 23
HERO 11 11
HUDS DW 0 0
IDDM 20 20
JSA 10 10
Meals Auditor Replacement 11 10
SharePoint 0 0
Cutover 65 65
UAT 81 61
Grand Total 716 651
Execution Status
Fail Pass Grand Total
BBTS Device 85 85
BBTS Report/Query 29 29
BBTS SW Config 8 237 245
BBTS Swipe Tracking 2 90 92
BBTS TIA 2 21 23
HERO 11 11
IDDM 20 20
JSA 10 10
Meals Auditor Replacement 10 10
Cutover 65 65
UAT 61 61
Grand Total 12 639 651
499 533 540
645 678
736 732 720
86
293
366
454 488
558 562
648
9 21 28 36 49 62 68 79
0
200
400
600
800
Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9
Team Velocity
Test Case Written Test Case Executed Total Bugs
23, 28%
55, 66%
5, 6%
Bug Status
Open
Closed
Not a Bug
59. SaaS with Custom Configuration
Formatted for PPTX
Assets Asset
Readiness
Manual Test Cases <
QA Environment <
TCM System <
Test Data <
Area Assessment
BAG MEAL ]
BBTS Device P
BBTS Report/Query P
BBTS SW Config O
BBTS Swipe Tracking
BBTS TIA
HERO P
HUDS DW ]
IDDM P
JSA P
Meals Auditor Replacement P
SharePoint ]
Cutover P
UAT P
Issues:
• Configuration IDE will not currently compile due to
partial config manually overwriting baseline config.
Awaiting vendor assistance.
• Swipes will not track in failover mode
• Interfaces will not fail over to alternate IP on record
Other Notes:
• Team velocity is on schedule
60. QUESTIONS?
Contact Centric
60
To learn more about Centric Software Quality Assurance and Testing (SQA&T)
Services:
CentricConsulting.com
Joseph Ours
Email: joseph.ours@centricconsulting.com
Phone: 614.668.2306
Editor's Notes
Alternate for Title Slide: slide 15
Barrier
Progress
Readiness
No trusted person every needed numbers to communicate their thoughts. Numbers are only asked for when people don’t trust the messenger. Then they use numbers for an objective, truthful statement.
No trusted person every needed numbers to communicate their thoughts. Numbers are only asked for when people don’t trust the messenger. Then they use numbers for an objective, truthful statement.
Readiness Assessment [Ready and Not Ready (Maintenance, Building)]
Login
Unit Suite
Acceptance Suite
Search
Unit Suite
Acceptance Suite
Exploratory Suite
Checkout
Unit Suite
Acceptance Suite
Exploratory Suite
Registration
Unit Suite
Acceptance Suite
Performance
Peak
Normal Responsiveness
Stress
Security
Penetration
White hat suite
IAM/Roles
Manipulation
Readiness Assessment [Ready and Not Ready (Maintenance, Building)]
Login
Unit Suite
Acceptance Suite
Search
Unit Suite
Acceptance Suite
Exploratory Suite
Checkout
Unit Suite
Acceptance Suite
Exploratory Suite
Registration
Unit Suite
Acceptance Suite
Performance
Peak
Normal Responsiveness
Stress
Security
Penetration
White hat suite
IAM/Roles
Manipulation
No trusted person every needed numbers to communicate their thoughts. Numbers are only asked for when people don’t trust the messenger. Then they use numbers for an objective, truthful statement.
Mission Status [I/P, Hold, R/Y/G]
Evaluation [Capable of supporting mission, partially capable, not capable]
Login
Search
Checkout
Registration
Performance
Peak
Normal Responsiveness
Stress
Security
Penetration
White hat suite
IAM/Roles
Manipulation
Mission Status [I/P, Hold, R/Y/G]
Evaluation [Capable of supporting mission, partially capable, not capable]
Login
Search
Checkout
Registration
Performance
Peak
Normal Responsiveness
Stress
Security
Penetration
White hat suite
IAM/Roles
Manipulation
No trusted person every needed numbers to communicate their thoughts. Numbers are only asked for when people don’t trust the messenger. Then they use numbers for an objective, truthful statement.