Develop a Defect Prevention Strategy—or Else!TechWell
Defects occurring throughout the development of a software project penalize the project. The effort spent remediating these defects robs the project team of valuable time, resources, and money that could otherwise be used for further innovation and delivering the highest possible quality product to wow the customer. The occurrence of a large percentage of these defects can be avoided with preventive defect removal strategies. Scott Aziz describes various methods for removing defects during the early design and development phases―long before testing. Methods include requirements-based testing that eliminates 95 percent of requirements defects prior to the coding phase, code reviews and inspections, and establishing model-based test design practices that allow for testing business requirements before any code is developed. Take back and adopt in your environment some of the most effective early defect prevention practices known and practiced in the industry today.
The anonymised slides from an old (but hopefully still relevant) talk on the case for placing a strategic focus on design testability. The material covers the technical, process and organisational considerations arising from such a strategy and is predominantly a summary of the ideas presented in Brett Pettichord's 2001 "Design For Testability' paper available here. The presentation makes a case for why a high level of design testability can be seen as a critical success factor in achieving sustained agility.
YAHDI SANDRA
11453104752
Program Studi S1 Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Sultan Syarif Kasim Riau
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/
Things to keep in mind before starting a test planNexSoftsys
If you are going to start a test plan, then you will know that most of the time in software testing, there is more debate on its quality and plan of activities. Today many things are worth noting, but you have to pay attention to these important things before starting the test plan.
Develop a Defect Prevention Strategy—or Else!TechWell
Defects occurring throughout the development of a software project penalize the project. The effort spent remediating these defects robs the project team of valuable time, resources, and money that could otherwise be used for further innovation and delivering the highest possible quality product to wow the customer. The occurrence of a large percentage of these defects can be avoided with preventive defect removal strategies. Scott Aziz describes various methods for removing defects during the early design and development phases―long before testing. Methods include requirements-based testing that eliminates 95 percent of requirements defects prior to the coding phase, code reviews and inspections, and establishing model-based test design practices that allow for testing business requirements before any code is developed. Take back and adopt in your environment some of the most effective early defect prevention practices known and practiced in the industry today.
The anonymised slides from an old (but hopefully still relevant) talk on the case for placing a strategic focus on design testability. The material covers the technical, process and organisational considerations arising from such a strategy and is predominantly a summary of the ideas presented in Brett Pettichord's 2001 "Design For Testability' paper available here. The presentation makes a case for why a high level of design testability can be seen as a critical success factor in achieving sustained agility.
YAHDI SANDRA
11453104752
Program Studi S1 Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Sultan Syarif Kasim Riau
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/
Things to keep in mind before starting a test planNexSoftsys
If you are going to start a test plan, then you will know that most of the time in software testing, there is more debate on its quality and plan of activities. Today many things are worth noting, but you have to pay attention to these important things before starting the test plan.
How to Make a Field invisible in Odoo 17Celine George
It is possible to hide or invisible some fields in odoo. Commonly using “invisible” attribute in the field definition to invisible the fields. This slide will show how to make a field invisible in odoo 17.
The Indian economy is classified into different sectors to simplify the analysis and understanding of economic activities. For Class 10, it's essential to grasp the sectors of the Indian economy, understand their characteristics, and recognize their importance. This guide will provide detailed notes on the Sectors of the Indian Economy Class 10, using specific long-tail keywords to enhance comprehension.
For more information, visit-www.vavaclasses.com
The Art Pastor's Guide to Sabbath | Steve ThomasonSteve Thomason
What is the purpose of the Sabbath Law in the Torah. It is interesting to compare how the context of the law shifts from Exodus to Deuteronomy. Who gets to rest, and why?
Synthetic Fiber Construction in lab .pptxPavel ( NSTU)
Synthetic fiber production is a fascinating and complex field that blends chemistry, engineering, and environmental science. By understanding these aspects, students can gain a comprehensive view of synthetic fiber production, its impact on society and the environment, and the potential for future innovations. Synthetic fibers play a crucial role in modern society, impacting various aspects of daily life, industry, and the environment. ynthetic fibers are integral to modern life, offering a range of benefits from cost-effectiveness and versatility to innovative applications and performance characteristics. While they pose environmental challenges, ongoing research and development aim to create more sustainable and eco-friendly alternatives. Understanding the importance of synthetic fibers helps in appreciating their role in the economy, industry, and daily life, while also emphasizing the need for sustainable practices and innovation.
How to Create Map Views in the Odoo 17 ERPCeline George
The map views are useful for providing a geographical representation of data. They allow users to visualize and analyze the data in a more intuitive manner.
2024.06.01 Introducing a competency framework for languag learning materials ...Sandy Millin
http://sandymillin.wordpress.com/iateflwebinar2024
Published classroom materials form the basis of syllabuses, drive teacher professional development, and have a potentially huge influence on learners, teachers and education systems. All teachers also create their own materials, whether a few sentences on a blackboard, a highly-structured fully-realised online course, or anything in between. Despite this, the knowledge and skills needed to create effective language learning materials are rarely part of teacher training, and are mostly learnt by trial and error.
Knowledge and skills frameworks, generally called competency frameworks, for ELT teachers, trainers and managers have existed for a few years now. However, until I created one for my MA dissertation, there wasn’t one drawing together what we need to know and do to be able to effectively produce language learning materials.
This webinar will introduce you to my framework, highlighting the key competencies I identified from my research. It will also show how anybody involved in language teaching (any language, not just English!), teacher training, managing schools or developing language learning materials can benefit from using the framework.
The French Revolution, which began in 1789, was a period of radical social and political upheaval in France. It marked the decline of absolute monarchies, the rise of secular and democratic republics, and the eventual rise of Napoleon Bonaparte. This revolutionary period is crucial in understanding the transition from feudalism to modernity in Europe.
For more information, visit-www.vavaclasses.com
5. What is Formal Technical Review?
• A method involving a structured encounter
in which a group of technical personnel
analyzes or improves the quality of the
original work product as well as the quality
of the method.
6. Why review? We test!
Reviews improve schedule performance.
Cost growth Model.
–Defects are much more expensive to fix the later they are
discovered.
•A defect that isn't discovered until testing can be 100 times
more expensive to repair than if it had been discovered
during a review.
7. Why review? We test!
Reviews reduce rework.
Rework accounts for 44% of dev. cost!
Reqs (1%), Design (12%), Coding (12%), Testing (19%)
Reviews are more productive than testing.
Find more errors in the same amount of time.
Reviews are more effective than testing.
Find errors not possible through testing.
Reviews are training.
8. Why review? Who benefits?
• Formal technical review provides:
– Defect information
– Information on work product and development to
peers.
– Fault likelihood data to testers.
– Product status to management.
9. True FTR is well-defined
• Well-defined process
– Phases (orientation, etc.)
– Procedures (checklists, etc.)
• Well-defined roles
• Well-defined objectives
– Defect removal, requirements gathering, etc.
• Well-defined measurements
– Forms, consistent data collection, etc.
10. FTR is effective quality improvement
• Reviews can find 60-100% of all defects.
• Reviews are technical, not management.
• Review data can assess/improve quality of:
– work product
– software development process
– review process
• Reviews reduce total project cost
• Reviews spread domain knowledge, development
skills
11. Industry Experience with FTR
• Aetna Insurance Company:
– FTR found 82% of errors, 25% cost reduction.
• Bell-Northern Research:
– Inspection cost: 1 hour per defect.
– Testing cost: 2-4 hours per defect.
12. Who, What, and When
• Who decides what should be reviewed?
– Senior technical personnel, project leader
• What should be reviewed?
– Work products with high impact upon project
risks.
– Work products directly related to quality
objectives.
• When should review be planned?
– Specify review method and target work products
in software development plan/quality plan.
13. The range of review practice
TekInspect
Development Method
Non-Cleanroom Cleanroom
FTR
inFTR
Code
Inspection
(Fagan76)
Inspection
(Gilb93)
2-Person
Inspection
(Bisant89)
N-Fold
Inspection
(Martin90)
Walkthrough
(Yourdon89)
Verification-
based
Inspection
(Dyer92)
Active
Design
Reviews
(Parnas85)
FTArm
(Johnson94)
ICICLE
(Brothers90)
Scrutiny
(Gintell93)
CAIS
(Mashayekhi94)
Manual
Tool-Based
Code
Reading
(McConnell93)
Software
Review
(Humphrey90)
Phased Insp.
(Knight93)
14. Families of Review Methods
Walkthroughs
Minimal transparency
Developer training
Quick turnaround
Requirements gathering
Ambiguity resolution
Training
Method Family Typical Goals Typical Attributes
Little/no preparation
Informal process
No measurement
Not FTR!
Technical
Reviews
Formal process
Author presentation
Wide range of discussion
Inspections
Detect and remove all
defects efficiently and
effectively.
Single author
Formal process
Checklists
Measurements
Verify phase
17. Planning
• Objectives
– Gather review package: work product, checklists
– Form inspection team.
– Determine dates for meetings.
• Procedure
– Moderator assembles team and review package.
– Moderator enhances checklist if needed.
– Moderator plans dates for meetings.
– Moderator checks work product for readiness.
– Moderator helps Author prepare overview.
Planning Orientation Preparation Review Mt. Rework Verify
Planning Orientation
19. Preparation
• Objectives
– Find maximum number of non-minor issues.
• Procedure for reviewers:
– Allocate recommended time to preparation.
– Perform individual review of work product.
– Use checklists and references to focus attention.
– Note critical, severe, and moderate issues on
Reviewer Data Form.
Planning Orientation Preparation Review Mt. Rework Verify
20. Example Issue Classification
• Critical
– Defects that may cause the system to hang, crash,
produce incorrect results or behavior, or corrupt user
data.
• Severe
– Defects that cause incorrect results or behavior. Large
and/or important areas of the system is affected.
• Moderate
– Defects that affect limited areas of functionality that
can either be ignored.
• Minor
– Defects that can be overlooked with no loss of
functionality.
21. Example checklist
Checklist for Software Quality Plans
1. Does the plan reference the Tektronix Test Plan process document to be used in this project?
2. Does the plan list the set of measurements to be used to assess the quality of the product?
3. Is a rationale provided for each feature to be tested?
4. According to this document, what features won't be tested? Are any missing? List all below:
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Does the plan provide a rationale for why each of these features will not be tested?
5. How well does the plan describe how tests will be traced back to requirements?
Check one of the following:
Very well Fairly well Poorly No Traceability
6. Refer to the corresponding software development plan. Does the quality plan discuss each of the test
milestones and test transmittal events from this document?
Check all that apply:
I cannot access the software development plan.
The software development plan has no test milestones.
The software development plan has no test transmittal events.
The quality plan has no test milestones.
The quality plan has no test transmittal events.
Both documents include the same set of test milestones and test transmittal events.
22. Example Preparation Data
1. Inspection ID _________ 2. Document: _____________ 3. Name: ________________
4. Critical, Severe, and Moderate Issues
Num Location Severity Chk/Ref Description
_____ _______ ______ ______ ______________________________________________________
_____ _______ ______ ______ ______________________________________________________
_____ _______ ______ ______ ______________________________________________________
_____ _______ ______ ______ ______________________________________________________
_____ _______ ______ ______ ______________________________________________________
5. Effort: min 6. Issue ________ ________ ________ ________ ________
Totals critical severe moderate minor author Q's
7. Preparation Work product has been completely checked.
Objectives All critical, severe, and moderate issues are noted on this form.
All minor issues and author questions are noted on the work product.
23. • Advantages of Reviewer Data Sheet:
– Minor issues are “pre-filtered” from review
meeting, saving meeting time.
– Reviewers articulate issues clearly during
preparation, saving meeting time.
– Preparation statistics gathering simplified.
– Issues can be presented in order of importance.
24. Review Meeting
• Objectives
– Create consolidated, comprehensive listing of non-
minor issues.
– Improve reviewing skill by observing others.
• Procedure
– Moderator requests issues sequentially.
– Reviewers raise issues.
Planning Orientation Preparation Review Mt. Rework Verify
25. Rework
• Objectives
– Assess each issue, determine if it is a defect, and
remove it if necessary.
– Produce written disposition of non-minor issue.
– Resolve minor issues as necessary.
Planning Orientation Preparation Review Mt. Rework Verify
26. Verify
• Objectives
– Assess the (reworked) work product quality.
– Assess the inspection process.
– Pass or fail the work product.
• Procedure for moderator:
– Obtain reworked product and Author Data Sheet.
– Review work product/data sheet for problems.
– Provide recommendation for work product.
– Perform sign-off with reviewers.
– Compute summary statistics for inspection.
– Generate any process improvement proposals.
– Enter review data into quality database.
Planning Orientation Preparation Review Mt. Rework Verify
28. Critical Success Factor:
Checklists
• Checklists guide reviewers to areas prone to
defects.
• Checklists may be stated as a yes/no
question:
• Checklists can also stimulate mental
modelling:
• Checklists should be combined with general
analysis.
– Don’t trust checklists to be comprehensive!
29. Critical Success Factor:
Effective Preparation
• Effective preparation requires both:
– Comprehension: the nature of the entire document.
– Analysis: inter-document consistency and adequacy.
• Focus on:
– What is present but not adequate.
– What is missing but should be there.
– What unique skills and experiences can you bring to
bear on the work product?
• Allocate enough time to prepare!
– Make multiple passes over document.
– Don’t prepare right before the review.
30. Critical Success Factor:
Measurement
• The goal of Inspection is to detect and remove all defects
efficiently and completely.
• We measure:
– Time spent on each phase.
– Number of issues of each type discovered.etc.
• Analysis over time suggests:
– New and better checklist items.
– Improvements to inspection process, by identifying poor quality review.
– Improvements to software development process, by identifying poor quality
work products.
– Improvements to standards.