Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.

Slides:



Advertisements
Similar presentations
Requirements Specification and Management
Advertisements

Kai H. Chang COMP 6710 Course NotesSlide ES- 1 Auburn University Computer Science and Software Engineering Course Notes : Examining the Specification Computer.
More CMM Part Two : Details.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
Static Technique. Static Technique - Review  A way of testing software work products  Program code, requirement spec., design spec.  Test plan, test.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
1 reviews8 Software Reviews, Walkthroughs, and Inspections The standard technique to ensure quality in software development.
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
Overview Lesson 10,11 - Software Quality Assurance
Week 7: Requirements validation Structured walkthroughs Why have walkthroughs When to have walkthroughs Who participates What procedures are helpful Thoughtless.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
SE 555 Software Requirements & Specification Requirements Validation.
 QUALITY ASSURANCE:  QA is defined as a procedure or set of procedures intended to ensure that a product or service under development (before work is.
Stoimen Stoimenov QA Engineer QA Engineer SitefinityLeads,SitefinityTeam6 Telerik QA Academy Telerik QA Academy.
Verification and Validation
1 Software Inspections and Walkthroughs Author: A. Frank Ackerman Presented by Cynthia Johnson EEL6883.
Design Reviews Peer Reviews. Agenda Peer Reviews Participants of Peer Review Preparation for a Peer Review Session The Peer Review Session Post-peer Review.
SystematicSystematic process that translates quality policy into measurable objectives and requirements, and lays down a sequence of steps for realizing.
1CMSC 345, Version 4/04 Verification and Validation Reference: Software Engineering, Ian Sommerville, 6th edition, Chapter 19.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Examining the Software Specification [Reading assignment: Chapter 4, pp ]
Introduction to Software Quality Assurance (SQA)
Software Inspections and Walkthroughs By. Adnan khan.
CHEP2000 February 2000 Impact of Software Review and Inspection Doris Burckhart CERN ATLAS DAQ/EF-1 Back-end software.
Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations The.
Software Testing Life Cycle
Software Reviews. Introduction/Motivation When creating written documents, it is a good idea to have someone else proof read your work. Oftentimes an.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality Part 4:
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Formal and Informal Peer Reviews
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
Phil Cronin Anne Hill Allen Schones CIS841 Summer on Campus 1998 IN-PROCESS INSPECTIONS FOR OBJECT ORIENTED DESIGNS.
Lecture #9 Project Quality Management Quality Processes- Quality Assurance and Quality Control Ghazala Amin.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.
Lecture 7: Requirements Engineering
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
T Iteration Demo Group name [PP|I1|I2] Iteration
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
1 Quality Attributes of Requirements Documents Lecture # 25.
Unit III Static Testing. static testing Testing of a component or system at requirements or implementation level without execution of any software, e.g.,
Inspection and Review The main objective of an Inspection or a Review is to detect defects. This activity and procedure was first formalized by Mike Fagan.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Advances In Software Inspection
Mahindra Satyam Confidential Quality Management System Software Defect Prevention.
Management of Software Project CSM Review By:Nafas.
Peer Review Presented by : Basker George. Peer ( 同等的人 ) Review( 回顾 ) During the development of software, defects are inevitably ( 不可避免 ) injected. Defect.
T Project Review Wellit I1 Iteration
Chapter 4-Static Testing Techniques Types of Reviews Review Process Static analysis using tools.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
Software Reviews Ashima Wadhwa.
Software Project Configuration Management
Software Quality Control and Quality Assurance: Introduction
CIS 375 Bruce R. Maxim UM-Dearborn
Software Configuration Management (SCM)
Peer Review and Testing
Verification and Validation
Verification and Validation
Inspection and Review The main objective of an Inspection or a Review is to detect defects. (Not for Giving Alternative Solutions) This activity and procedure.
Examining the Specification
QA Reviews Lecture # 6.
Software Reviews.
3. Software Quality Management
Presentation transcript:

Damian Gordon

 Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.  Dynamic Testing is the testing of software by executing the software of either a component or system.  Static Testing and Dynamic Testing are complementary methods and tend to find different types of defects effectively and efficiently.

 Static Testing detects defects such as deviations from standards, missing requirements, design defects, non- maintainable code and inconsistent interface specifications.  Dynamic Testing detects defects such as checking if outputs from the expected values.

 One key approach in Static Testing is the Review Process.  Reviews can find defects, are informational, communicational, and educational.  Participants in the review learn the content of the software systems, the role of their own work, help planning for future stages of the work.  Reviews often represent milestones, and support the establishments of a baseline for the software product.

 The type and quantity of defects found during the review stage can help focus the testing process.  In some cases customers or users attend the review process and provide feedback to the developers and document authors.  Studies have shown the reviews significantly increase productivity and product quality.

 They can be either informal or formal.  The formality of the review process is related to factors such as the maturity of the development process, any legal or regulatory requirements or the need for an audit trail.  In practice most reviews are informal.  A two-person team can conduct an informal review, as the developer/author can get a colleague to review the code and documentation.

 Phases of a Formal Review 1.Planning 2.Kick-Off 3.Preparation 4.Review Meeting 5.Rework 6.Follow-up

 1. Planning  The authors/developers request a review.  A moderator is assigned – this is the leader of the review process.  The project planning needs to incorporate time to undertake the review.  The planning must start with deciding an entry criteria to ensure that document is ready for review.

 1. Planning  Entry Criteria  The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. Test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria.

 1. Planning  Minimum set of criteria for performing entry check: ◦ A short check of a product sample by the moderator does not reveal a large number of defects, e.g. After 30 minutes of checking, no more than 3 major defects are found in a single page or fewer than 10 major defects in total in a set of 5 pages. ◦ The document to be reviewed is available with line numbers. ◦ The document has been cleaned up by running any automated checks that apply. ◦ References needed for the inspection are stable and available. ◦ The document author is prepared to join the review team and feels confident with the quality of the document.

 1. Planning  The review will focus on a few different things: ◦ Focus on higher-level documents, e.g. Does the design comply to the requirements ◦ Focus on standards, e.g. Internal consistency, clarity, naming conventions, templates ◦ Focus on related documents at the same level, e.g. Interfaces between software functions ◦ Focus on usage, e.g. For testability and maintainablity

 2. Kick-Off  The review starts with a kick-off meeting, to make sure everyone is on the same wavelength regarding the document under review.  The meeting consists of a short introduction to the objectives of the review and the documents.  Role assignments, checking rate, the pages to be checked, process changes and possible other questions are discussed at this meeting.

 3. Preparation  Participants identify defects, questions, and comments, according to their understanding of the document and their role.  A checking rate is decided, which is the number of pages checked per hour, usually about 5 to 10 pages per hour, depending on complexity.

 4. Review Meeting  Usually made up of the following phases: ◦ Logging phase ◦ Discussion phase ◦ Decision phase

 4. Review Meeting  Logging Phase:  The issues that have been identified in the Preparation stage are logged.  To ensure progress and efficiency, no real discussion is allowed during the logging phase.  Each defect is logged with a severity: ◦ Critical: defects will cause downstream damage. ◦ Major: defects could cause downstream damage. ◦ Minor: defects are not likely to cause downstream damage.

 4. Review Meeting  Discussion Phase:  Each of the defects that require discussion are discussed, with a chairman preventing discussions from getting too personal.

 4. Review Meeting  Decision Phase:  At the end of the discussion phase, a decision is taken about the document under review. If the number of defects found per page exceeds a certain level, the document may need to be reworked, and reviewed again.

 5. Rework  Based on the defects detects, the author will improve the document under review, step- by-step.

 Always, every, all, none, never, … (absolutely sure?)  Certainly, therefore, clearly, obviously, customarily, most, … (persuasion lingo)  Some, sometimes, often, usually, ordinarily, customarily, most, … (vague)  etc., and so forth, and so on, such as, … (not testable)  Good, fast, cheap, efficient, small, stable, … (unquantifiable)  Handled, processed, rejected, skipped, eliminated…  If … then … (missing else)

 Roles and Responsibilities  The moderator  The author  The scribe  The reviewers  The manager

 Roles and Responsibilities  The moderator serves as the review leader, they determine the type of review, approach and the composition of the review team.  The moderator performs the entry check, and the follow-up on the rework.  The moderator also schedules meetings, disseminates documents, leads discussions and stores relevant data.

 Roles and Responsibilities  The author writes the original document and seeks to improve the quality of the document by working with others.

 Roles and Responsibilities  The scribe records all of the defects during the logging meetings.

 Roles and Responsibilities  The reviewers (also called checkers and inspectors) check the documents for defects.  Reviewers are chosen to represent different perspectives in the review.

 Roles and Responsibilities  The manager decides on the execution of reviews and determines whether review process objectives have been met.

 Types of Reviews  Walkthrough  Technical Review  Inspection

 Types of Reviews  Walkthrough  The author guides the review team through the document, to achieve a common understanding and gather feedback.  This means the author does a range of preparation, and the review team don’t need to do a detailed study before the meeting.  A walkthrough is especially useful for higher-level documents, like requirements specifications and architectural documents.

 Types of Reviews  Technical Review  This approach focuses on developing a consensus about the technical content of the document.  Defects are found by technical experts, who focus on the content of the document (as opposed to considering any relevant legislation and standards, referenced documents, and intended readership).

 Types of Reviews  Inspection  This approach is the most formal review type.  The document is inspected thoroughly be the reviews before the meeting, comparing the work product with its sources and other referenced documents, and using rules and checklists.  The defects found are logged and any discussion is postponed until the discussion phase.  This makes the inspection meeting a very efficient meeting.

 Let’s do one.