SlideShare a Scribd company logo
Webinar:  Risk Driven Testing May 5th, 2010 11:00 AM CST Please note: The audio portion of this webinar is only accessible through the telephone dial-in number that you received in your registration confirmation email.
Jorge Boria Senior VP International Process Improvement Liveware Inc. [email_address] Michael Milutis Director of Marketing Computer Aid, Inc. (CAI) [email_address]
About  Presenter’s Firm Liveware is a leader among SEI partners, trusted by small, medium and large organizations around the world to increase their effectiveness and efficiency through improving the quality of their processes.  With an average collective experience of over 20 years in software process improvement we know how to make our customers succeed.  We partner with our clients by focusing on their bottom line and short and long term business goals.  With over 70 Introduction to CMMI classes delivered and 40 SCAMPI appraisals performed, you will not find a better consultant for your process improvement needs.
CAI  is a global IT outsourcing firm currently managing active engagements with over 100 Fortune 1,000 companies and government agencies around the world.  CAI  is a leader in IT Best Practices for legacy support and new development application management.  CAI’s  focus is directed toward practical implementations that track and measure the right activities in software activity management  CAI  consistently promises and delivers double digit productivity in its outsourcing and consulting engagements.  CAI  makes all of this possible through the use of: Standard processes Management by metrics SLA compliance management Detailed cost, resource, and time tracking Capacity management  Standard estimation A unique, metrics based methodology along with a proprietary, real time data repository and management system  (TRACER®).   About Computer Aid, Inc. (CAI)

Recommended for you

Rational Quality Manager
Rational Quality ManagerRational Quality Manager
Rational Quality Manager

IBM® Rational® Quality Manager is a collaborative, Web-based, quality management tool for comprehensive test planning and test asset management throughout the software lifecycle. It is built on the Jazz™ platform and is designed to be used by test teams of all sizes. It supports a variety of user roles, such as test manager, test architect, test lead, tester, and lab manager, as well as roles outside of the test organization. This article explains how to set up a new project in Rational Quality Manager and reviews several of the basic things that you can do with it in your projects.Strongback Consulting helps organizations get started automated their test environment and improving the quality of the quality management process.

manualtestingrqmautomation
Quality Control in Development
Quality Control in DevelopmentQuality Control in Development
Quality Control in Development

Building apps in the App Cloud is so fast and easy it can almost feel magical at times. But there is no magic in producing good quality apps and solutions. Join us as we give specific suggestions and guidance to help you with quality control in your Salesforce implementation, including typical Apex code pitfalls, setting up a review process, and creating a development standards guide.

salesforce developersdf15salesforce
Chapter 14
Chapter 14Chapter 14
Chapter 14

The document discusses the concept of software quality. It defines quality as characteristics or attributes that make something what it is. For software, quality includes design quality and conformance quality. While quality is difficult to explicitly define, it generally means meeting user goals and specifications. The document outlines different views of quality and discusses quality dimensions such as performance, reliability and maintainability. It also discusses balancing quality with cost and risk considerations.

NOW AVAILABLE!  ONLINE WEBINAR RECORDINGS  ANYTIME ACCESS! WWW. ITMPI.ORG / LIBRARY
Today’s Agenda State testing goals and objectives  Identify risks with regard to product and project characteristics  State testing activities with acceptance criteria  Select a testing lifecycle to match the products risks and the project's schedule
Our Objectives Identify testing project risks and refine the plan to include mitigation and contingency activities State testing goals and objectives  Identify risks with regard to product and project characteristics  State testing activities with acceptance criteria  Select a testing lifecycle to match the products risks and the project's schedule
The Test Categories Map © black box crystal box UNIT INTEGRATION SYSTEM ALPHA USER ACCEPTANCE BETA time goal construction functionality performance usability string volume integration stress error handling readiness configuration memory leaks regression path coverage decision coverage statement coverage data flow coverage Disclaimer: This is just indicative. Individual project’s needs vary

Recommended for you

Agile Testing: Best Practices and Methodology
Agile Testing: Best Practices and Methodology  Agile Testing: Best Practices and Methodology
Agile Testing: Best Practices and Methodology

Agile testing focuses on delivering value to customers through frequent testing and feedback. It differs from the traditional waterfall model which separates development and testing. The document discusses four main agile testing methodologies: behavior driven development, acceptance test driven development, exploratory testing, and session based testing. It also covers the agile testing quadrants framework and how companies can implement best practices for agile testing.

#qatestingservicescompany#softwaretestingservices#qatestingcompany
Best practices quality assurance
Best practices   quality assuranceBest practices   quality assurance
Best practices quality assurance

QA plays an important role in delivering high quality software by thoroughly testing for errors and issues and providing constructive feedback to developers. Some key responsibilities of QA include properly understanding requirements, creating comprehensive test plans and test cases, executing different types of testing such as positive and negative testing, carefully analyzing results and logging any issues found along with the steps to reproduce them. QA should pursue finding and resolving errors, not blame on individuals. Both QA and developers must work together effectively through clear communication and collaboration.

Test Automation Strategies and Frameworks: What Should Your Team Do?
Test Automation Strategies and Frameworks: What Should Your Team Do?Test Automation Strategies and Frameworks: What Should Your Team Do?
Test Automation Strategies and Frameworks: What Should Your Team Do?

Agile practices have done a magnificent job of speeding up the software development process. Unfortunately, simply applying agile practices to testing isn't enough to keep testers at the same pace. Test automation is necessary to support agile delivery. Max Saperstone explores popular test automation frameworks and shares the benefits of applying these frameworks, their implementation strategies, and best usage practices. Focusing on the pros and cons of each framework, Max discusses data-driven, keyword-driven, and action-driven approaches. Find out which framework and automation strategy are most beneficial for specific situations. Although this presentation is tool agnostic, Max demonstrates automation with examples from current tooling options. If you are new to test automation or trying to optimize your current automation strategy, this session is for you.

test automation
The V Model Applied UAT Execution (SDS) Test Report Sys Test Execution (SDS) Test Report Acceptance UAT Test Planning and Preparation System Test Planning and Preparation Unit Test Planning and Preparation Acceptance Requirements (SRD) Acceptance Specifications (TSD) Coding (SDS) Unit Test Execution (SDS) Hand Off Developed Components (SDS)` Phase End Review Phase End Review Post Mortem Project Review
Common Testing Problems we ship before we have finished testing our customers find most of our defects we don’t have the testers when we need them testing is ad-hoc and results are irreproducible we don’t test for the critical success factors we don’t test versus requirements from customer there are no acceptance criteria for any phase and deciding when the product is ready becomes a point of contention  ...
Risk Management  Preventable Problems We anticipated lateness but accepted sending out an unfinished product We have too many defects to fix too late in the cycle We have too many tests to run in a short period of time We have tested for the simple defects and the customer gets to test for the “killer” bugs …
Mission and goals Decision drivers Organization management Customer / end user Budget / cost Schedule Project parameters Development process Development environment Personnel and relationships Operational environment New technology Cost overruns Schedule slips Inadequate functionality Canceled projects Sudden personnel changes Customer dissatisfaction Loss of company image Demoralized staff Poor product performance Legal proceedings Risk Sources Project Consequences testing concerns

Recommended for you

Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...
Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...
Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...

EuroSTAR Software Testing Conference 2010 presentation on Working Ourselves out of a Job: A Passion For Improvement by Isabel Evans. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/

software testingeurostar conference
James Brodie - Outsourcing Partnership - Shared Perspectives
James Brodie - Outsourcing Partnership - Shared Perspectives James Brodie - Outsourcing Partnership - Shared Perspectives
James Brodie - Outsourcing Partnership - Shared Perspectives

This presentation discusses NFU Mutual's outsourcing project and partnership with a vendor for additional testing. It covers their selection process, including developing criteria and running proofs of concept. It also discusses how they have lived the relationship, including governance, service level agreements, integrating teams, and moving work offshore. Metrics and cultural integration are important factors for a successful partnership. Overall, the key to success is open communication, agreed metrics, and addressing potential issues upfront.

testing
Quality Assurance in SDLC
Quality Assurance in SDLCQuality Assurance in SDLC
Quality Assurance in SDLC

- The document discusses quality assurance in the software development lifecycle, including key concepts, practices, and challenges. - It defines quality assurance, software development lifecycle phases, and differences between verification and validation. Common testing types like unit, integration, and non-functional testing are also covered. - The document then describes quality assurance practices used in industry, such as creating QA plans, requirements reviews, test case development, and validation activities at different stages. Finally, challenges of quality assurance are discussed around testing focus, cost of fixes, schedules, and career opportunities.

software testingqasdlc
Critical Success Factors A product’s critical success factors (CSFs) are related to: business needs for its development coverage of all its intended user constituencies fitness for use in the intended context lack of dissatisfiers competitive advantage price? delighters?
CSF: Business Needs (Why?) Typical business reasons for new systems or changes: cost reduction  reducing personnel time in the field reduces costs increased efficiency of work or resource a better interface makes one person capable of doing the job of two developing new markets using a “smart card” allows very small business to get into the credit card market improved resource management electronic data management (EDM) systems allow insurance claims to be processed in hundreds of different locations, depending on work load What Is The Customer Going To Get Out Of The Use Of The Product?
CSF: User Constituencies (Who?) Answer the questions: given the business needs, what goals will the product help achieve? who will have to use the product (different user constituencies) to achieve those goals?  At least three levels of need: need to increase the bottom line typical user constituency: upper management need to gather supervisory data typical user constituency: middle management need for an efficient interface typical user constituency: end user other?
CSF: Fitness for Use (How?) “ Fitness for use” the product may meet all  stated  requirements but not support solving a real need or problem for a given user constituency testing features does not cover the workflows Test in the context of the job Test the product as if you would have to perform the job yourself Use your expertise in testing to extend the possibilities of use cases

Recommended for you

Nisha Varghese_Senior Test lead & Tester
Nisha Varghese_Senior Test lead & TesterNisha Varghese_Senior Test lead & Tester
Nisha Varghese_Senior Test lead & Tester

Nisha Varghese is a senior QA analyst and test lead with 9 years of experience in healthcare, travel, and retail domains. She has worked on various projects for Carefirst BCBS including their private exchange platform and reports for product setup changes. Her responsibilities include requirements analysis, test planning, task allocation, test oversight, reporting, and client management. She is proficient in testing methodologies, tools like ALM, and platforms like SharePoint, Lotus Notes, and mobile.

Software Quality Metrics for Testers - StarWest 2013
Software Quality Metrics for Testers - StarWest 2013Software Quality Metrics for Testers - StarWest 2013
Software Quality Metrics for Testers - StarWest 2013

Presentation by Phil Lew at StarWest 2013. When implementing software quality metrics, we need to first understand the purpose of the metrics and who will be using them. Will the metric be used to measure people or the process, to illustrate the level of quality in software products, or to drive toward a specific objective? QA managers typically want to deliver productivity metrics to management but management may want to see metrics that describe customer or user satisfaction. Philip Lew believes that software quality metrics without actionable objectives toward increasing customer satisfaction are a waste of time. Learn how to connect each metric with potential actions based on evaluating the metric. Metrics for the sake of information may be helpful but often just end up in spreadsheets of interest to no one. Take home methods to identify metrics that support actionable objectives. Once the metrics and their objectives have been established, learn how to define and use metrics for real improvement.

software testing metricssoftware quality measurementsoftware quality metrics
QA Interview Questions With Answers
QA Interview Questions With AnswersQA Interview Questions With Answers
QA Interview Questions With Answers

QA Interview Questions With Answers from software testing experts. Frequently asked questions in Quality Assurance (QA) interview for freshers and experienced professionals.

testing interview questionssoftware testingqa faqs
High-Level Testing Goals Effectiveness: Defect detection percentage of total found in some time frame severity found after testing AND Efficiency: Resource usage time people machines Reporting time spent reproducing the defect by the developers
Risks from the Project Risks from the project come from: Project Plan Schedule Constraints testing might be cut short if development is late testing might have all its tasks in the critical path Lifecycle being followed by the project Simple Waterfall,  Parallel Waterfall,  Evolutionary,  Prototyping,  Spiral Design Architecture Resources missing critical skills budgetary shortcomings
Design Architecture Figure out what the Architecture is going to be Ask the designer Request information on the design elements early If not traditional, plan accordingly Use scenarios profusely Try having testers join teams early Use testers insight of design to develop test cases Push for updated documentation Push for consistency reviews across documents Requirements traceability Formal reviews
Testing Deliverables Planning Assets Test Plan Testing Assets Testing procedures Testing suites Testing templates Reporting Assets Individual tests results Test statistics Acceptance report

Recommended for you

Not Just Numericals Values_ByDrSanjayGupta
Not Just Numericals Values_ByDrSanjayGuptaNot Just Numericals Values_ByDrSanjayGupta
Not Just Numericals Values_ByDrSanjayGupta

This document discusses the importance of test metrics in software testing. It provides examples of key metrics like productivity, defect count, and skills assessment. Productivity metrics like test cases designed/executed per day can demonstrate team capabilities. Defect data around count, age, and severity provides critical project health information. Skills can be measured on an individual, team, and readiness level against required skills to identify training needs. Representing and tracking the right metrics ensures project quality and on-time delivery.

Integrating agile into sdlc presentation pmi v2
Integrating agile into sdlc presentation   pmi v2Integrating agile into sdlc presentation   pmi v2
Integrating agile into sdlc presentation pmi v2

The document discusses integrating Agile practices into a company's software development lifecycle (SDLC). It outlines key Agile concepts like product backlogs, sprints, and daily standups. It provides examples of how sprints can align with the SDLC and what deliverables each sprint produces. Critical success factors and potential adoption risks are also covered.

Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance

The document discusses software quality assurance (SQA) and defines key terms related to quality. It describes SQA as encompassing quality management, software engineering processes, formal reviews, testing strategies, documentation control, and compliance with standards. Specific SQA activities mentioned include developing an SQA plan, participating in process development, auditing work products, and ensuring deviations are addressed. The document also discusses software reviews, inspections, reliability, and the reliability specification process.

software quality assurance
Strategy Problems Problems that faulty test strategies can cause we spend too much time on just one phase we place all our effort at the end of the project we ignore regressions we test in the wrong configuration we receive work products that are unfit to test we get into endless arguments about product fitness to ship ... Good testing strategies help!
Selecting a Strategy Decide on how much testing is required of what type when will it happen who will do it how will it happen, e.g.: Will integration be top-down or bottom-up? Will clear box be manual or automatic?
Identifying Test Tasks Review the V-Model  Pick and choose the adequate phases to meet the goals You have twenty days to visit all of Europe You may never be able to go back How do you budget your time? Testing is always under-budgeted and over-committed
Defining a Strategy Review and rework the business goals Review project variables and rework the Testing Phases  Consider cost, time to market, personnel, product life expectancy, users, constraints Emphasize the tasks that tie with the goals try to probe weak areas of the project Points to ponder: regression (when, how much, which) coverage (how much, what type, when) deadlines (slipping deadlines, schedule compression) integration (how, when, by whom) assignment of responsibility (developers, testers, users)

Recommended for you

Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance

Software quality assurance (SQA) involves planning and implementing activities throughout development to ensure quality. SQA includes standards, reviews, testing, defect tracking, and risk management. Statistical SQA categorizes defects and identifies their root causes to improve processes. Reviews are important for uncovering errors and should involve preparation, focus on the work product, and result in accepting or rejecting the product. Metrics collected from reviews indicate their effectiveness at defect detection and removal.

Risk-Based Testing for Agile Projects
Risk-Based Testing for Agile ProjectsRisk-Based Testing for Agile Projects
Risk-Based Testing for Agile Projects

Many projects implicitly use some kind of risk-based approach for prioritizing testing activities. However, critical testing decisions should be based on a product risk assessment process using key business drivers as its foundation. For agile projects, this assessment should be both thorough and lightweight. Erik van Veenendaal discusses PRISMA (PRoduct RISk MAnagement), a highly practical method for performing systematic product risk assessments. Learn how to employ PRISMA techniques in agile projects using Risk Poker. Carry out risk identification and analysis, see how to use the outcome to select the best test approach, and learn how to transform the result into an agile one-page sprint test plan. Erik shares practical experiences and results achieved by employing product risk assessments. Learn how to optimize your test effort by including product risk assessment in your agile testing practices.

software testingagile
04 small interventions sepg 2007
04 small interventions sepg 200704 small interventions sepg 2007
04 small interventions sepg 2007

- Small organizations have limited resources, making traditional SPI approaches difficult. This paper proposes a minimalist approach of making small, incremental changes that collectively achieve CMMI practices. - The approach involves identifying business problems and implementing small actions to solve them, measuring effects, and iterating. This has advantages of immediate results and accelerated adoption. - Three ways small organizations implement CMMI are through knowledge sharing with others, purchasing pre-packaged solutions, or modifying the learning curve with minimal changes. The paper focuses on the third approach in detail. - A case example demonstrates implementing a series of small process changes over time to address identified project issues in a controlled manner. This minimalist approach spreads costs and shows quick benefits

configuration managementorganizational developmentcmmi
Test Strategies (1) Analyze business case where is the payoff? think in terms of customer satisfaction identify particular functionality or killer faults Probe the quality of the product with regard to it Note:  Overriding assumption is  that you will not have time to do it all
Test Strategies (2) Analyze users by frequency of use sporadic, heavy, etc. by organizational level general managers, middle managers, end users, etc. by their knowledge of the software experts, newcomers, etc. Build a profile of system usage sketch scenarios assign probabilities for each scenario e.g.., one out of eight times the plan will be run unchanged Use this data to design the test cases to optimize testing coverage of most frequent paths
Test Strategies (3) Analyze time to market are you going to be pressed for time? => focus on existing functionality => test system rather than component => test typical rather than exceptional Decide which tests can be run within the time constraints If some of the fundamental tests cannot be run, move tests forward
Test Strategies (4) Analyze cost how many staff/hours can you pay?  Figure out if the tests you have so far selected fit within the budget If so, if you have room for more… Analyze constraints performance precision volume find critical quantities analyze or set stress testing … then include tests for them

Recommended for you

MPS and Agile Methods references in english
MPS and Agile Methods references in englishMPS and Agile Methods references in english
MPS and Agile Methods references in english

This document provides a list of over 80 references used in the field of software engineering. The references cover topics such as agile development, lean principles, software quality, project management, process improvement frameworks like CMMI and MPS.BR, and software engineering best practices. The references are from books, papers, and websites published between 1970-2012.

mps swcmmi devagile methods
Mps and agile appendix on change
Mps and agile appendix on changeMps and agile appendix on change
Mps and agile appendix on change

A big part of process improvement is managing the transition. Many books have been written about how to do this, yet there is a paucity of strategies that can be tied to real life variables. In this Appendix to our book (in translation from Spanish) we explore such strategies and suggest a parsimonious approach whenever possible.

change transitionprocess improvementchange management
From Lust to Dust: A Product Life Cycle
From Lust to Dust: A Product Life CycleFrom Lust to Dust: A Product Life Cycle
From Lust to Dust: A Product Life Cycle

Traditional software engineering deals with two phases of a product lifecycle: Development and Maintenance. In this short paper we propose to take a different approach and look at the product’s lifecycle using an analogy with the human lifecycle. We use this analogy to define roles that we call ‘research’, ‘engineering’, and ‘support’ to accommodate all the required activities that will keep a product useful for the longest period possible, while at the same time giving rapid response to customer needs.

software developmentsoftware engineeringsoftware maintenance
Test Strategies (5) Analyze personnel who can you count on reinforce testing of the products of the project’s weaker links which of your documents are going to be weak for lack of experts requirements or specs <=> functional tests high-level design <=> integration modules <=> module testing
Test Strategies (6) Analyze product life expectancy find the payoff of documented procedures, test case suites, results, etc.. don’t overspend in a product that has a short life expectancy don’t under spend in a product that will be around long
Example Strategy (1) Business goal Keep and expand customer base Internal translation to project Make sure that the user finds the entire current version’s functionality works as usual  Testing strategy Test old before new, in every phase
Example Strategy (2) Business goal Exceed customer’s expectations of product quality Internal translation to project Fewer than 10% of total bugs caught by the user  Testing strategy Move functional test suites to developers before and during unit code and testing

Recommended for you

Tableros de desempeño
Tableros de desempeñoTableros de desempeño
Tableros de desempeño

Este documento presenta un taller de un día sobre la implementación de tableros de desempeño para la motivación, el control y el diagnóstico de proyectos. El taller cubrirá cómo establecer objetivos medibles y sistemas de medición, diseñar indicadores clave de desempeño, y construir tableros de control para la toma de decisiones estratégicas y tácticas. El instructor, Jorge Boria, tiene más de 40 años de experiencia en ingeniería de software y procesos de mejora, y enseñará a los participantes cómo aplicar

sistemas de medicionesmedicionesindicadores
Maturity Models and agile chap 02
Maturity Models and agile chap 02Maturity Models and agile chap 02
Maturity Models and agile chap 02

This is the second chapter of the authors' own translation of the award winning book The Story of Tahini-Tahini: Process Improvement and Agile Methods with the MPS Model. Originally published in Portuguese and already in Spanish. This Chapter deals with Process Improvement and how to make it work.

software process improvementfishcmmi dev
El cmmi de servicios está aquí 5
El cmmi de servicios está aquí 5El cmmi de servicios está aquí 5
El cmmi de servicios está aquí 5

La última entrega de mi serie sobre el CMMI SVC. Como en la anterior, me enfoco en una de las dos áreas de gestión de trabajo que son exclusivas del modelo SVC, en este caso continuidad de servicios (SCON)

servicioscontinuidad de servicioscmmi svc
Acceptance Criteria For each test selected, define: Environment tests would have had to run on Regression suites covered by the tests  Functionality covered by the tests Performance testing goals reached Volume Testing goals achieved Reliability Testing (when applicable) Usability Testing (when applicable) How can we tell that the work product is safe for releasing it to the user?
System Acceptance Criteria Probably only main deployment environment  but NOT the development environment only Usually all regression suites for the entire tests  usually automated Most, if not all, functionality focus on functionality not tested or changed after unit code Performance Testing, Volume Testing goals MUST be met, no excuses deployment environment used in tests Reliability Testing if applicable, statistically controlled Usability Testing  if critical, or if it leaves development organization
User Acceptance Test Purpose is to detect remaining defects focus might change Different things to different people another level of system acceptance emphatically focused on usability performed by users exclusively performed by user proxies, exclusively performed by the IV&V of the organization other? ... Which is yours?
User Acceptance Criteria Some general rules Cover all deployment environments Only do regression if regression suites are different or significant fixes and / or changes have happened after system acceptance  Functionality focus should be on usual rather than exceptional Performance Testing should focus on throughput  Volume Testing might be skipped unless significant fixes and / or changes have happened after system acceptance  Reliability Testing only when thoroughly planned from day one Usability Testing probably the most emphatic effort goes here

Recommended for you

01 the value of quality
01   the value of quality01   the value of quality
01 the value of quality

1) Complex software is everywhere and software development is difficult, time-consuming, and expensive. 2) There are often large gaps in software development processes which creates risks like inconsistent processes, lack of productivity reporting, and unpredictable development. 3) Visual Studio 2012 aims to address issues in software development through features like integrated testing tools, storyboarding for early feedback, load testing, and monitoring of applications in production.

almmicrosoftmtm
April 08
April 08April 08
April 08

The document discusses challenges with traditional waterfall software development approaches and how agile development methods address some of these challenges. It notes that waterfall projects often fail to meet schedules, budgets and user needs due to changing requirements. Agile methods use iterative development, prioritize working software over documentation, and emphasize collaboration between developers and customers.

Downloads abc 2006 presentation downloads-ramesh_babu
Downloads abc 2006   presentation downloads-ramesh_babuDownloads abc 2006   presentation downloads-ramesh_babu
Downloads abc 2006 presentation downloads-ramesh_babu

This document discusses project planning, feasibility studies, and various factors to consider for IT projects. It covers guidelines for project plans, internal and external factors, components of a project plan, the project development lifecycle including planning, analysis, design, implementation, and support phases. It also discusses assessing the feasibility of projects, including tests of operational, technical, schedule, and economic feasibility. Methods for evaluating feasibility include feasibility matrices and analyses of benefits, costs, payback periods, and net present values. Managing stakeholder expectations is also addressed.

Limiting the Testing Effort (1) Some things cannot be tested quality user-friendliness timeliness …
Limiting the Testing Effort (2) Some things you might not want to test regression on a new or relatively small enhancement performance stress …
Limiting the Testing Effort (3) Some things you might not have the ability to test reliability (e.g. MTTF) availability (e.g. (MTTF/(MTTF+MTTR))) …
Constraints on the Lifecycle Review the phases against the Project’s constraints Can you accommodate the project plan schedule constraints? Is the model being followed by the project Simple Waterfall,  Parallel Waterfall,  Evolutionary,  Prototyping,  Spiral allowing for the testing tasks you’ve set? e.g. might not have integration testing Can the tests selected be adjusted to the design architecture? three tiers might bring a whole set of problems Are the goals compatible with the project’s shortcomings?

Recommended for you

Softwaretesting
SoftwaretestingSoftwaretesting
Softwaretesting

Software testing involves verifying that software meets requirements and works as intended. There are various testing types including unit, integration, system, and acceptance testing. Testing methodologies include black box testing without viewing code and white box testing using internal knowledge. The goal is to find bugs early and ensure software reliability.

How to build confidence in your release cycle
How to build confidence in your release cycleHow to build confidence in your release cycle
How to build confidence in your release cycle

Learn how to establish a greater sense of confidence in your release cycle, along with the practices and processes to create a high-performing engineering culture within your team.

 
by DiUS
software testingsoftware developmentdora metrics
Quality Assurance and Testing services
Quality Assurance and Testing servicesQuality Assurance and Testing services
Quality Assurance and Testing services

Learn why Quality Assurance is important for your business and what are different types of testing services.

qasoftware testing servicesquality assurance
Risk Action Planning Deal with high exposure risks first Research: Do we know enough about this risk?  Accept: Can we live with it and do nothing about it? Manage: Can we take action?  Avoid: Should we cancel the project or change the approach?  Balance the threat of the risk against the effort to avert it How great is the threat? How much does it cost to avert?
Risk Contingency Plans Devise contingency plans for High exposure risks, in case the mitigation strategy fails Any risk for which there is no possible mitigation action Specify risk measures and trigger values Measures of time, resources to handle risk Measures of risk impact Trigger values that tell it is time to use contingency approach now Agree with customer and management at project start how contingency plans will be funded and handled
Example Contingency Triggers For risks leading to schedule slips Latest date to allow you to use alternative platforms Latest date to select another vendor For risks requiring additional effort or time Latest date to have time to locate the resources Greatest amount of penalty or fine to incur Greatest amount of investment available for overrun Limit for extra cost to the customer Limit for learning time
Example of Action and Contingency (1) Risk Statement Since the project team is already behind schedule by two full weeks, we might not have time to cover all the high yield tests before the cutover date and the quality of the product will be seriously imperiled. Risk Action Provide one of our test engineers as a testing consultant to the development team, so they can test and fix before they send the product to the Testing Team.

Recommended for you

Webinar app testing and distribution
Webinar app testing and distribution Webinar app testing and distribution
Webinar app testing and distribution

The document discusses testing and distribution of mobile apps. It provides an overview of: 1) A mobile maturity model that organizations can use to assess their mobile strategy and capabilities across different areas including testing. 2) The importance of testing throughout the app development lifecycle from definition to development to acceptance. It describes various testing types like unit, integration, and usability testing. 3) How automated testing can help with frequent verification but still requires manual testing. It provides examples of unit and functional automated tests. 4) The different phases of testing in a project including definition to set testing requirements, development where testing is integrated, and acceptance testing by the customer.

testingmobile application developmentapp testing
Value of software testing
Value of software testingValue of software testing
Value of software testing

Software Testing adds organizational value in quantitative and qualitative ways. Successful organizations recognize the importance of quality. Establishing a quality-oriented mindset is the responsibility of business leadership.

software testingquality assuranceagile software development
Agile Pmi 102108 Final
Agile Pmi 102108 FinalAgile Pmi 102108 Final
Agile Pmi 102108 Final

This is a presentation that was given to the Project Management Institute of Metrolina. The goal is exposure to the fundamental ideas of Lean/Agile/Scrum software development.

Example of Action and Contingency (2) Contingency Plan If by the first of April, we do not have an integration test version of the product, drop the web testing suites and focus on regression so our customer can use a significantly improved current version for six months without a Web interface.
Example Contingency for Lateness Plan your testing activities in passes First Pass (mandatory): test all modules/components use most frequently used scenarios use few test cases use selected error cases Second Pass (supplementary): test only modules with fixes, do first pass on components cover most scenarios use test cases covering all data equivalence classes include test cases for “bad values” Third Pass (complementary): test only modules with fixes from second pass cover all test suite go for 100% clear case coverage
Summary Key Activities in Defining the Testing Strategy identify test tasks and their goals rank test tasks by their goals define the limits of the testing effort detail testing tasks define testing tasks entry criteria define testing tasks acceptance criteria Outputs to the process include individual test task goals  phase acceptance criteria detailed testing project tasks all in the updated test plan
Questions? Your PDU CODE: S010-ITMPI0xxxx

Recommended for you

Impetus qLabs Solutions
Impetus qLabs SolutionsImpetus qLabs Solutions
Impetus qLabs Solutions

This presentation tells in brief the solutions provided by Impetus\'s Testing Center of Excellence "qLabs". Please send in your comments at qLabs@impetus.co.in http://www.impetus.com/qLabs

puneet_pall_resume
puneet_pall_resumepuneet_pall_resume
puneet_pall_resume

This document contains the resume of Puneet Pall, who has 7 years of experience in quality assurance and testing roles. He has led offshore test teams and has experience in client communication, test planning, execution, defect management, and reporting. His technical skills include testing tools like ALM v11 and Bugzilla, and programming languages like VBScript. He has expertise in functional, regression, integration, and database testing. He also has experience working as a test lead on projects in various domains like chemicals, petroleum, insurance, and payments.

Software testing kn husainy
Software testing kn husainySoftware testing kn husainy
Software testing kn husainy

The document provides an overview of software testing, including common software problems, objectives and principles of testing, quality assurance vs quality control, software development life cycles, project management, and risk management. It discusses what testing is, why it's necessary, who does it, objectives of testing, types of problems found, quality principles, life cycles like waterfall and V-model, project planning, scheduling, staffing, and identifying, analyzing and managing risks.

moictd bangaldesh
CAI Sponsors  The IT Metrics & Productivity Institute: Clearinghouse repository of best practices:  WWW.ITMPI.ORG   Weekly educational newsletter:  WWW.ITMPI.ORG  / SUBSCRIBE Weekly webinars hosted by industry leaders:  WWW.ITMPI.ORG  / WEBINARS ACCESS WEBINAR RECORDINGS ANYTIME AT  WWW.ITMPI.ORG  / LIBRARY Online Expert Training Through CAI University (CAIU):  WWW.CAIU.COMPAID.COM Follow us on TWITTER at  WWW.TWITTER.COM /  ITMPI
Software Best Practices Conferences Around the World WWW.ITMPI.ORG  / EVENTS   Feb. 23 Tampa, FL Mar. 18 San Antonio, TX Mar. 23 Philadelphia, PA Mar. 30 El Segundo, CA Apr. 15 Philadelphia, PA Apr. 20 Detroit, MI Apr. 29 Chicago, IL May  4 Trenton, NJ May 11 New York, NY May 20 Albany, NY May 25 Toronto, ON Spring 2010 Sep. 14 Baltimore, MD Sep. 21 Sydney, AU Sep. 28 Detroit, MI Oct. 7 Tallahassee, FL Oct. 13 Orlando, FL Oct. 21 Philadelphia, PA Nov. 16 Miami, FL Fall 2010
Jorge Boria Senior VP International Process Improvement Liveware Inc. [email_address] Michael Milutis Director of Marketing Computer Aid, Inc. (CAI) [email_address]

More Related Content

What's hot

Enhancing Software Quality
Enhancing Software QualityEnhancing Software Quality
Enhancing Software Quality
Anand Prabhala
 
Software Quality Metrics Do's and Don'ts - QAI-Quest 1 Hour Presentation
Software Quality Metrics Do's and Don'ts - QAI-Quest 1 Hour PresentationSoftware Quality Metrics Do's and Don'ts - QAI-Quest 1 Hour Presentation
Software Quality Metrics Do's and Don'ts - QAI-Quest 1 Hour Presentation
XBOSoft
 
Otto Vinter - Analysing Your Defect Data for Improvement Potential
Otto Vinter - Analysing Your Defect Data for Improvement PotentialOtto Vinter - Analysing Your Defect Data for Improvement Potential
Otto Vinter - Analysing Your Defect Data for Improvement Potential
TEST Huddle
 
Rational Quality Manager
Rational Quality ManagerRational Quality Manager
Rational Quality Manager
Strongback Consulting
 
Quality Control in Development
Quality Control in DevelopmentQuality Control in Development
Quality Control in Development
Salesforce Developers
 
Chapter 14
Chapter 14Chapter 14
Chapter 14
Benjamin Yu
 
Agile Testing: Best Practices and Methodology
Agile Testing: Best Practices and Methodology  Agile Testing: Best Practices and Methodology
Agile Testing: Best Practices and Methodology
Zoe Gilbert
 
Best practices quality assurance
Best practices   quality assuranceBest practices   quality assurance
Best practices quality assurance
Shakal Shukla
 
Test Automation Strategies and Frameworks: What Should Your Team Do?
Test Automation Strategies and Frameworks: What Should Your Team Do?Test Automation Strategies and Frameworks: What Should Your Team Do?
Test Automation Strategies and Frameworks: What Should Your Team Do?
TechWell
 
Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...
Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...
Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...
TEST Huddle
 
James Brodie - Outsourcing Partnership - Shared Perspectives
James Brodie - Outsourcing Partnership - Shared Perspectives James Brodie - Outsourcing Partnership - Shared Perspectives
James Brodie - Outsourcing Partnership - Shared Perspectives
TEST Huddle
 
Quality Assurance in SDLC
Quality Assurance in SDLCQuality Assurance in SDLC
Quality Assurance in SDLC
Adil Mughal
 
Nisha Varghese_Senior Test lead & Tester
Nisha Varghese_Senior Test lead & TesterNisha Varghese_Senior Test lead & Tester
Nisha Varghese_Senior Test lead & Tester
Nisha Varghese
 
Software Quality Metrics for Testers - StarWest 2013
Software Quality Metrics for Testers - StarWest 2013Software Quality Metrics for Testers - StarWest 2013
Software Quality Metrics for Testers - StarWest 2013
XBOSoft
 
QA Interview Questions With Answers
QA Interview Questions With AnswersQA Interview Questions With Answers
QA Interview Questions With Answers
H2Kinfosys
 
Not Just Numericals Values_ByDrSanjayGupta
Not Just Numericals Values_ByDrSanjayGuptaNot Just Numericals Values_ByDrSanjayGupta
Not Just Numericals Values_ByDrSanjayGupta
Dr. Sanjay Gupta
 
Integrating agile into sdlc presentation pmi v2
Integrating agile into sdlc presentation   pmi v2Integrating agile into sdlc presentation   pmi v2
Integrating agile into sdlc presentation pmi v2
pmimkecomm
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance
Aman Adhikari
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance
Rizky Munggaran
 
Risk-Based Testing for Agile Projects
Risk-Based Testing for Agile ProjectsRisk-Based Testing for Agile Projects
Risk-Based Testing for Agile Projects
TechWell
 

What's hot (20)

Enhancing Software Quality
Enhancing Software QualityEnhancing Software Quality
Enhancing Software Quality
 
Software Quality Metrics Do's and Don'ts - QAI-Quest 1 Hour Presentation
Software Quality Metrics Do's and Don'ts - QAI-Quest 1 Hour PresentationSoftware Quality Metrics Do's and Don'ts - QAI-Quest 1 Hour Presentation
Software Quality Metrics Do's and Don'ts - QAI-Quest 1 Hour Presentation
 
Otto Vinter - Analysing Your Defect Data for Improvement Potential
Otto Vinter - Analysing Your Defect Data for Improvement PotentialOtto Vinter - Analysing Your Defect Data for Improvement Potential
Otto Vinter - Analysing Your Defect Data for Improvement Potential
 
Rational Quality Manager
Rational Quality ManagerRational Quality Manager
Rational Quality Manager
 
Quality Control in Development
Quality Control in DevelopmentQuality Control in Development
Quality Control in Development
 
Chapter 14
Chapter 14Chapter 14
Chapter 14
 
Agile Testing: Best Practices and Methodology
Agile Testing: Best Practices and Methodology  Agile Testing: Best Practices and Methodology
Agile Testing: Best Practices and Methodology
 
Best practices quality assurance
Best practices   quality assuranceBest practices   quality assurance
Best practices quality assurance
 
Test Automation Strategies and Frameworks: What Should Your Team Do?
Test Automation Strategies and Frameworks: What Should Your Team Do?Test Automation Strategies and Frameworks: What Should Your Team Do?
Test Automation Strategies and Frameworks: What Should Your Team Do?
 
Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...
Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...
Isabel Evans - Working Ourselves out of a Job: A Passion For Improvement - Eu...
 
James Brodie - Outsourcing Partnership - Shared Perspectives
James Brodie - Outsourcing Partnership - Shared Perspectives James Brodie - Outsourcing Partnership - Shared Perspectives
James Brodie - Outsourcing Partnership - Shared Perspectives
 
Quality Assurance in SDLC
Quality Assurance in SDLCQuality Assurance in SDLC
Quality Assurance in SDLC
 
Nisha Varghese_Senior Test lead & Tester
Nisha Varghese_Senior Test lead & TesterNisha Varghese_Senior Test lead & Tester
Nisha Varghese_Senior Test lead & Tester
 
Software Quality Metrics for Testers - StarWest 2013
Software Quality Metrics for Testers - StarWest 2013Software Quality Metrics for Testers - StarWest 2013
Software Quality Metrics for Testers - StarWest 2013
 
QA Interview Questions With Answers
QA Interview Questions With AnswersQA Interview Questions With Answers
QA Interview Questions With Answers
 
Not Just Numericals Values_ByDrSanjayGupta
Not Just Numericals Values_ByDrSanjayGuptaNot Just Numericals Values_ByDrSanjayGupta
Not Just Numericals Values_ByDrSanjayGupta
 
Integrating agile into sdlc presentation pmi v2
Integrating agile into sdlc presentation   pmi v2Integrating agile into sdlc presentation   pmi v2
Integrating agile into sdlc presentation pmi v2
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance
 
Risk-Based Testing for Agile Projects
Risk-Based Testing for Agile ProjectsRisk-Based Testing for Agile Projects
Risk-Based Testing for Agile Projects
 

Viewers also liked

04 small interventions sepg 2007
04 small interventions sepg 200704 small interventions sepg 2007
04 small interventions sepg 2007
Jorge Boria
 
MPS and Agile Methods references in english
MPS and Agile Methods references in englishMPS and Agile Methods references in english
MPS and Agile Methods references in english
Jorge Boria
 
Mps and agile appendix on change
Mps and agile appendix on changeMps and agile appendix on change
Mps and agile appendix on change
Jorge Boria
 
From Lust to Dust: A Product Life Cycle
From Lust to Dust: A Product Life CycleFrom Lust to Dust: A Product Life Cycle
From Lust to Dust: A Product Life Cycle
Jorge Boria
 
Tableros de desempeño
Tableros de desempeñoTableros de desempeño
Tableros de desempeño
Jorge Boria
 
Maturity Models and agile chap 02
Maturity Models and agile chap 02Maturity Models and agile chap 02
Maturity Models and agile chap 02
Jorge Boria
 
El cmmi de servicios está aquí 5
El cmmi de servicios está aquí 5El cmmi de servicios está aquí 5
El cmmi de servicios está aquí 5
Jorge Boria
 

Viewers also liked (7)

04 small interventions sepg 2007
04 small interventions sepg 200704 small interventions sepg 2007
04 small interventions sepg 2007
 
MPS and Agile Methods references in english
MPS and Agile Methods references in englishMPS and Agile Methods references in english
MPS and Agile Methods references in english
 
Mps and agile appendix on change
Mps and agile appendix on changeMps and agile appendix on change
Mps and agile appendix on change
 
From Lust to Dust: A Product Life Cycle
From Lust to Dust: A Product Life CycleFrom Lust to Dust: A Product Life Cycle
From Lust to Dust: A Product Life Cycle
 
Tableros de desempeño
Tableros de desempeñoTableros de desempeño
Tableros de desempeño
 
Maturity Models and agile chap 02
Maturity Models and agile chap 02Maturity Models and agile chap 02
Maturity Models and agile chap 02
 
El cmmi de servicios está aquí 5
El cmmi de servicios está aquí 5El cmmi de servicios está aquí 5
El cmmi de servicios está aquí 5
 

Similar to Risk Driven Testing

01 the value of quality
01   the value of quality01   the value of quality
01 the value of quality
Clemens Reijnen
 
April 08
April 08April 08
April 08
davidwebb00
 
Downloads abc 2006 presentation downloads-ramesh_babu
Downloads abc 2006   presentation downloads-ramesh_babuDownloads abc 2006   presentation downloads-ramesh_babu
Downloads abc 2006 presentation downloads-ramesh_babu
Hem Rana
 
Softwaretesting
SoftwaretestingSoftwaretesting
Softwaretesting
nazeer pasha
 
How to build confidence in your release cycle
How to build confidence in your release cycleHow to build confidence in your release cycle
How to build confidence in your release cycle
DiUS
 
Quality Assurance and Testing services
Quality Assurance and Testing servicesQuality Assurance and Testing services
Quality Assurance and Testing services
Boston Technology Corporation
 
Webinar app testing and distribution
Webinar app testing and distribution Webinar app testing and distribution
Webinar app testing and distribution
Service2Media
 
Value of software testing
Value of software testingValue of software testing
Value of software testing
Transpose Solutions Inc
 
Agile Pmi 102108 Final
Agile Pmi 102108 FinalAgile Pmi 102108 Final
Agile Pmi 102108 Final
bmcglin
 
Impetus qLabs Solutions
Impetus qLabs SolutionsImpetus qLabs Solutions
Impetus qLabs Solutions
Vipul Gupta
 
puneet_pall_resume
puneet_pall_resumepuneet_pall_resume
puneet_pall_resume
puneet pall
 
Software testing kn husainy
Software testing kn husainySoftware testing kn husainy
Software testing kn husainy
khalid noman husainy
 
Six sigma ajal
Six sigma ajalSix sigma ajal
Six sigma ajal
AJAL A J
 
Software Productivity Framework
Software Productivity Framework Software Productivity Framework
Software Productivity Framework
Zinnov
 
Curiosity and Infuse Consulting Present: Sustainable Test Automation Strategi...
Curiosity and Infuse Consulting Present: Sustainable Test Automation Strategi...Curiosity and Infuse Consulting Present: Sustainable Test Automation Strategi...
Curiosity and Infuse Consulting Present: Sustainable Test Automation Strategi...
Curiosity Software Ireland
 
Slides chapter 3
Slides chapter 3Slides chapter 3
Slides chapter 3
Priyanka Shetty
 
Slides chapter 3
Slides chapter 3Slides chapter 3
Slides chapter 3
Hardik Patel
 
The Leaders Guide to Getting Started with Automated Testing
The Leaders Guide to Getting Started with Automated TestingThe Leaders Guide to Getting Started with Automated Testing
The Leaders Guide to Getting Started with Automated Testing
James Briers
 
Importance of software quality metrics
Importance of software quality metricsImportance of software quality metrics
Importance of software quality metrics
Piyush Sohaney
 
Resume_Pallavi_Updated
Resume_Pallavi_UpdatedResume_Pallavi_Updated
Resume_Pallavi_Updated
Pallavi Nayak
 

Similar to Risk Driven Testing (20)

01 the value of quality
01   the value of quality01   the value of quality
01 the value of quality
 
April 08
April 08April 08
April 08
 
Downloads abc 2006 presentation downloads-ramesh_babu
Downloads abc 2006   presentation downloads-ramesh_babuDownloads abc 2006   presentation downloads-ramesh_babu
Downloads abc 2006 presentation downloads-ramesh_babu
 
Softwaretesting
SoftwaretestingSoftwaretesting
Softwaretesting
 
How to build confidence in your release cycle
How to build confidence in your release cycleHow to build confidence in your release cycle
How to build confidence in your release cycle
 
Quality Assurance and Testing services
Quality Assurance and Testing servicesQuality Assurance and Testing services
Quality Assurance and Testing services
 
Webinar app testing and distribution
Webinar app testing and distribution Webinar app testing and distribution
Webinar app testing and distribution
 
Value of software testing
Value of software testingValue of software testing
Value of software testing
 
Agile Pmi 102108 Final
Agile Pmi 102108 FinalAgile Pmi 102108 Final
Agile Pmi 102108 Final
 
Impetus qLabs Solutions
Impetus qLabs SolutionsImpetus qLabs Solutions
Impetus qLabs Solutions
 
puneet_pall_resume
puneet_pall_resumepuneet_pall_resume
puneet_pall_resume
 
Software testing kn husainy
Software testing kn husainySoftware testing kn husainy
Software testing kn husainy
 
Six sigma ajal
Six sigma ajalSix sigma ajal
Six sigma ajal
 
Software Productivity Framework
Software Productivity Framework Software Productivity Framework
Software Productivity Framework
 
Curiosity and Infuse Consulting Present: Sustainable Test Automation Strategi...
Curiosity and Infuse Consulting Present: Sustainable Test Automation Strategi...Curiosity and Infuse Consulting Present: Sustainable Test Automation Strategi...
Curiosity and Infuse Consulting Present: Sustainable Test Automation Strategi...
 
Slides chapter 3
Slides chapter 3Slides chapter 3
Slides chapter 3
 
Slides chapter 3
Slides chapter 3Slides chapter 3
Slides chapter 3
 
The Leaders Guide to Getting Started with Automated Testing
The Leaders Guide to Getting Started with Automated TestingThe Leaders Guide to Getting Started with Automated Testing
The Leaders Guide to Getting Started with Automated Testing
 
Importance of software quality metrics
Importance of software quality metricsImportance of software quality metrics
Importance of software quality metrics
 
Resume_Pallavi_Updated
Resume_Pallavi_UpdatedResume_Pallavi_Updated
Resume_Pallavi_Updated
 

More from Jorge Boria

Maturity Models and agile chap 01
Maturity Models and agile chap 01 Maturity Models and agile chap 01
Maturity Models and agile chap 01
Jorge Boria
 
The Story of Tahini-Tahini: Software Process Improvement with Agile Methods a...
The Story of Tahini-Tahini: Software Process Improvement with Agile Methods a...The Story of Tahini-Tahini: Software Process Improvement with Agile Methods a...
The Story of Tahini-Tahini: Software Process Improvement with Agile Methods a...
Jorge Boria
 
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Jorge Boria
 
Oilfield services
Oilfield servicesOilfield services
Oilfield services
Jorge Boria
 
El cmmi de servicios está aquí 4
El cmmi de servicios está aquí 4El cmmi de servicios está aquí 4
El cmmi de servicios está aquí 4
Jorge Boria
 
Change mgmt april-2011
Change mgmt april-2011Change mgmt april-2011
Change mgmt april-2011
Jorge Boria
 
Psqt east risk testing
Psqt east risk testingPsqt east risk testing
Psqt east risk testing
Jorge Boria
 
16 car at all levels
16 car at all levels16 car at all levels
16 car at all levels
Jorge Boria
 
El cmmi de servicios está aquí 3
El cmmi de servicios está aquí 3El cmmi de servicios está aquí 3
El cmmi de servicios está aquí 3
Jorge Boria
 
El cmmi de servicios está aquí 2
El cmmi de servicios está aquí 2El cmmi de servicios está aquí 2
El cmmi de servicios está aquí 2
Jorge Boria
 
El cmmi de servicios está aquí 1
El cmmi de servicios está aquí 1El cmmi de servicios está aquí 1
El cmmi de servicios está aquí 1
Jorge Boria
 
Effectiveness of Organizational Training
Effectiveness of Organizational TrainingEffectiveness of Organizational Training
Effectiveness of Organizational Training
Jorge Boria
 
Cmmi svc july 2011
Cmmi svc   july 2011Cmmi svc   july 2011
Cmmi svc july 2011
Jorge Boria
 
Qa 3 best practices
Qa 3 best practicesQa 3 best practices
Qa 3 best practices
Jorge Boria
 
Dont Be On Time
Dont Be On TimeDont Be On Time
Dont Be On Time
Jorge Boria
 
Product Lifecycles
Product LifecyclesProduct Lifecycles
Product Lifecycles
Jorge Boria
 
Waterfallacies V1 1
Waterfallacies V1 1Waterfallacies V1 1
Waterfallacies V1 1
Jorge Boria
 

More from Jorge Boria (17)

Maturity Models and agile chap 01
Maturity Models and agile chap 01 Maturity Models and agile chap 01
Maturity Models and agile chap 01
 
The Story of Tahini-Tahini: Software Process Improvement with Agile Methods a...
The Story of Tahini-Tahini: Software Process Improvement with Agile Methods a...The Story of Tahini-Tahini: Software Process Improvement with Agile Methods a...
The Story of Tahini-Tahini: Software Process Improvement with Agile Methods a...
 
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
 
Oilfield services
Oilfield servicesOilfield services
Oilfield services
 
El cmmi de servicios está aquí 4
El cmmi de servicios está aquí 4El cmmi de servicios está aquí 4
El cmmi de servicios está aquí 4
 
Change mgmt april-2011
Change mgmt april-2011Change mgmt april-2011
Change mgmt april-2011
 
Psqt east risk testing
Psqt east risk testingPsqt east risk testing
Psqt east risk testing
 
16 car at all levels
16 car at all levels16 car at all levels
16 car at all levels
 
El cmmi de servicios está aquí 3
El cmmi de servicios está aquí 3El cmmi de servicios está aquí 3
El cmmi de servicios está aquí 3
 
El cmmi de servicios está aquí 2
El cmmi de servicios está aquí 2El cmmi de servicios está aquí 2
El cmmi de servicios está aquí 2
 
El cmmi de servicios está aquí 1
El cmmi de servicios está aquí 1El cmmi de servicios está aquí 1
El cmmi de servicios está aquí 1
 
Effectiveness of Organizational Training
Effectiveness of Organizational TrainingEffectiveness of Organizational Training
Effectiveness of Organizational Training
 
Cmmi svc july 2011
Cmmi svc   july 2011Cmmi svc   july 2011
Cmmi svc july 2011
 
Qa 3 best practices
Qa 3 best practicesQa 3 best practices
Qa 3 best practices
 
Dont Be On Time
Dont Be On TimeDont Be On Time
Dont Be On Time
 
Product Lifecycles
Product LifecyclesProduct Lifecycles
Product Lifecycles
 
Waterfallacies V1 1
Waterfallacies V1 1Waterfallacies V1 1
Waterfallacies V1 1
 

Risk Driven Testing

  • 1. Webinar: Risk Driven Testing May 5th, 2010 11:00 AM CST Please note: The audio portion of this webinar is only accessible through the telephone dial-in number that you received in your registration confirmation email.
  • 2. Jorge Boria Senior VP International Process Improvement Liveware Inc. [email_address] Michael Milutis Director of Marketing Computer Aid, Inc. (CAI) [email_address]
  • 3. About Presenter’s Firm Liveware is a leader among SEI partners, trusted by small, medium and large organizations around the world to increase their effectiveness and efficiency through improving the quality of their processes. With an average collective experience of over 20 years in software process improvement we know how to make our customers succeed. We partner with our clients by focusing on their bottom line and short and long term business goals. With over 70 Introduction to CMMI classes delivered and 40 SCAMPI appraisals performed, you will not find a better consultant for your process improvement needs.
  • 4. CAI is a global IT outsourcing firm currently managing active engagements with over 100 Fortune 1,000 companies and government agencies around the world. CAI is a leader in IT Best Practices for legacy support and new development application management. CAI’s focus is directed toward practical implementations that track and measure the right activities in software activity management CAI consistently promises and delivers double digit productivity in its outsourcing and consulting engagements. CAI makes all of this possible through the use of: Standard processes Management by metrics SLA compliance management Detailed cost, resource, and time tracking Capacity management Standard estimation A unique, metrics based methodology along with a proprietary, real time data repository and management system (TRACER®). About Computer Aid, Inc. (CAI)
  • 5. NOW AVAILABLE! ONLINE WEBINAR RECORDINGS ANYTIME ACCESS! WWW. ITMPI.ORG / LIBRARY
  • 6. Today’s Agenda State testing goals and objectives Identify risks with regard to product and project characteristics State testing activities with acceptance criteria Select a testing lifecycle to match the products risks and the project's schedule
  • 7. Our Objectives Identify testing project risks and refine the plan to include mitigation and contingency activities State testing goals and objectives Identify risks with regard to product and project characteristics State testing activities with acceptance criteria Select a testing lifecycle to match the products risks and the project's schedule
  • 8. The Test Categories Map © black box crystal box UNIT INTEGRATION SYSTEM ALPHA USER ACCEPTANCE BETA time goal construction functionality performance usability string volume integration stress error handling readiness configuration memory leaks regression path coverage decision coverage statement coverage data flow coverage Disclaimer: This is just indicative. Individual project’s needs vary
  • 9. The V Model Applied UAT Execution (SDS) Test Report Sys Test Execution (SDS) Test Report Acceptance UAT Test Planning and Preparation System Test Planning and Preparation Unit Test Planning and Preparation Acceptance Requirements (SRD) Acceptance Specifications (TSD) Coding (SDS) Unit Test Execution (SDS) Hand Off Developed Components (SDS)` Phase End Review Phase End Review Post Mortem Project Review
  • 10. Common Testing Problems we ship before we have finished testing our customers find most of our defects we don’t have the testers when we need them testing is ad-hoc and results are irreproducible we don’t test for the critical success factors we don’t test versus requirements from customer there are no acceptance criteria for any phase and deciding when the product is ready becomes a point of contention ...
  • 11. Risk Management Preventable Problems We anticipated lateness but accepted sending out an unfinished product We have too many defects to fix too late in the cycle We have too many tests to run in a short period of time We have tested for the simple defects and the customer gets to test for the “killer” bugs …
  • 12. Mission and goals Decision drivers Organization management Customer / end user Budget / cost Schedule Project parameters Development process Development environment Personnel and relationships Operational environment New technology Cost overruns Schedule slips Inadequate functionality Canceled projects Sudden personnel changes Customer dissatisfaction Loss of company image Demoralized staff Poor product performance Legal proceedings Risk Sources Project Consequences testing concerns
  • 13. Critical Success Factors A product’s critical success factors (CSFs) are related to: business needs for its development coverage of all its intended user constituencies fitness for use in the intended context lack of dissatisfiers competitive advantage price? delighters?
  • 14. CSF: Business Needs (Why?) Typical business reasons for new systems or changes: cost reduction reducing personnel time in the field reduces costs increased efficiency of work or resource a better interface makes one person capable of doing the job of two developing new markets using a “smart card” allows very small business to get into the credit card market improved resource management electronic data management (EDM) systems allow insurance claims to be processed in hundreds of different locations, depending on work load What Is The Customer Going To Get Out Of The Use Of The Product?
  • 15. CSF: User Constituencies (Who?) Answer the questions: given the business needs, what goals will the product help achieve? who will have to use the product (different user constituencies) to achieve those goals? At least three levels of need: need to increase the bottom line typical user constituency: upper management need to gather supervisory data typical user constituency: middle management need for an efficient interface typical user constituency: end user other?
  • 16. CSF: Fitness for Use (How?) “ Fitness for use” the product may meet all stated requirements but not support solving a real need or problem for a given user constituency testing features does not cover the workflows Test in the context of the job Test the product as if you would have to perform the job yourself Use your expertise in testing to extend the possibilities of use cases
  • 17. High-Level Testing Goals Effectiveness: Defect detection percentage of total found in some time frame severity found after testing AND Efficiency: Resource usage time people machines Reporting time spent reproducing the defect by the developers
  • 18. Risks from the Project Risks from the project come from: Project Plan Schedule Constraints testing might be cut short if development is late testing might have all its tasks in the critical path Lifecycle being followed by the project Simple Waterfall, Parallel Waterfall, Evolutionary, Prototyping, Spiral Design Architecture Resources missing critical skills budgetary shortcomings
  • 19. Design Architecture Figure out what the Architecture is going to be Ask the designer Request information on the design elements early If not traditional, plan accordingly Use scenarios profusely Try having testers join teams early Use testers insight of design to develop test cases Push for updated documentation Push for consistency reviews across documents Requirements traceability Formal reviews
  • 20. Testing Deliverables Planning Assets Test Plan Testing Assets Testing procedures Testing suites Testing templates Reporting Assets Individual tests results Test statistics Acceptance report
  • 21. Strategy Problems Problems that faulty test strategies can cause we spend too much time on just one phase we place all our effort at the end of the project we ignore regressions we test in the wrong configuration we receive work products that are unfit to test we get into endless arguments about product fitness to ship ... Good testing strategies help!
  • 22. Selecting a Strategy Decide on how much testing is required of what type when will it happen who will do it how will it happen, e.g.: Will integration be top-down or bottom-up? Will clear box be manual or automatic?
  • 23. Identifying Test Tasks Review the V-Model Pick and choose the adequate phases to meet the goals You have twenty days to visit all of Europe You may never be able to go back How do you budget your time? Testing is always under-budgeted and over-committed
  • 24. Defining a Strategy Review and rework the business goals Review project variables and rework the Testing Phases Consider cost, time to market, personnel, product life expectancy, users, constraints Emphasize the tasks that tie with the goals try to probe weak areas of the project Points to ponder: regression (when, how much, which) coverage (how much, what type, when) deadlines (slipping deadlines, schedule compression) integration (how, when, by whom) assignment of responsibility (developers, testers, users)
  • 25. Test Strategies (1) Analyze business case where is the payoff? think in terms of customer satisfaction identify particular functionality or killer faults Probe the quality of the product with regard to it Note: Overriding assumption is that you will not have time to do it all
  • 26. Test Strategies (2) Analyze users by frequency of use sporadic, heavy, etc. by organizational level general managers, middle managers, end users, etc. by their knowledge of the software experts, newcomers, etc. Build a profile of system usage sketch scenarios assign probabilities for each scenario e.g.., one out of eight times the plan will be run unchanged Use this data to design the test cases to optimize testing coverage of most frequent paths
  • 27. Test Strategies (3) Analyze time to market are you going to be pressed for time? => focus on existing functionality => test system rather than component => test typical rather than exceptional Decide which tests can be run within the time constraints If some of the fundamental tests cannot be run, move tests forward
  • 28. Test Strategies (4) Analyze cost how many staff/hours can you pay? Figure out if the tests you have so far selected fit within the budget If so, if you have room for more… Analyze constraints performance precision volume find critical quantities analyze or set stress testing … then include tests for them
  • 29. Test Strategies (5) Analyze personnel who can you count on reinforce testing of the products of the project’s weaker links which of your documents are going to be weak for lack of experts requirements or specs <=> functional tests high-level design <=> integration modules <=> module testing
  • 30. Test Strategies (6) Analyze product life expectancy find the payoff of documented procedures, test case suites, results, etc.. don’t overspend in a product that has a short life expectancy don’t under spend in a product that will be around long
  • 31. Example Strategy (1) Business goal Keep and expand customer base Internal translation to project Make sure that the user finds the entire current version’s functionality works as usual Testing strategy Test old before new, in every phase
  • 32. Example Strategy (2) Business goal Exceed customer’s expectations of product quality Internal translation to project Fewer than 10% of total bugs caught by the user Testing strategy Move functional test suites to developers before and during unit code and testing
  • 33. Acceptance Criteria For each test selected, define: Environment tests would have had to run on Regression suites covered by the tests Functionality covered by the tests Performance testing goals reached Volume Testing goals achieved Reliability Testing (when applicable) Usability Testing (when applicable) How can we tell that the work product is safe for releasing it to the user?
  • 34. System Acceptance Criteria Probably only main deployment environment but NOT the development environment only Usually all regression suites for the entire tests usually automated Most, if not all, functionality focus on functionality not tested or changed after unit code Performance Testing, Volume Testing goals MUST be met, no excuses deployment environment used in tests Reliability Testing if applicable, statistically controlled Usability Testing if critical, or if it leaves development organization
  • 35. User Acceptance Test Purpose is to detect remaining defects focus might change Different things to different people another level of system acceptance emphatically focused on usability performed by users exclusively performed by user proxies, exclusively performed by the IV&V of the organization other? ... Which is yours?
  • 36. User Acceptance Criteria Some general rules Cover all deployment environments Only do regression if regression suites are different or significant fixes and / or changes have happened after system acceptance Functionality focus should be on usual rather than exceptional Performance Testing should focus on throughput Volume Testing might be skipped unless significant fixes and / or changes have happened after system acceptance Reliability Testing only when thoroughly planned from day one Usability Testing probably the most emphatic effort goes here
  • 37. Limiting the Testing Effort (1) Some things cannot be tested quality user-friendliness timeliness …
  • 38. Limiting the Testing Effort (2) Some things you might not want to test regression on a new or relatively small enhancement performance stress …
  • 39. Limiting the Testing Effort (3) Some things you might not have the ability to test reliability (e.g. MTTF) availability (e.g. (MTTF/(MTTF+MTTR))) …
  • 40. Constraints on the Lifecycle Review the phases against the Project’s constraints Can you accommodate the project plan schedule constraints? Is the model being followed by the project Simple Waterfall, Parallel Waterfall, Evolutionary, Prototyping, Spiral allowing for the testing tasks you’ve set? e.g. might not have integration testing Can the tests selected be adjusted to the design architecture? three tiers might bring a whole set of problems Are the goals compatible with the project’s shortcomings?
  • 41. Risk Action Planning Deal with high exposure risks first Research: Do we know enough about this risk? Accept: Can we live with it and do nothing about it? Manage: Can we take action? Avoid: Should we cancel the project or change the approach? Balance the threat of the risk against the effort to avert it How great is the threat? How much does it cost to avert?
  • 42. Risk Contingency Plans Devise contingency plans for High exposure risks, in case the mitigation strategy fails Any risk for which there is no possible mitigation action Specify risk measures and trigger values Measures of time, resources to handle risk Measures of risk impact Trigger values that tell it is time to use contingency approach now Agree with customer and management at project start how contingency plans will be funded and handled
  • 43. Example Contingency Triggers For risks leading to schedule slips Latest date to allow you to use alternative platforms Latest date to select another vendor For risks requiring additional effort or time Latest date to have time to locate the resources Greatest amount of penalty or fine to incur Greatest amount of investment available for overrun Limit for extra cost to the customer Limit for learning time
  • 44. Example of Action and Contingency (1) Risk Statement Since the project team is already behind schedule by two full weeks, we might not have time to cover all the high yield tests before the cutover date and the quality of the product will be seriously imperiled. Risk Action Provide one of our test engineers as a testing consultant to the development team, so they can test and fix before they send the product to the Testing Team.
  • 45. Example of Action and Contingency (2) Contingency Plan If by the first of April, we do not have an integration test version of the product, drop the web testing suites and focus on regression so our customer can use a significantly improved current version for six months without a Web interface.
  • 46. Example Contingency for Lateness Plan your testing activities in passes First Pass (mandatory): test all modules/components use most frequently used scenarios use few test cases use selected error cases Second Pass (supplementary): test only modules with fixes, do first pass on components cover most scenarios use test cases covering all data equivalence classes include test cases for “bad values” Third Pass (complementary): test only modules with fixes from second pass cover all test suite go for 100% clear case coverage
  • 47. Summary Key Activities in Defining the Testing Strategy identify test tasks and their goals rank test tasks by their goals define the limits of the testing effort detail testing tasks define testing tasks entry criteria define testing tasks acceptance criteria Outputs to the process include individual test task goals phase acceptance criteria detailed testing project tasks all in the updated test plan
  • 48. Questions? Your PDU CODE: S010-ITMPI0xxxx
  • 49. CAI Sponsors The IT Metrics & Productivity Institute: Clearinghouse repository of best practices: WWW.ITMPI.ORG Weekly educational newsletter: WWW.ITMPI.ORG / SUBSCRIBE Weekly webinars hosted by industry leaders: WWW.ITMPI.ORG / WEBINARS ACCESS WEBINAR RECORDINGS ANYTIME AT WWW.ITMPI.ORG / LIBRARY Online Expert Training Through CAI University (CAIU): WWW.CAIU.COMPAID.COM Follow us on TWITTER at WWW.TWITTER.COM / ITMPI
  • 50. Software Best Practices Conferences Around the World WWW.ITMPI.ORG / EVENTS Feb. 23 Tampa, FL Mar. 18 San Antonio, TX Mar. 23 Philadelphia, PA Mar. 30 El Segundo, CA Apr. 15 Philadelphia, PA Apr. 20 Detroit, MI Apr. 29 Chicago, IL May 4 Trenton, NJ May 11 New York, NY May 20 Albany, NY May 25 Toronto, ON Spring 2010 Sep. 14 Baltimore, MD Sep. 21 Sydney, AU Sep. 28 Detroit, MI Oct. 7 Tallahassee, FL Oct. 13 Orlando, FL Oct. 21 Philadelphia, PA Nov. 16 Miami, FL Fall 2010
  • 51. Jorge Boria Senior VP International Process Improvement Liveware Inc. [email_address] Michael Milutis Director of Marketing Computer Aid, Inc. (CAI) [email_address]

Editor's Notes

  1. The purpose of this webinar is to discuss issues that impact the effectiveness of IT organizations. Our discussion will be limited to IT Service Delivery (problem resolution, consultation requests, enhancements and projects). We will not be addressing Infrastructure or Operations Management issues.
  2. Discuss these versus the class expectations, going over the notes from the introduction slide.
  3. There are many more problems… see what students can add to the list. Other things that are often missing are the quality characteristics - what are the reliability requirements, the availability requirements, maintainability, portability, etc. What platforms are needed? What’s the key problem with today’s system that has to be addressed by this new one? What can go wrong if we don’t plan for these things in testing?
  4. A project is a microcosm within a larger organization. Effective risk management must take into account the business environment in which the project operates. Many, if not most, projects fail not for technology or project management reasons, but because of larger organizational pressures that are typically ignored. These organizational pressures come in many forms, such as competitive pressures, financial health, and organizational culture. Here is a sample list of risk sources and possible consequences. It is interesting to note that the elements of significant risk are not the same across all types of projects. Different types of projects face different kinds of risks and must then pursue entirely different forms of risk control. When you take only a limited amount of time to do risk identification, you might use this list of categories to guide brainstorming of the risks to the projects. For example, if you are working on a small project which will receive minimal risk and reviews focus, you may spend only a few minutes considering the risks. Use the list of categories here to guide that time in a top-down approach to identifying the risks.
  5. When faced with what to test, the crunch between the scarcity of resources and the need to provide a comprehensive coverage forces the testing manager with a compromise. To go through the horns of this dilemma, the best option is to find those aspects of the product that have the most impact on the business, a concept sometimes identified with “good enough”. A product might be defect free and not good enough, or defect plagued and good enough for its market. These CSFs are the quintessential element of a good testing plan.
  6. What are the business drivers for the change? What will make the product a success or a failure? For example, if the business need is headcount reduction based on the goodness of your interface, how can you test that the reduction could be (not will be, because that is outside your scope) achieved? In the above slide, discuss what features might be crucial to the success of the product.
  7. You should research who are the buyers of the product. All products are considered to bring in positive changes that will eventually impact the bottom line. For some, this imperative is seen as a short term goal. Is this your case? If so, how? Consider that sometimes the problem the product is expected to solve is that of administrative control. Does the product have the functionality to provide this? Is this functionality correct? Would the end-users also see improvement in the installation of the system? How can you get the kinks out of the system before shipping it to them, so that this is true?
  8. What good is a good system if it is not really solving a problem? Would you use eighteen-wheelers for urban transportation of letters and documents? Does that make them bad products? Conversely, would you use motorcycles to send fresh farm produce across the continental United States? Does that make motorcycles unfit for commercial applications? When you are testing, do you only test against requirements? Whose representation are you assuming that makes sense for the business? Remember that your role is not to check that the software runs, nor to prove it correct, but to show all aspects that the users will find objections to!
  9. The testing manager has two dimensions to worry about: being effective, that is, detecting as many defects as possible, and being efficient, that is, do this with the restrictions of a scarcity of resources. The most scarce resource is, of course, time. We have already discussed that testing is, by definition, always in the critical path. Therefore, it is sage she who schedules critical tasks (let’s call the testing tasks related to critical success factors so) before others. The purpose of testing is to find defects, but an implied consequence of this is that these defects get fixed. In that sense, reporting is very much a critical skill of a good tester. One way to measure it is in the time spent by developers in reproducing the defect when trying to fix it. This, and the other measures that are shown here, are just examples of goal setting dimensions.
  10. Link this plan to the Project Plan by the schedule constraints. Enter this under the Schedule Constraints sub-section. Describe the model being followed by the project: Simple Waterfall, Parallel Waterfall, Evolutionary, Prototyping, Spiral, etc. Enter this under the Project’s Lifecycle Model sub-section. Define the project’s tasks at a high level of granularity, in order to show the schedule dependencies of the testing tasks with the project’s tasks. Use your Testing Process now to interleave the Testing tasks without tailoring them yet. Enter all this under the Project’s Work breakdown structure sub-section. You will have the opportunity later to refine or change the testing tasks, even drop some tasks as you see adequate. If known, enter under the sub section The Project’s Design Architecture the overall design architecture, whether the architecture is batch, event-driven, one, two, or three-tiered, etc. Discuss any shortcomings of the project that can have an impact on the business from the viewpoint of the testing team. Enter this under the Project’s Shortcomings sub-section.
  11. Link this plan to the Project Plan by the schedule constraints. Enter this under the Schedule Constraints sub-section. Describe the model being followed by the project: Simple Waterfall, Parallel Waterfall, Evolutionary, Prototyping, Spiral, etc. Enter this under the Project’s Lifecycle Model sub-section. Define the project’s tasks at a high level of granularity, in order to show the schedule dependencies of the testing tasks with the project’s tasks. Use your Testing Process now to interleave the Testing tasks without tailoring them yet. Enter all this under the Project’s Work breakdown structure sub-section. You will have the opportunity later to refine or change the testing tasks, even drop some tasks as you see adequate. If known, enter under the sub section The Project’s Design Architecture the overall design architecture, whether the architecture is batch, event-driven, one, two, or three-tiered, etc. Discuss any shortcomings of the project that can have an impact on the business from the viewpoint of the testing team. Enter this under the Project’s Shortcomings sub-section.
  12. There are many more problems… see what students can add to the list. Other things that are often missing are the quality characteristics - what are the reliability requirements, the availability requirements, maintainability, portability, etc. Can we test them? Should we? What platforms are needed? What’s the key problem with today’s system that has to be addressed by this new one?
  13. The simile here is that testing, always in the critical path, will not be granted the required time to do a thorough job, in all but the most mission critical projects. However, it still has to do a “good-enough” job. Therefore, a large part of the strategy is to cleverly budget the time allotted to testing. Mind you that this is not a problem of testing resources, because even with a very large number of testers you can have too little time to run a very large number of tests. Also, the nature of the process is that before you run a large number the programs break down and you send them back to fix. This is, in fact, the limiting factor: how many defects can be fixed per unit of time? Since you will find ten times as many defects in the time it takes to correct one, starting early makes all the sense. If you leave the testing till the end, when all the resources have been committed to delivering massive quantities of unusable functionality, the project is lost.
  14. You cannot stress enough that quality cannot be tested into a product. Yes, you can test the kinks out of a product, but quality is a fundamental, quintessential, holistic characteristic. User-friendliness is not a requirement, it is a general statement. The (derived) requirement will have to be testable, as in number of buttons, number of clicks to get the job done, feedback received, time to do the job, etc. User friendliness is, surprisingly, very unfriendly to the tester. It isn’t even a usability statement! It probably, but not always, draws from usability, but performance and fitness of purpose are more important. You might want to have reliability numbers, but you can’t if you don’t have profiled scenarios of the usage, with probabilities attached.
  15. You cannot stress enough that quality cannot be tested into a product. Yes, you can test the kinks out of a product, but quality is a fundamental, quintessential, holistic characteristic. User-friendliness is not a requirement, it is a general statement. The (derived) requirement will have to be testable, as in number of buttons, number of clicks to get the job done, feedback received, time to do the job, etc. User friendliness is, surprisingly, very unfriendly to the tester. It isn’t even a usability statement! It probably, but not always, draws from usability, but performance and fitness of purpose are more important. You might want to have reliability numbers, but you can’t if you don’t have profiled scenarios of the usage, with probabilities attached.
  16. You cannot stress enough that quality cannot be tested into a product. Yes, you can test the kinks out of a product, but quality is a fundamental, quintessential, holistic characteristic. User-friendliness is not a requirement, it is a general statement. The (derived) requirement will have to be testable, as in number of buttons, number of clicks to get the job done, feedback received, time to do the job, etc. User friendliness is, surprisingly, very unfriendly to the tester. It isn’t even a usability statement! It probably, but not always, draws from usability, but performance and fitness of purpose are more important. You might want to have reliability numbers, but you can’t if you don’t have profiled scenarios of the usage, with probabilities attached.
  17. It is time to think pre-scheduling. Will this strategy fly? Mainly, will the people be available, will there be time to perform the tests (and the fixes) will the model accommodate the strategy, will you have to change the strategy to accommodate the model. For example, you have set a high coverage goal for the unit tests. The architecture is OO framework. Will you have to accommodate the goals to fit the architecture? Will a high scenario coverage suffice?
  18. Risk action planning turns risk information into decisions and actions. Planning involves developing actions to address individual risks, prioritizing risk actions, and creating an integrated risk management plan. Here are four key areas to address during risk action planning: Research. Do we know enough about this risk? Do we need to study the risk further to acquire more information and better determine the characteristics of the risk before we can decide what action to take? Accept. Can we live with the consequences if the risk were actually to occur? Can we accept the risk and take no further action? Manage. Is there anything the team can do to mitigate the impact of the risk should the risk occur? Is the effort worth the cost? Avoid. Can we avoid the risk by changing the project approach?
  19. A contingency plan provides a fallback option in case all efforts to manage the risk fail. For example, suppose a new release of a particular tool is needed so that software can be placed on some platform, but the arrival of the tool is at risk. We may want to have a plan to use an alternate tool or platform. Simultaneous development may be the only contingency plan that ensures we hit the market window we seek. Deciding when to start the second parallel effort is a matter of watching the trigger value for the contingency plan. To determine when to launch the contingency plan, the team should select measures of risk handling or measures of impact that they can use to determine when their mitigation strategy is out of control. At that point, they need to start the contingency plan.
  20. Trigger values for the contingency plan can often be established based on the type of risk or the type of project consequence that will be encountered. Trigger values help the project team determine when they need to spend the time, money, or effort on their contingency plan, since mitigation efforts are not working.
  21. The action plan addresses the risk in a way that allows us to apply resources or other assistance to remove the potential problem. The contingency action is our fallback plan, for the possibility that the action does not work. Here, we see that a case where there probably is no viable option other than the one being developed. If it doesn’t get to us on time, we may need to ship without the feature. The product may have other capabilities for which the customer needs the release on the original date planned, whether or not it has the Web interface.
  22. The action plan addresses the risk in a way that allows us to apply resources or other assistance to remove the potential problem. The contingency action is our fallback plan, for the possibility that the action does not work. Here, we see that a case where there probably is no viable option other than the one being developed. If it doesn’t get to us on time, we may need to ship without the feature. The product may have other capabilities for which the customer needs the release on the original date planned, whether or not it has the Web interface.
  23. Another way to think it is to have the universe of test suites divided within itself in mandatory test cases, supplementary test cases, and complementary test cases, and have the suites ranked into “must run”, “good to run”, and “optional”.
  24. Our focus is to help build effective business processes, leveraging the best products in the marketplace, to build solutions to customer problems quickly.