Testing Close to and Post-Release: System, Acceptance, and Regression Testing
|
|
- Anthony Walker
- 6 years ago
- Views:
Transcription
1 Testing Close to and Post-Release: System, Acceptance, and Regression Testing CSCE Lecture 23-04/05/2016
2 The V-Model of Development Requirements Elicitation System Specification Acceptance Test Plan System Integration Test Plan Regression Test Plan Acceptance Testing Operation and Maintenance Architectural Design System Integration Testing Detailed Design Subsystem Integration Testing Unit Development and Testing Gregory Gay CSCE Spring
3 Final Testing Stages All concerned with behavior of the system as a whole, but for different purposes. System Testing Verification of the completed system against the specifications. Acceptance Testing Validation against the user s expectations. Regression Testing Ensuring that the system continues to work as expected when it evolves. Gregory Gay CSCE Spring
4 Verification and Validation Activities that must be performed to consider the software done. Verification: The process of proving that the software conforms to its specified functional and non-functional requirements. Validation: The process of proving that the software meets the customer s true requirements, needs, and expectations. Gregory Gay CSCE Spring
5 System and Acceptance Testing System Testing Checks system against specification. Performed by developers and professional testers. Verifies correctness and completion of the product. Acceptance Testing Checks system against user needs. Performed by customers, with developer supervision Validates usefulness and satisfaction with the product. Gregory Gay CSCE Spring
6 Regression Testing Systems continue to evolve post-release. Patches to newly-discovered faults. New features. Adaptations to new hardware/software dependencies (OS). Rechecks test cases passed by previous production systems. Guards against unintended changes. Gregory Gay CSCE Spring
7 System Testing
8 Unit Testing Test cases derived from module specifications in design documents. Requires complex scaffolding to execute incomplete dependencies (stubs), simulate execution environment (drivers), and judge test results (oracles). Focus is on behavior of individual modules. Gregory Gay CSCE Spring
9 Integration/Subsystem Testing Test cases derived from architecture and design specifications. Requires scaffolding, but can reuse some from unit testing. Fewer stubs and drivers required, as classes are tested together. (depends on integration order and architecture) Focus is on module integration and interactions. Gregory Gay CSCE Spring
10 System Testing Test cases derived from requirement specification. Requires no detail of the code. Tests should be designed before code is written. Does not need scaffolding, except for oracles. Sometimes operates in a simulated environment. Focus on system functionality and further integration errors. Gregory Gay CSCE Spring
11 System Testing Last hurdle before releasing a system. Final chance to find faults. If all tests pass, the system is free of faults. Test cases should be developed independently of unit and subsystem tests. Design errors often infect unit test design. Introduces a source of blindness. System tests do not require details of the source code. And are able to detect design flaws as a result. Gregory Gay CSCE Spring
12 Who Should Test? Developer Understands the system, but Tends to test gently and is driven by deadlines. Independent Tester Needs to learn the system, but Will attempt to break it. Better able to focus on quality. Gregory Gay CSCE Spring
13 System Testing Systems are developed as interacting subsystems. Once units and subsystems are tested, the combined system must be tested. Advice about interface testing still important here (you interact with a system through some interface). Two important differences from subsystem testing: Reusable components (off-the-shelf systems) need to be integrated with the newly-developed components. Components developed by different team members or groups need to be integrated. Gregory Gay CSCE Spring
14 Non-functional Properties Properties desired of the final system not related to functional correctness (f(a) = b) must be tested at the system level. Performance, reliability, safety, security. Requires ability to measure and assess fulfillment of the property. Depends on both the system and its environment and use. In some cases, standard measurements exist. In others, more difficult to capture the requirement in a test. Gregory Gay CSCE Spring
15 Non-functional Properties US HIPAA regulations on software using medical records: A covered entity must reasonably safeguard protected health information from any intentional or unintentional use or disclosure that is in violation of the standards, implementation specifications, or other requirements of this subpart. Hard to measure satisfaction. Requires context: Personnel that have access, how unauthorized personnel are prevented from gaining access. Gregory Gay CSCE Spring
16 Non-functional Properties Properties must be defined in context. Performance standards must consider the operating environment. Under what circumstances must a particular threshold be met? Real-time system must meet computation and response deadlines. Requires definition of event frequency and minimum input arrival times. Generally cannot use testing to show that a property is met in all configurations. Gregory Gay CSCE Spring
17 Non-functional Properties Not all properties are amenable to traditional testing techniques. Inspection and analysis can help with some. Security properties are assessed by teams of users that attempt to gain access. Security is a property of a larger system and environment that one piece of software is a small part of. Consider safety of the whole system, and how this piece of software fits into that environment. Look for vulnerabilities in each piece of software. Gregory Gay CSCE Spring
18 Acceptance Testing
19 Acceptance Testing Once the system is internally tested, it should be placed in the hands of users for feedback. Users must ultimately approve the system. Many faults do not emerge until the system is used in the wild. Alternative operating environments. More eyes on the system. Wide variety of usage types. Acceptance testing allows users to try the system under controlled conditions. Gregory Gay CSCE Spring
20 User-Based Testing Types Three types of user-based testing: Alpha Testing A small group of users work closely with development team to test the software. Beta Testing A release of the software is made available to a larger group of interested users. Acceptance Testing Customers decide whether or not the system is ready to be released. Gregory Gay CSCE Spring
21 Alpha Testing Users and developers work together. Users can identify problems not apparent to the development team. Developers work from requirements, users have their own expectations. Takes place under controlled conditions. Software is usually incomplete or untested. Power users and customers who want early information about system features. Agile processes advocate for customer as a team member Gregory Gay CSCE Spring
22 Beta Testing Early build made available to a larger group of volunteers and customers. Software is used under uncontrolled conditions, hardware configurations. Important if the system will be sold to any customer. Discovers interaction problems. Can be a form of marketing. Should not replace traditional testing. Gregory Gay CSCE Spring
23 Acceptance Testing Formal validation activity between developer and customer. Software is taken to a group of users that try a set of scenarios under supervision. Scenarios mirror the typical system use cases. Users provide feedback and decide whether the software is acceptable for each scenario. Users ultimately decide whether the software is ready for release. Developers may negotiate with users. Gregory Gay CSCE Spring
24 Acceptance Testing Stages Define acceptance criteria Work with customers to define how validation will be conducted, and the conditions that will determine acceptance. Plan acceptance testing Decide resources, time, and budget for acceptance testing. Establish a schedule. Define order that features should be tested. Define risks to testing process. Derive acceptance tests. Design tests to check whether or not the system is acceptable. Test both functional and non-functional characteristics of the system. Gregory Gay CSCE Spring
25 Acceptance Testing Stages Run acceptance tests Users complete the set of tests. Should take place in the same environment that they will use the software. Some training may be required. Negotiate test results It is unlikely that all of the tests will pass the first time. Developer and customer negotiate to decide if the system is good enough or if it needs more work. Reject or accept the system Developers and customer must meet to decide whether the system is ready to be released. Gregory Gay CSCE Spring
26 Qualitative Process Results may vary based on the user surveyed and environmental factors. Software may need to be accepted regardless of users preferences if deadline is strict. May be used as an excuse to reject a project. Users should be typical Usually interested volunteers. How users interact with a beta may not match the real system. May not catch faults that normal users will see. Gregory Gay CSCE Spring
27 Usability A usable product is quickly learned, allows users to work efficiently, and can be used without frustration. Must be evaluated through user-based testing. Objective criteria: Time and number of operations to perform tasks. Frequency of user error. Subjective criteria: Satisfaction of users. Can be evaluated throughout lifecycle. Gregory Gay CSCE Spring
28 Usability Testing Steps Inspecting specifications: Checklists based on prior experience. Testing early prototypes: Bring in end users to: Explore mental models (exploratory testing) Evaluate alternatives (comparison testing) Validate usability. May involve mockup GUIs, not working software. System and Acceptance Testing: Evaluate incremental builds, compare against competitors, check against compatibility guidelines. Gregory Gay CSCE Spring
29 Exploratory Testing Explore the mental model of end users. Early in design stage, ask users how they would like to interact with the system. Look for common answers from users. If conflicts, try to combine elements of answers. Larger sample sizes will yield better results. Consider all groups of stakeholders. Some stakeholders will have different usage patterns from others. Gregory Gay CSCE Spring
30 Validation Testing Used to assess overall usability. Identifies difficulties and obstacles encountered while using the system. Measures error rate, clicks/time to perform a task. Preparation phase: Define objectives for the session, identify items to be tested, select population, plan actions. Execution phase: Users monitored as they execute planned actions. Analysis phase: Results evaluated, software changes planned. Gregory Gay CSCE Spring
31 Validation Testing Activities should be based on typical use cases of expected features. Intent is to ensure normal use is optimal, not to search for new faults. Users should perform tasks independently. Actions are recorded through tracking software. Comments and impressions are collected with postactivity questionnaires. Consider accessibility needs. Font size, color choices, audio guidance. Gregory Gay CSCE Spring
32 Regression Testing
33 Software Lifecycle Initial Development Specification Implementation Evolution R4 R3 R2 R1 Operation Verification & Validation Servicing Phaseout Gregory Gay CSCE Spring
34 Software Maintenance Fault Repairs Changes made in order to correct coding, design, or requirements errors. Environmental Adaptations Changes made to accommodate changes to the hardware, OS platform, or external systems. Functionality Addition New features are added to the system to meet new user requirements. Gregory Gay CSCE Spring
35 Maintenance is Hard It is harder to maintain than to write new code. Must understand code written by another developer, or code that you wrote long ago. Creates a house of cards effect. Developers tend to prioritize new development. New code must be tested. Existing code must also be retested. Gregory Gay CSCE Spring
36 System Regression System evolution may change existing functionality in unforeseen ways. When a new version no longer works as expected, it regresses with respect to tested functionality. A basic quality requirement is that new versions are non-regressive - if we tested it and it works, it should continue to work. Regression testing is used to detect regressive code. Gregory Gay CSCE Spring
37 Regression Testing Basic idea: when changes have been made, re-execute tests that were used to verify the original code. Not as simple as it sounds: When do you execute regression tests? On check-in? Before patch is publicly released? Can you afford to execute all tests? The number will grow as the system expands. Can you actually execute all tests? Do you need to? Are some tests obsolete? Gregory Gay CSCE Spring
38 Test Case Maintenance Test suites must be maintained over time. Obsolete tests should be removed. Tests involving requirements, features, classes, or interfaces that no longer exist or have been modified. Redundant tests should be identified. Tests that cover the same structural elements, input partitions, other test goals. May be introduced to test changed code, or by concurrently-working testers. Can still be executed, but may not be needed. Gregory Gay CSCE Spring
39 Regression Test Selection The number of tests to reexecute may be very large (and grows over time). Not all tests need to be re-executed. Changes only affect part of the system. Regression testing costs can be reduced by prioritizing the set of test cases. Select a subset of tests relevant to the changes introduced. Weigh those tests higher than those unlikely to expose faults. Techniques based on code and specifications. Choose a cut-off based on testing budget. Gregory Gay CSCE Spring
40 Code-Based Test Selection Select a test case for execution if it exercises a portion of the code modified (or likely to be affected by a change). Control-based selection: Maintain a record of the CFG blocks executed by each test. Compare the structure of the old and new versions. Tests that exercise added, modified, or deleted elements are prioritized. Can be based on control or data flow. Gregory Gay CSCE Spring
41 Example Version 1: Version 2: } else if (c == % ){ int digit_high =.. } ++dptr; ++eptr; } } else if (c == % ){ if(!*(eptr + 1) && *(eptr + 2)){ ok = 1; return; } int digit_high =.. } if(! isascii(*dptr)){ *dptr =? ; ok=1; } ++dptr; ++eptr; } Gregory Gay CSCE Spring
42 Example A B M L C D E Z: *dptr =? ; ok=1; W: if(! isascii (*dptr)){ F X: if(!*(eptr + 1) && * (eptr + 2)){ Y: ok = 1; return; G H I Gregory Gay CSCE Spring
43 Example A ID Input Path B M C D E F X Y G Z H I W L 1 A B M 2 test+case%1dadequacy A B C D F L B M 3 adequate+test% 0Dexecution%7U A B C D F L B M 4 %3D A B C D G H L B M 5 %A A B C D G I L B M Base case: Re-execute all tests Corrective that pass through Changes node Only: D and Ignores proceed new towards features, G, and and all only considers tests that reach corrective node patches. L. 6 a+b A B C D F L B C E L B C D F L B M 7 test A B C D F L B C D F L B C D F L B M 8 +%0D+%4J A B C E L B C D G I L B M 9 first+test%9ktest%k9 A B C D F L B M Gregory Gay CSCE Spring
44 Data-Based Test Selection New code can introduce new DU pairs and remove existing pairs. Re-execute test cases that execute DU pairs in the original program that were deleted or modified in the revised program. Also select test cases that execute a conditional statements modified in the revision. Changed predicates can affect DU paths. Gregory Gay CSCE Spring
45 Example A Variable Definitions Uses B M C D E F X Y G Z H I W L *eptr X eptr X *dptr Z W dptr Z, W ok Y, Z Gregory Gay CSCE Spring
46 Selective Execution When a regression suite is too large, we must reduce the number of tests executed. Techniques predict usefulness of tests: Elements covered. History of effectiveness. High priority tests will be selected more often than low priority tests. Eventually, all tests will be selected. However, at varying frequencies. Efficient rotation in which the cases most likely to reveal faults will be selected more often. Gregory Gay CSCE Spring
47 Selective Execution Schema Execution History Schema: Simple strategy. Recently executed tests are given low priority. Cases not recently executed are given high priority. Often used to weight along with correlation to changed elements. Fault-Revealing Priority Schema: Test cases that have recently revealed faults are prioritized. Faults are not evenly distributed, but tend to cluster around particular functionality/units in the code. Not all faults may have been fixed. Gregory Gay CSCE Spring
48 Selective Execution Schema Structural Priority Schema: Weight tests by the number of elements covered. Statements, branches, conditions, etc. Weight each element by when it was last executed. Prioritize tests that cover a large number of elements that have not recently been executed. Ensures that all structural elements are eventually recovered, especially if they have not recently been tested. Gregory Gay CSCE Spring
49 We Have Learned Late-stage testing techniques are concerned with behavior of the system as a whole, but for different purposes. System Testing Verification of the completed system against the specifications. Acceptance Testing Validation against the user's expectations. Regression Testing Ensuring that the system continues to work as expected when it evolves. Gregory Gay CSCE Spring
50 Next Time When is software ready for release? Measuring dependability Some material in Chapter 4 Homework: Assignment 4 - due tonight! Assignment 5 is out! Presentations - April 19, 21, 26, May 3 Gregory Gay CSCE Spring
SWE 211 Software Processes
SWE 211 Software Processes These slides are designed and adapted from slides provided by Software Engineering 9 /e Addison Wesley 2011 by Ian Sommerville 1 Outlines Software process models Process activities
More informationIntroduction to software testing and quality process
Introduction to software testing and quality process Automated testing and verification J.P. Galeotti - Alessandra Gorla Engineering processes Engineering disciplines pair construction activities activities
More informationLectures 2 & 3. Software Processes. Software Engineering, COMP201 Slide 1
Lectures 2 & 3 Software Processes Software Engineering, COMP201 Slide 1 What is a Process? When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks
More informationSoftware System Integration. Chapter 8 Software testing 1
Software System Integration Chapter 8 Software testing 1 Overview What is system integration? Integration process description Integration testing System Integration Checklist Chapter 8 Software testing
More informationMSc Software Testing and Maintenance MSc Prófun og viðhald hugbúnaðar
MSc Software Testing and Maintenance MSc Prófun og viðhald hugbúnaðar Fyrirlestrar 25 & 26 The SWEBOK Chapter on Software Testing IEEE http://www.swebok.org/ 19/10/2005 Dr Andy Brooks 1 Repeat after Andy:
More informationBased on Software Engineering, by Ian Sommerville Coherent sets of activities for specifying, designing, implementing and testing software systems
Software Processes Based on Software Engineering, by Ian Sommerville Coherent sets of activities for specifying, designing, implementing and testing software systems Slide 1 Objectives To introduce software
More informationTesting 2. Testing: Agenda. for Systems Validation. Testing for Systems Validation CONCEPT HEIDELBERG
CONCEPT HEIDELBERG GMP Compliance for January 16-17, 2003 at Istanbul, Turkey Testing for Systems Validation Dr.-Ing. Guenter Generlich guenter@generlich.de Testing 1 Testing: Agenda Techniques Principles
More informationOn the management of nonfunctional requirements
- modulo B On the management of nonfunctional requirements Dr Tullio Vardanega European Space Research and Technology Centre and University of Padua TU Delft, 12 November 2001 Outline of the talk What
More informationBook Outline. Software Testing and Analysis: Process, Principles, and Techniques
Book Outline Software Testing and Analysis: Process, Principles, and Techniques Mauro PezzèandMichalYoung Working Outline as of March 2000 Software test and analysis are essential techniques for producing
More informationTesting. CxOne Standard
Testing CxOne Standard CxStand_Testing.doc November 3, 2002 Advancing the Art and Science of Commercial Software Engineering Contents 1 INTRODUCTION... 1 1.1 OVERVIEW... 1 1.2 GOALS... 1 1.3 BACKGROUND...
More informationCMPT 275 Software Engineering
CMPT 275 Software Engineering Software life cycle 1 Software Life Cycle Sequence of processes completed as a software project moves from inception to retirement At beginning of project development, choose
More informationLecture 1: Processes, Requirements, and Use Cases
Lecture 1: Processes, Requirements, and Use Cases 1 Development Processes Early Days: evolve a system Build and fix Leads to chaos Need for intelligent design Waterfall Model Requirements, Design, Code,
More informationBCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2
BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 Friday 30 th September 2016 - Morning Answer any THREE questions
More informationSoftware Engineering Lecture 5 Agile Software Development
Software Engineering Lecture 5 Agile Software Development JJCAO Mostly based on the presentation of Software Engineering, 9ed Exercise Describe the main activities in the software design process and the
More informationThe software process
Software Processes The software process A structured set of activities required to develop a software system Specification; Design; Validation; Evolution. A software process model is an abstract representation
More informationSoftware Development Life Cycle:
Software Development Life Cycle: The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software
More informationAgile Tutorial for the Senior Project Class School of Computing and Information Sciences Florida International University
Agile Tutorial for the Senior Project Class School of Computing and Information Sciences Florida International University What is Agile? In simple terms, Agile is a collection of ideas to guide both the
More informationObjectives. Rapid software development. Topics covered. Rapid software development. Requirements. Characteristics of RAD processes
Objectives Rapid software development To explain how an iterative, incremental development process leads to faster delivery of more useful software To discuss the essence of agile development methods To
More informationConfiguration Management
Configuration Management Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Outline Introduction SCM Activities SCM Process 2 2 Software Configuration Management Definition A set of management disciplines
More informationFunctional Testing. CSCE Lecture 4-01/21/2016
Functional Testing CSCE 747 - Lecture 4-01/21/2016 How do you come up with test cases? Test Plans Plan for how we will test the system. What is being tested (units of code, features). When it will be tested
More informationVolume 8, No. 1, Jan-Feb 2017 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at
Volume 8, No. 1, Jan-Feb 2017 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at www.ijarcs.info A Study of Software Development Life Cycle Process Models
More informationIdentification of. 2 (25) - SOFTWARE ARCHITECTURE ATAM: Method for Architecture Evaluation - Sven Arne Andreasson - Computer Science and Engineering
ATAM: Method for Architecture Evaluation ATAM Focuses on quality attribute requirements. Critical to have precise characterizations for each quality attribute. Attribute-Based Architectural Styles The
More informationISTQB Sample Question Paper Dump #11
ISTQB Sample Question Paper Dump #11 1. Which of the following is true a. Testing is the same as quality assurance b. Testing is a part of quality assurance c. Testing is not a part of quality assurance
More informationThis tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping.
i About the Tutorial SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a series of planned activities to develop or alter the Software Products. This tutorial will give
More informationVectorCAST Presentation AdaEurope 2017 Advanced safety strategies for DO178C certification Massimo Bombino, MSCE
VectorCAST Presentation AdaEurope 2017 Advanced safety strategies for DO178C certification Massimo Bombino, MSCE Vector Software, Inc. > Software Quality Overview QUALITY HAZARDS IN AVIONICS INDUSTRY 1.
More informationSoftware Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1
Software Processes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be
More informationIntegration and Testing
Integration and Testing 1 Today Software Quality Assurance Integration Test planning Types of testing Test metrics Test tools 2 Deliverables by Phase Possible Deliverables by Phase Concept Document Statement
More informationA Paradigm Shift for Dispatch Consoles From hardware consoles to a licensed, evergreen software platform
A Paradigm Shift for Dispatch Consoles From hardware consoles to a licensed, evergreen software platform By Michael Branning, CEO. Dispatch console operators in the 1950 s and 1960 s operated radio dispatch
More informationIntroduction to Software Engineering
UNIT I SOFTWARE PROCESS Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, objects oriented) -system engineering computer
More informationInspect what you expect.
Introduction Inspect what you expect. - W. Edwards Deming Unlike call monitoring, in which the scenario of the call is dependent on the caller, mystery shopping allows managers to present employees with
More informationSoftware Processes. Objectives. Topics covered. The software process. Waterfall model. Generic software process models
Objectives Software Processes To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
More informationCHALLENGES (BARRIERS) IN ADOPTING THE ELECTRONIC COMMERCE SYSTEM IN LIC OF INDIA
CHAPTER-6 CHALLENGES (BARRIERS) IN ADOPTING THE ELECTRONIC COMMERCE SYSTEM IN LIC OF INDIA 6.1 Introduction : e-insurance is the application of Internet and related technologies to the production and distribution
More information03. Perspective Process Models
03. Perspective Process Models Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 Prescriptive Process Models advocates an orderly approach to software
More informationObjectives. The software process. Topics covered. Waterfall model. Generic software process models. Software Processes
Objectives Software Processes To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
More informationSample Exam ISTQB Agile Foundation Questions. Exam Prepared By
Sample Exam ISTQB Agile Foundation Questions Exam Prepared By November 2016 1 #1 Which of the following is the correct pairing according to the Agile Manifesto statement of values? a. Individuals and Interactions
More informationTopics covered. Software process models Process iteration Process activities The Rational Unified Process Computer-aided software engineering
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
More informationIIBA Global Business Analysis Core Standard. A Companion to A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 3
IIBA Global Business Analysis Core Standard A Companion to A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 3 International Institute of Business Analysis, Toronto, Ontario, Canada.
More informationIntroduction of RUP - The Rational Unified Process
Introduction of RUP - The Rational Unified Process Jong-Hoon Lee Dependable Software Laboratory Konkuk University References Textbook: The Rational Unified Process Made Easy A Practitioner s Guide to the
More information0 Introduction Test strategy A Test Strategy for single high-level test B Combined testing strategy for high-level tests...
TPI Automotive Test Process Improvement Version: 1.01 Author: Sogeti Deutschland GmbH Datum: 29.12.2004 Sogeti Deutschland GmbH. Version 1.01 29.12.04-1 - 0 Introduction... 5 1 Test strategy...10 1.A Test
More informationThe IBM Rational Software Development Platform
IBM Software Group The IBM Rational Software Development Platform An overview Marc Haeverans marc.haeverans@be.ibm.com 2006 IBM Corporation Agenda The Challenge Software Development and SOA Rational Software
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2014/2015 Dr. Sebastian Adam Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects
More informationCHAPTER 2 LITERATURE SURVEY
10 CHAPTER 2 LITERATURE SURVEY This chapter provides the related work that has been done about the software performance requirements which includes the sub sections like requirements engineering, functional
More informationRequirements Engineering
Requirements Engineering Professor Ray Welland Department of Computing Science University of Glasgow E-mail: ray@dcs.gla.ac.uk The Importance of Requirements Identifying (some) requirements is the starting
More informationSuccessful Service Virtualization
Technical Brief Successful Service Virtualization An introduction to how Service Virtualization can help IT to remain agile and deliver software faster at lower risk and cost IT is constantly evolving
More informationNote 10: Software Process
Computer Science and Software Engineering University of Wisconsin - Platteville Note 10: Software Process Yan Shi Lecture Notes for SE 3330 UW-Platteville Based on Pressman Chapter 2 & 3 Software Process
More informationAUTOMOTIVE SPICE v3.1 POCKET GUIDE
EXTENDED VDA SCOPE ASPICE v3.1 AUTOMOTIVE SPICE v3.1 POCKET GUIDE 4 5 6 7 8-9 10 11-13 14-15 16-19 20-43 44-49 50-51 52-69 70-93 94-103 104-105 106 Automotive SPICE at a glance Automotive SPICE application
More informationPOINTS OF DEFECT CREATION
POINTS OF DEFECT CREATION SPEEDING DETECTION AND CORRECTION IN PRODUCT DEVELOPMENT Authors: Shankar Krishnamoorthy Krishna Sivaramakrishnan Aparna Venkateshwaran oftware Product development methodologies
More informationSoftware System Integration. Chapter 8 Software testing 1
Software System Integration Chapter 8 Software testing 1 Overview What is system integration? Integration process description Integration testing System Integration Checklist Chapter 8 Software testing
More informationEvolutionary Differences Between CMM for Software and the CMMI
Evolutionary Differences Between CMM for Software and the CMMI Welcome WelKom Huan Yín Bienvenue Bienvenido Wilkommen????S???S??? Bienvenuto Tervetuloa Välkommen Witamy - 2 Adapting an An Integrated Approach
More informationSoftware Development Life Cycle (SDLC) Tata Consultancy Services ltd. 12 October
Software Development Life Cycle (SDLC) Tata Consultancy Services ltd. 12 October 2006 1 Objectives (1/2) At the end of the presentation, participants should be able to: Realise the need for a systematic
More informationIntroduction and Key Concepts Study Group Session 1
Introduction and Key Concepts Study Group Session 1 PD hours/cdu: CH71563-01-2018 (3 hours each session) 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters
More informationPertemuan 2. Software Engineering: The Process
Pertemuan 2 Software Engineering: The Process Collect Your Project Topic What is Software Engineering? Software engineering is the establishment and sound engineering principles in order to obtain economically
More informationQuality Assurance Plan D9.1.1
Quality Assurance Plan D9.1.1 Deliverable Number: D9.1.1 Contractual Date of Delivery: month 3 Actual Date of Delivery: 27/07/2001 Title of Deliverable: Quality Assurance Plan Work-Package contributing
More informationRapid software development
Rapid software development 이동아 This lecture note is based on materials from Ian Sommerville 2006. Objectives To explain how an iterative, incremental development process leads to faster delivery of more
More informationCSV Inspection Readiness through Effective Document Control. Eileen Cortes April 27, 2017
CSV Inspection Readiness through Effective Document Control Eileen Cortes April 27, 2017 Agenda Background CSV Readiness CSV and Change Management Process Inspection Readiness Do s and Don ts Inspection
More informationISO 9001: 2000 (December 13, 2000) QUALITY MANAGEMENT SYSTEM DOCUMENTATION OVERVIEW MATRIX
In completing your Documented Quality Management System Review, it is important that the following matrix be completed and returned to us as soon as possible. This will save time during the review and
More informationSoftware Quality Factors
Software Quality Factors The need for a comprehensive software quality requirements There are some characteristic common : All the software projects satisfactory fulfilled the basic requirements for correct
More informationVolere Requirements: How to Get Started
Requirements: How to Get Started Since its introduction in 1995, the approach to requirements has been adopted by thousands of organizations around the world. We felt that it was time to summarize some
More informationISTQB CTFL BH QuestionsAnswers with Explanation
ISTQB CTFL BH0-10 - QuestionsAnswers with Explanation For Software Testing Articles Visit @ http://softwaretestinghelp.com Join the Best Software Testing Training Course @ http://softwaretestinghelp.org
More informationSoftwaretechnik. Lecture 02: Processes. Peter Thiemann SS University of Freiburg, Germany
Softwaretechnik Lecture 02: Processes Peter Thiemann University of Freiburg, Germany SS 2012 Peter Thiemann (Univ. Freiburg) Softwaretechnik SWT 1 / 34 Terms Software Program SW System organized collections
More informationCMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide
processlabs CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide CMMI-DEV V1.3 Process Areas Alphabetically by Process Area Acronym processlabs CAR - Causal Analysis and Resolution...
More informationINTERNATIONAL STANDARD
INTERNATIONAL STANDARD ISO 9001 Third edition 2000-12-15 Quality management systems Requirements Systèmes de management de la qualité Exigences Reference number ISO 9001:2000(E) ISO 2000 Contents Page
More informationWaterfall model is the earliest SDLC approach that was used for software development.
1 Waterfall Model Guide These days there is a strong push for Agile Management, as opposed to Waterfall. Personally at Castellan Systems we believe that the agility should be applied to the project development
More informationCMMI 2008 CMMI 2008 Denver, Colorado United States November Tim Kasse. Kasse Initiatives LLC Europe
Value Proposition for Project Managers from Configuration Management CMMI 2008 CMMI 2008 Denver, Colorado United States November 2008 Tim Kasse Kasse Initiatives LLC +1 972-987 - 7706 USA +45 72 19 42
More informationNon-object-oriented design methods. Software Requirements and Design CITS 4401 Lecture 15
Non-object-oriented design methods Software Requirements and Design CITS 4401 Lecture 15 1 (reminder) Software Design is a creative process no cook book solutions goal driven we create a design for solving
More information25 D.L. Martin Drive Mercersburg, PA (717)
QUALITY MANUAL D. L. MARTIN CO. 25 D.L. Martin Drive Mercersburg, PA 17236 (717) 328-2141 Revision 14 August 2012 Michael A. White Manager, QA & Engineering D.L. Martin Co. Quality Manual UNCONTROLLED
More informationIntroduction and Key Concepts Study Group Session 1
Introduction and Key Concepts Study Group Session 1 PDU: CH71563-04-2017 (3 hours) 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters to use and modify this
More informationSistemi ICT per il Business Networking
Corso di Laurea Specialistica Ingegneria Gestionale Sistemi ICT per il Business Networking Requirements Engineering Docente: Vito Morreale (vito.morreale@eng.it) 17 October 2006 1 UP Phases 1. Inception
More informationAgile and Secure Can We Be Both? San Antonio AITP. August 15 th, 2007
Agile and Secure Can We Be Both? San Antonio AITP August 15 th, 2007 Agenda Background Evolution of traditional software development methodologies Benefits of Agile development Requirement for Secure development
More information3. PLANNING & PROCESSES
The Life Cycle of A Large Project Contract Bid, Ref PLAIG. PLAIG PROCESSES Payment Resource Program Program Resource Project Project Solution Engineering Engineering Criteria Subcontract Subcontract Material
More informationLearning Objectives. Agile Modeling and. Major Topics. Prototyping. Patched Up Prototype. Agile Modeling, but First. Prototyping
Agile Modeling and Prototyping Systems Analysis and Design, 7e Kendall & Kendall 6 Learning Objectives Understand the roots of agile modeling in prototyping and the four main types of prototyping Be able
More informationSystem-of-Systems Influences on Acquisition Strategy Development
System-of-Systems Influences on Acquisition Strategy Development Rita Creel Robert J. Ellison June 23008 ABSTRACT: An acquisition strategy is a top-level roadmap that focuses on highlighting and managing
More informationService Description for Storage Implementation. Issue 1.0. Date
Service Description for Storage Implementation Issue 1.0 Date 2012-11-01 Contents 1 Service Overview... 3 1.1 Service Product Definition... 3 1.2 Service Architecture... 3 2 Service Description... 4 2.1
More informationGENERAL PRINCIPLES OF SOFTWARE VALIDATION
GUIDANCE FOR INDUSTRY GENERAL PRINCIPLES OF SOFTWARE VALIDATION DRAFT GUIDANCE Version 1.1 This guidance is being distributed for comment purposes only. Draft released for comment on: June 9, 1997 Comments
More informationChapter 6: Software Evolution and Reengineering
Chapter 6: Software Evolution and Reengineering Harald Gall Software Engineering Group www.ifi.unizh.ch/swe/ Universität Zürich Institut für Informatik Ian Sommerville 2004 Software Engineering, 7th edition.
More informationCORPORATE QUALITY MANUAL
Corporate Quality Manual Preface The following Corporate Quality Manual is written within the framework of the ISO 9001:2008 Quality System by the employees of CyberOptics. CyberOptics recognizes the importance
More informationFunctional requirements and acceptance testing
Functional requirements and acceptance testing Lecture 3 Software Engineering TDDC88/TDDC93 autumn 2007 Department of Computer and Information Science Linköping University, Sweden Message from the course
More informationAgile Test Plan How to Construct an Agile Test Plan
Agile Test Plan How to Construct an Agile Test Plan XBOSoft White Paper How to Construct an Agile Test Plan www.xbosoft.com 2 Agile is changing not only the way we develop software but the way we work
More informationKINGS COLLEGE OF ENGINEERING DEPARTMENT OF INFORMATION TECHNOLOGY QUESTION BANK
KINGS COLLEGE OF ENGINEERING DEPARTMENT OF INFORMATION TECHNOLOGY QUESTION BANK Subject Code & Subject Name: IT1251 Software Engineering and Quality Assurance Year / Sem : II / IV UNIT I SOFTWARE PRODUCT
More informationEPICOR, INCORPORATED QUALITY ASSURANCE MANUAL
EPICOR, INCORPORATED QUALITY ASSURANCE MANUAL Revision: 6 Date 05/18/09 EPICOR, INCORPORATED 1414 E. Linden Avenue P.O. Box 1608 Linden, NJ. 07036-0006 Tel. 1-908-925-0800 Fax 1-908-925-7795 Table of Contents:
More informationRequirements Analysis
Objectives Classify categories of requirements Requirements Analysis Define the principles of iterative requirements analysis Learn about use cases and their elements Define system sequence diagrams for
More informationCMMI-SVC V1.3 CMMI for Services Version 1.3 Quick Reference Guide
processlabs CMMI-SVC V1.3 CMMI for Services Version 1.3 Quick Reference Guide CMMI-SVC V1.3 Process Areas Alphabetically by Process Area Acronym processlabs CAM - Capacity and Availability Management...
More informationIEC KHBO, Hobufonds SAFESYS ing. Alexander Dekeyser ing. Kurt Lintermans
IEC 61508 KHBO, Hobufonds SAFESYS ing. Alexander Dekeyser ing. Kurt Lintermans page 2 PART 1 : GENERAL REQUIREMENTS 1 Scope The first objective of this standard is to facilitate the development of application
More informationQUEST Boston Full Lifecycle Testing of Commercial off the Shelf (COTS) Software. Thursday, April 7 th, :00 AM 12:00 PM
Thursday, April 7 th, 2011 11:00 AM 12:00 PM QUEST Boston 2011 Full Lifecycle Testing of Commercial off the Shelf (COTS) Software PRESENTER: Saeid Vakili COMPANY: Ontario Ministry of Education This was
More informationThe following is an example systems manual from a low volume (TE, but not an automotive supplier) company.
The following is an example systems manual from a low volume (TE, but not an automotive supplier) company. You will note that this is essentially a copy of ISO 9001:2000. I take this path because long
More informationWork Plan and IV&V Methodology
Work Plan and IV&V Methodology Technology initiatives and programs should engage with an IV&V process at the project planning phase in order to receive an unbiased, impartial view into the project planning,
More informationPROCESS LED TRANSFORMATION & SUSTAINABILITY
PROCESS LED TRANSFORMATION & SUSTAINABILITY BUSINESS PROCESS MANAGEMENT USE CASE IMPRIVA Inc. 101A Clay St. #196 San Francisco, CA 94111 877.838.9714 www.impriva.com US Content Pain Point 3 Key Terms 3
More informationChapter 1: Introduction
Chapter 1: Introduction Engineering Engineering 1 Objectives In this chapter, you will learn about: The importance of requirements The role of RE in Software Development Lifecycle Gus Engineering 2 Problem
More informationAssociation of American Railroads Quality Assurance System Evaluation (QASE) Checklist Rev. 1/12/2017
Company: Prepared By: Date: Changes from previous version highlighted in yellow. Paragraph Element Objective Evidence 2.1 Objective of Quality Assurance Program 2.2 Applicability and Scope 2.3 QA Program
More informationAn Evolutionary Lifecycle Model with Agile Practices for Software Development at ABB
An Evolutionary Lifecycle Model with Agile Practices for Software Development at ABB Aldo Dagnino ABB US Corporate Research Center 1021 Main Campus Drive Raleigh, NC, USA aldo.dagnino@us.abb.com Abstract
More informationWhat is Continuous Integration. And how do I get there
What is Continuous Integration And how do I get there Related Workshops Introduction to DevOps Transform your Organization with DevOps Concepts DevOps Implementation Boot Camp Comprehensive literacy on
More information7. Model based software architecture
UNIT - III Model based software architectures: A Management perspective and technical perspective. Work Flows of the process: Software process workflows, Iteration workflows. Check Points of The process
More informationGuidelines for Testing Maturity
Guidelines for Testing Maturity Erik van Veenendaal of Improve Quality Services BV in the Netherlands has both involved in test process improvement projects at a large number of industrial organizations.
More informationSoftware Engineering
Software Engineering Lecture 02: Processes Peter Thiemann University of Freiburg, Germany SS 2013 Peter Thiemann (Univ. Freiburg) Software Engineering SWT 1 / 41 Terms Software Component SW System Organized
More informationSoftware Life Cycle. Main Topics. Introduction
Software Life Cycle Main Topics Study the different life cycle models Study the difference between software maintenance and evolution Study product line engineering as a design methodology 2 Introduction
More informationvramanujam Page 1 5/22/2014 TESTING MANUAL VARUN RAMANUJAM
vramanujam Page 1 5/22/2014 TESTING MANUAL BY VARUN RAMANUJAM vramanujam Page 2 5/22/2014 TOPICS SDLC (different phases) Types of SDLC models Role of Testing in SDLC Key differences between QA, QC and
More informationTHE PURPOSE OF TESTING
Chapter 6 THE PURPOSE OF TESTING Context-Driven Overview of Quadrants Tests That Support the Team Tests That Critique the Product Quadrant Intro Purpose of Testing Managing Technical Debt Knowing When
More informationAgile Quality Management
Agile Quality Management Panagiotis Sfetsos, PhD Assistant Professor, Department of Informatics, Alexander Technological Educational Institution E mail: sfetsos@it.teithe.gr Web Page: http://aetos.it.teithe.gr/~sfetsos/
More informationIntroduction. Fundamental concepts in testing
INF 3121 Software Testing - Lecture 01 Introduction. Fundamental concepts in testing 1. Why is testing necessary?? 4. Fundamental test process 5. The psychology of testing 1 1. Why is testing necessary?
More informationCourse Organization. Lecture 1/Part 1
Course Organization Lecture 1/Part 1 1 Outline About me About the course Lectures Seminars Evaluation Literature 2 About me: Ing. RNDr. Barbora Bühnová, Ph.D. Industrial experience Research Quality of
More information