Introduction to Software Testing
|
|
- Emery Golden
- 6 years ago
- Views:
Transcription
1 Introduction to Software Testing
2 Introduction Chapter 1 introduces software testing by : describing the activities of a test engineer defining a number of key terms explaining the central notion of test coverage Software is a key ingredient in many of the devices and systems: network routers financial networks web embedded applications: Airplanes, Spaceships, Traffic control systems mundane appliances watches, ovens, cars, DVD players 2
3 Introduction Goal of this course: present some few basic software testing concepts that can be used to design tests for a large variety of software applications. software engineer can easily apply them to any software testing situation. simplify testing by classifying coverage criteria into four categories: Graphs logical expressions input domain characterizations syntactic descriptions 3
4 Activities Of A Test Engineer Test engineer : Is an information technology (IT) professional Is in charge of one or more technical test activities including: designing test inputs Producing test case values running test scripts analyzing results reporting results to developers and managers Every engineer involved in software development should realize that he or she sometimes wears the hat of a test engineer. 4
5 Activities Of A Test Engineer Test Manager : Is in charge of one or more test engineers. Set test policies and processes, interact with other managers. 5
6 Activities Of A Test Engineer One of a test engineer s most powerful tools is a formal coverage criterion. Formal coverage criteria give test engineers ways to: decide what test inputs to use during testing. making it more likely that the tester will find problems in the program. Coverage criteria provide stopping rules for the test engineers. Software testing activities have been categorized into levels. Two kinds of levels have been used. 6
7 Activities Of A Test Engineer The most often used level categorization is based on traditional software process steps. Although most types of tests can only be run after some part of the software is implemented, tests can be designed and constructed during all software development steps. The most time-consuming parts of testing: Test design Test construction The second-level categorization is based on the attitude and thinking of the testers. 7
8 Testing Levels Based on Software Activity Different levels of testing: Acceptance Testing: assess software with respect to requirements. System Testing: assess software with respect to architectural design. Integration Testing: assess software with respect to subsystem design. Module Testing: assess software with respect to detailed design. Unit Testing: assess software with respect to implementation. 8
9 Testing Levels Based on Software Activity below figure shows software development activities and testing levels (V Model) 9
10 Testing Levels Based on Software Activity Standard advice is to design the tests concurrently with each development activity. The reason for this advice is that : mere process of explicitly articulating tests can identify defects in design decisions that otherwise appear reasonable. Requirements Analysis phase of software development captures the customer s needs. Acceptance testing is designed to determine whether the completed software meets these needs. Acceptance testing must involve users or other individuals who have strong domain knowledge. 10
11 Testing Levels Based on Software Activity Architectural design phase chooses components and connectors that realize a system whose specification is intended to meet. System testing is designed to determine whether the assembled system meets its specifications. Subsystem design phase specifies the structure and behavior of subsystems Integration testing is designed to assess whether the interfaces between modules in a given subsystem have consistent assumptions and communicate correctly. 11
12 Testing Levels Based on Software Activity Detailed design phase determines the structure and behavior of individual modules. Module testing is designed to assess individual modules in isolation, including how the component units interact with each other. Implementation is the phase that actually produces code. Unit testing is designed to assess the units produced by the implementation. 12
13 Testing Levels Based on Software Activity Regression testing : a standard part of the maintenance phase of software development. is done after changes are made to the software. its purpose is to help ensure that the updated software still possesses the functionality it had before the updates. Unfortunately, the software faults that come from requirements and design mistakes are visible only through testing months or years after the original mistake. 13
14 Testing Levels Based on Software Activity If tests cannot be executed, the very process of defining tests can identify a significant fraction of the mistakes in requirements and design. Through techniques such as use-case analysis, test planning is becoming better integrated with requirements analysis in standard software practice. Although most of the literature emphasizes these levels in terms of when they are applied, a more important distinction is on the types of faults. 14
15 Testing Levels Based on Software Activity One of the best examples of the differences between unit testing and system testing can be illustrated in the context of the infamous Pentium bug: the chip gave incorrect answers to certain floating-point division calculations. The chip was slightly inaccurate for a few pairs of numbers. The Pentium bug not only illustrates the difference in testing levels, but it is also one of the best arguments for paying more attention to unit testing. 15
16 Testing Levels Based on Software Activity On the other hand, some faults can only be found at the system level: The launch failure of the first Ariane 5 rocket. The low-level cause was an unhandled floating-point conversion exception in an internal guidance system function. The guidance system function is correct for Ariane 4 but no one reanalyzed the software in light of the substantially different flight trajectory of Ariane 5. 16
17 Testing Levels Based on Software Activity Object-Oriented softwares changes the testing levels: OO software blurs the distinction between units and modules. Intramethod testing is when tests are constructed for individual methods. Intermethod testing is when pairs of methods within the same class are tested in concert. Intraclass testing is when tests are constructed for a single entire class. 17
18 Beizer s Testing Levels Based on Test Process Maturity This categorization of levels is based on the test process maturity level of an organization: Level 0: There s no difference between testing and debugging. Level 1: The purpose of testing is to show that the software works. Level 2: The purpose of testing is to show that the software doesn t work. Level 3: The purpose of testing is to reduce the risk of using the software. Level 4: Testing is a mental discipline that helps all IT professionals develop higher quality software. 18
19 Beizer s Testing Levels Based on Test Process Maturity Level 0 is the view that testing is the same as debugging. This model does not distinguish between a program s incorrect behavior and a mistake within the program, and does very little to help develop software that is reliable or safe. In Level 1 testing, the purpose is to show correctness. Suppose we run a collection of tests and find no failures. What do we know? Should we assume that we have good software or just bad tests? Test managers have no way to answer the question. they have no way to quantitatively express or evaluate their work. 19
20 Beizer s Testing Levels Based on Test Process Maturity In Level 2 testing, the purpose is to show failures. Testers may enjoy finding the problem, but the developers never want to find problems level 2 testing puts testers and developers into an adversarial relationship when our primary goal is to look for failures, we are still left wondering what to do if no failures are found. Level 3 testing: Testing can show the presence, but not the absence, of failures. This allows us to realize that the entire development team wants to reduce the risk of using the software. 20
21 Beizer s Testing Levels Based on Test Process Maturity Once the testers and developers are on the same team, an organization can progress to real Level 4 testing. Level 4 thinking defines testing as a mental discipline that increases quality. We often think that the purpose of a spell checker is to find misspelled words, but in fact, the best purpose of a spell checker is to improve our ability to spell. In the same way, level 4 testing means that the purpose of testing is to improve the ability of the developers to produce high quality software. The testers should train your developers. 21
22 Automation of Test Activities Software testing requires up to 50% of software development costs, and even more for safety-critical applications. revenue tasks: determining which methods are appropriate to define a given data abstraction as a Java class is a revenue task. excise tasks: compiling a Java class is a excise task. Excise tasks are candidates for automation; revenue tasks are not. Software testing probably has more excise tasks than any other aspect of software development. 22
23 Automation of Test Activities Automating excise tasks serves the test engineer in many ways: 1. Eliminates excise tasks eliminates drudgery, thereby making the test engineers job more satisfying. 2. Frees up time to focus on the fun and challenging parts of testing. 3. Can help eliminate errors of omission, such as failing to update all the relevant files with the new set of expected results. 4. Eliminates some of the variance in test quality caused by differences in individual s abilities. 23
24 Software Testing Limitations and Terminology One of the most important limitations of software testing is that testing can show only the presence of failures, not their absence. Some terms that are important in software testing: Validation evaluating software at the end of software development. usually depends on domain knowledge. Verification determining whether the products of a given phase fulfill the requirements. is usually a more technical activity IV&V (independent verification and validation) : evaluation is done by non developers. 24
25 Software Testing Limitations and Terminology Software Fault A static defect in the software Faults in software are design mistakes. Software Error An incorrect internal state that is the manifestation of some fault. Software Failure External, incorrect behavior with respect to the requirements or other description of the expected behavior. 25
26 Software Testing Limitations and Terminology Example for fault, error and failure in a Java program: 26
27 Software Testing Limitations and Terminology The fault : it starts looking for zeroes at index 1 instead of index 0 For example, numzero ([2, 7, 0]) correctly evaluates to 1, while numzero ([0, 7, 2]) incorrectly evaluates to 0. both of these cases result in an error only the second case results in failure. First state is in error because the value of i should be zero on the first iteration. However, since the value of count is correct, the error state does not propagate to the output. 27
28 Software Testing Limitations and Terminology Testing Evaluating software by observing its execution. Test Failure Execution that results in a failure. Debugging The process of finding a fault given a failure. For a given fault, not all inputs will trigger the fault into creating incorrect output (a failure). Three conditions must be present for a failure to be observed ( RIP Model) 28
29 Software Testing Limitations and Terminology RIP Model 1. Reachability: The location or locations in the program that contain the fault must be reached. 2. Infection: After executing the location, the state of the program must be incorrect. 3. Propagation: The infected state must propagate to cause some output of the program to be incorrect. Test Case Values The input values necessary to complete some execution of the software under test. Expected Results The result that will be produced when executing the test if and only if the program satisfies its intended behavior. 29
30 Software Testing Limitations and Terminology Software Observability How easy it is to observe the behavior of a program in terms of its outputs, effects on the environment, and other hardware and software components. Software Controllability How easy it is to provide a program with the needed inputs, in terms of values, operations, and behaviors. Many O & C problems can be addressed with simulation (bypass the hardware or software components that interfere with testing) 30
31 Software Testing Limitations and Terminology Test Case A test case is composed of the test case values, expected results, prefix values, and postfix values necessary for a complete execution and evaluation of the software under test. Test Set A test set is simply a set of test cases. Executable Test Script A test case that is prepared in a form to be executed automatically on the test software and produce a report. 31
32 Software Testing Limitations and Terminology Prefix Values Any inputs necessary to put the software into the appropriate state to receive the test case values. Postfix Values Any inputs that need to be sent to the software after the test case values are sent. Postfix values can be subdivided into two types: Verification Values: Values necessary to see the results of the test case values. Exit Commands: Values needed to terminate the program or otherwise return it to a stable state. 32
33 Coverage Criteria For Testing Some ill-defined terms used in testing are complete testing exhaustive testing and full coverage The number of potential inputs for most programs is so large as to be effectively infinite. For Example : in a Java compiler the number of inputs to the compiler is not just all Java Programs, but all strings. Since we cannot test with all inputs, coverage criteria are used to decide which test inputs to use. From a practical perspective, coverage criteria provide useful rules for when to stop testing. 33
34 Coverage Criteria For Testing Test Requirement A test requirement is a specific element of a software artifact that a test case must satisfy or cover. Test requirements can be described with respect to a variety of software artifacts, including source code, design components, specification modeling elements, or descriptions of the input space. Suppose we are given the task of testing bags of jelly beans: They have the following six flavors and come in four colors. A simple approach to testing might be to test one jelly bean of each flavor. Six test requirements, one for each flavor. We satisfy the test requirement Lemon by selecting and tasting a Lemon jelly bean from a bag of jelly beans. This dilemma illustrates a classic controllability issue. 34
35 Coverage Criteria For Testing Coverage Criterion A coverage criterion is a rule or collection of rules that impose test requirements on a test set. Criterion describes the test requirements in a complete and unambiguous manner. Test requirements for flavor criterion : TR = {flavor = Lemon, flavor = Pistachio, flavor = Cantaloupe, flavor = Pear, flavor = Tangerine, flavor = Apricot} 35
36 Coverage Criteria For Testing Coverage Given a set of test requirements TR for a coverage criterion C, a test set T satisfies C if and only if for every test requirement tr in TR, at least one test t in T exists such that t satisfies tr. a test set T with 12 beans satisfies the flavor criterion. It is perfectly acceptable to satisfy a given test requirement with more than one test. It is sometimes expensive to satisfy a coverage criterion. Some requirements cannot be satisfied. for example Tangerine jelly beans are rare Drop unsatisfiable TRs from the set TR or to replace them with less stringent test requirements. 36
37 Coverage Criteria For Testing Coverage Level Given a set of test requirements TR and a test set T, the coverage level is simply the ratio of the number of test requirements satisfied by T to the size of TR. Infeasible: Test requirements that cannot be satisfied. Dead code results in infeasible test requirements because the statements cannot be reached. 100% coverage is impossible in practice. 37
38 Coverage Criteria For Testing Coverage Criteria Coverage criteria are used in one of two ways: 1. Directly generate test case values to satisfy a given criterion. o o Assumed by the research community and is the most obvious way to use criteria. Very hard in some cases: if we do not have enough automated tools to support test case value generation. 2. Generate test case values externally and measure tests against the criterion in terms of their coverage. o Assumed by the industry practitioners. 38
39 Coverage Criteria For Testing Coverage Criteria(etc.) If our tests do not reach 100% coverage, what does that mean? We have no data on how much, say, 99% coverage is worse than 100% coverage. Generator Procedure that automatically generates values to satisfy a criterion. Recognizer Procedure that decides whether a given set of test case values satisfies a criterion. 39
40 Coverage Criteria For Testing Generator vs. Recognizer In practice it is possible to recognize whether test cases satisfy a criterion more often than generating the tests. The primary problem with recognition is infeasible test requirements; if no infeasible test requirements are present, then the problem becomes decidable. The set TR depends on the specific artifact under test. TR: color = Purple doesn t make sense because we assumed that the factory does not make Purple jelly beans. 40
41 Coverage Criteria For Testing Criteria Subsumption A coverage criterion C1 subsumes C2 if and only if every test set that satisfies criterion C1 also satisfies C2. Note that this has to be true for every test set. For Example : Color criterion requires that we try one jelly bean of each color. If we satisfy the flavor criterion, then we have also implicitly satisfied the color criterion. 41
42 Infeasibility and Subsumption A subtle relationship exists between infeasibility and subsumption. Sometimes a coverage criterion C1 will subsume another C2 if we assume that C1 has no infeasible test requirements, but if C1 does create an infeasible test requirement for a program, a test suite that satisfies C1 while skipping the infeasible test requirements might also skip some test requirements from C2 that are satisfiable. 42
43 Characteristics of a Good Coverage Criterion 1. The difficulty of computing test requirements. 2. The difficulty of generating tests. 3. How well the tests reveal faults. Notes: Subsumption is at best a very rough way to compare criteria. If one criterion subsumes another, then it should reveal more faults. The fact that the difficulty of generating tests can be directly related to how well the tests reveal faults should not be surprising. Choosing criteria that have the right cost/benefit tradeoffs 43
44 Older Software Testing Terminology Black-box testing Deriving tests from external descriptions of the software, including specifications, requirements, and design. White-box testing Deriving tests from the source code internals of the software, specifically including branches, individual conditions, and statements. From an abstract perspective, black-box and white-box testing are very similar. 44
45 Older Software Testing Terminology Top-Down Testing Test the main procedure, then go down through procedures it calls, and so on. top-down testing is impractical. Bottom-Up Testing Test the leaves in the tree and move up to the root. Each procedure is tested only if all of its children have been tested. OO software leads to a more general problem. The relationships among classes can be formulated as general graphs with cycles, requiring test engineers to make the difficult choice of what order to test the classes in. 45
46 Older Software Testing Terminology Static Testing Testing without executing the program. This includes software inspections and some forms of analysis. Dynamic Testing Testing by executing the program with real inputs. testing refer to dynamic testing verification activities refer to static testing 46
Introduction 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 information9. Verification, Validation, Testing
9. Verification, Validation, Testing (a) Basic Notions (b) Dynamic testing. (c) Static analysis. (d) Modelling. (e) Environmental Simulation. (f) Test Strategies. (g) Tool support. (h) Independent Verification
More informationAn Application of Causal Analysis to the Software Modification Process
SOFTWARE PRACTICE AND EXPERIENCE, VOL. 23(10), 1095 1105 (OCTOBER 1993) An Application of Causal Analysis to the Software Modification Process james s. collofello Computer Science Department, Arizona State
More information32 BETTER SOFTWARE JULY/AUGUST 2009
32 BETTER SOFTWARE JULY/AUGUST 2009 www.stickyminds.com Why automate? This seems such an easy question to answer; yet many people don t achieve the success they hoped for. If you are aiming in the wrong
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 informationSE420 Software Quality Assurance
SE420 Software Quality Assurance Lecture 1 Introduction Part-2 January 16, 2017 Sam Siewert Course Learning Objectives Theory of Overall SQA Process Process Models (Waterfall, Spiral, XP) using Agile Strategy
More information18-642: Software Development Processes
18-642: Software Development Processes 9/6/2017 Without requirements and design, programming is the art of adding bugs to an empty text file. Louis Srygley Coding Is Essentially 0% of Creating Software
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 informationdeveloper.* The Independent Magazine for Software Professionals Automating Software Development Processes by Tim Kitchens
developer.* The Independent Magazine for Software Professionals Automating Software Development Processes by Tim Kitchens Automating repetitive procedures can provide real value to software development
More informationTest Process Improvement using TMM(i)
Test Process Improvement using TMM(i) Erik van Veenendaal, Richard Grooff and Rob Hendriks Improve Quality Services BV Introduction More and more organisation are trying to improve their software development
More informationBASICS OF SOFTWARE TESTING AND QUALITY ASSURANCE. Yvonne Enselman, CTAL
BASICS OF SOFTWARE TESTING AND QUALITY ASSURANCE Yvonne Enselman, CTAL Information alines with ISTQB Sylabus and Glossary THE TEST PYRAMID Why Testing is necessary What is Testing Seven Testing principles
More informationSE420 Software Quality Assurance
SE420 Software Quality Assurance Lecture 2 Software Specification Part-1 January 16, 2017 Sam Siewert SQA LO s (Learning Objectives) Theory and Principles 1. Coverage of Current SQA Theory and Practice
More informationAn Overview of Software Reliability
Software Design For Reliability (DfR) Seminar An Overview of Software Reliability Bob Mueller bobm@opsalacarte.com www.opsalacarte.com Software Quality and Software Reliability Related Disciplines, Yet
More informationJava & Testing. Slides adapted from Craig Zilles
Java & Testing Slides adapted from Craig Zilles 1 Things to have been doing join UIUC CS 126 on piazza.com get an iclicker registered at http://iclicker.com get a GitHub account install IntelliJ on to
More informationTesting. Testing is the most important component of software development that must be performed throughout the life cycle
Testing Testing is the most important component of software development that must be performed throughout the life cycle Testing must be carried out by developers continuously More methodical testing must
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 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 informationISEB ISTQB Sample Paper
[2011] ISEB ISTQB Sample Paper [BH0-010 ISEB ISTQB FOUNDATION LEVEL] This sample is based on the latest syllabus of ISTQB Foundation Level prepared by For more sample papers visit /istqb.aspx Total Questions:
More informationPrinciples of Verification, Validation, Quality Assurance, and Certification of M&S Applications
Introduction to Modeling and Simulation Principles of Verification, Validation, Quality Assurance, and Certification of M&S Applications OSMAN BALCI Professor Copyright Osman Balci Department of Computer
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 informationSurviving the Top Ten Challenges of Software Testing
Surviving the Top Ten Challenges of Software Testing: A Closer Look at Understanding Software Testing Randy Rice, CQA, CSTE Rice Consulting Services, Inc. 405-692-7331 http://www.riceconsulting.com rcs@telepath.com
More informationOnline Student Guide Types of Control Charts
Online Student Guide Types of Control Charts OpusWorks 2016, All Rights Reserved 1 Table of Contents LEARNING OBJECTIVES... 4 INTRODUCTION... 4 DETECTION VS. PREVENTION... 5 CONTROL CHART UTILIZATION...
More informationIntroduction to Systems Analysis and Design
Introduction to Systems Analysis and Design What is a System? A system is a set of interrelated components that function together to achieve a common goal. The components of a system are called subsystems.
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 informationSoftware Reliability and Testing: Know When To Say When. SSTC June 2007 Dale Brenneman McCabe Software
Software Reliability and Testing: Know When To Say When SSTC June 2007 Dale Brenneman McCabe Software 1 SW Components with Higher Reliability Risk, in terms of: Change Status (new or modified in this build/release)
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 informationTesting a Software Product Line
Testing a Software Product Line John D. McGregor Clemson University Clemson, SC 29634 johnmc@cs.clemson.edu Abstract. The software product line approach to the development of software intensive systems
More informationIT Software Testing
IT6004 - Software Testing Unit-I Introduction 1.1 The Evolving Profession of Software Engineering the development process is well understood; projects are planned; life cycle models are defined and adhered
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 informationRisk-Based Approach to SAS Program Validation
Paper FC04 Risk-Based Approach to SAS Program Validation Keith C. Benze SEC Associates, Inc. 3900 Paramount Parkway, Suite 150 South Morrisville, NC 27560 ABSTRACT SAS is widely used throughout the FDA
More informationWORKING WITH TEST DOCUMENTATION
WORKING WITH TEST DOCUMENTATION CONTENTS II. III. Planning Your Test Effort 2. The Goal of Test Planning 3. Test Planning Topics: b) High Level Expectations c) People, Places and Things d) Definitions
More informationSOFTWARE QUALITY IMPROVEMENT THROUGH DEFECT PREDICTION
SOFTWARE QUALITY IMPROVEMENT THROUGH DEFECT PREDICTION DR. DEEPAK KUMAR VERMA ASSISTANT PROFESSOR DEPARTMENT OF COMPUTER SCIENCE & INFORMATION TECHNOLOGY BABASAHEB BHIMRAO AMBEDKAR UNIVERSITY, (A CENTRAL
More informationIntroduction to Software Life Cycles and Agile. CSCI 5828: Foundations of Software Engineering Lecture 03 09/02/2014
Introduction to Software Life Cycles and Agile CSCI 5828: Foundations of Software Engineering Lecture 03 09/02/2014 1 Goals Present an introduction to the topic of software life cycles concepts and terminology
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 informationVector Software W H I T E P A P E R. Using VectorCAST for Software Verification and Validation of Railway Applications
Vector Software W H I T E P A P E R Using VectorCAST for Software Verification and Validation of Railway Applications Introduction This document is intended to serve as a reference for the usage of VectorCAST
More informationThe Verification Company. Software Development and Verification compliance to DO-178C/ED-12C
The Verification Company Software Development and Verification compliance to DO-178C/ED-12C DO-178C/ED-12C in Context Airworthiness Requirements Federal Aviation Regulation (FAR) 25 Airworthiness Standards:
More informationIBM Rational Software Quality Solutions
IBM Software Group IBM Rational Software Quality Solutions - IBM Rational Performance Tester Denice Wong Technical Consultant Rational Software, IBM Hong Kong 2006 IBM Corporation Agenda IBM Rational Software
More informationISTQB CTFL BH0-10 Questions Answers with Explanation
ISTQB CTFL BH0-10 Questions Answers with Explanation For Software Testing Articles Visit @ http://softwaretestinghelp.com Join the Best Software Testing Training Course @ http://softwaretestinghelp.org
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 informationFormal Techniques in Large-Scale Software Engineering
Formal Techniques in Large-Scale Software Engineering Mathai Joseph Tata Research Development and Design Centre Tata Consultancy Services 54B Hadapsar Industrial Estate Pune 411 013 India Draft of Paper
More informationCost Benefits Analysis of Test Automation
Douglas Hoffman Software Quality Methods, LLC. 24646 Heather Heights Place Saratoga, California 95070-9710 Phone 408-741-4830 Fax 408-867-4550 doug.hoffman@acm.org Keywords: Automated Testing, Automation
More informationComponent-based Development Process and Component Lifecycle
-based Process and Lifecycle Ivica Crnkovic 1, Michel Chaudron 2, Stig Larsson 3 1 Mälardalen University, Department of Computer Science and Electronics, Sweden 2 Eindhoven University of Technology, Dept.
More informationBASICS OF SOFTWARE TESTING
BASICS OF SOFTWARE TESTING CONTENTS I. Software Quality, Definition of testing, Role of testing. II. III. IV. Failure, Error, fault, Defect, Bug Terminology Objectives of Testing What is a Test Case? V.
More informationINF 3121 Software Testing - Lecture 05. Test Management
INF 3121 Software Testing - Lecture 05 Test Management 1. Test organization (20 min) (25 min) (15 min) (10 min) (10 min) (10 min) INF3121 / 23.02.2016 / Raluca Florea 1 1. Test organization (20 min) LO:
More informationWriting Good Requirements. (A Requirements Working Group Information Report)
Writing Good Requirements Page 1 of 11 Published in the Proceedings of the Third International Symposium of the NCOSE - Volume 2, 1993. Prepared by the Requirements Working Group of the International Council
More informationIEC Is it pain or gain?
IEC 61508 Is it pain or gain? Clive Timms, Director, C&C Technical Support Services Ltd. Introduction IEC 61508 (Ref. 1) provides designers and operators with the first generic internationally accepted
More informationAbstract. Keywords. 1. Introduction. Rashmi N 1, Suma V 2. Where, i = 1 requirement phase, n = maintenance phase of software development process [9].
Defect Detection Efficiency: A Combined approach Rashmi N 1, Suma V 2 Abstract Survival of IT industries depends much upon the development of high quality and customer satisfied software products. Quality
More informationDesign of a Performance Measurement Framework for Cloud Computing
A Journal of Software Engineering and Applications, 2011, *, ** doi:10.4236/jsea.2011.***** Published Online ** 2011 (http://www.scirp.org/journal/jsea) Design of a Performance Measurement Framework for
More informationTesting and Quality Assurance Techniques
Testing and Quality Assurance Techniques Sandy Sorkin Coastal Technologies 615 Valley Road - Upper Montclair, NJ 07043 (973) 744-2900 - Fax (973) 744-2129 www.coastaltech.com 1998 Coastal Technologies
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 informationDeliverable: 1.4 Software Version Control and System Configuration Management Plan
Deliverable: 1.4 Software Version Control and System Configuration VoteCal Statewide Voter Registration System Project State of California, Secretary of State (SOS) Authors This document was prepared
More informationDevelopment of Safety Related Systems
July 2015 LatticeSemiconductor 7 th Floor,111SW5 th Avenue Portland,Oregon97204USA Telephone:(503)268I8000 www.latticesemi.com WP004 The increasing degree of automation brings a lot of comfort and flexibility
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 informationTechnische Universität München. Software Quality. Management. Dr. Stefan Wagner Technische Universität München. Garching 18 June 2010
Technische Universität München Software Quality Management Dr. Stefan Wagner Technische Universität München Garching 18 June 2010 1 Last QOT: Why is software reliability a random process? Software reliability
More informationIMPLEMENTATION, EVALUATION & MAINTENANCE OF MIS:
IMPLEMENTATION, EVALUATION & MAINTENANCE OF MIS: The design of a management information system may seem to management to be an expensive project, the cost of getting the MIS on line satisfactorily may
More informationFundamentals of Requirements Engineering
- interfaces system seen as black box inputs functions quantified characteristics outputs restrictions, prerequisites boundaries, exceptions standards, regulations Frogs vei 41 P.O. Box 235, NO-3603 Kongsberg
More informationCost of Changing the Activities in SDLC. Minimum of Cost at this level. code debuging unit test integration. Activity
Software Development Life Cycle (SDLC) This is a work flow for creating a new software/application. Usually, any company that is in the software business follows the same route and structure. In this document
More information``Overview. ``The Impact of Software. ``What are Virtual Prototypes? ``Competitive Electronic Products Faster
Virtualizer ``Overview ``The Impact of ``What are Virtual Prototypes? ``Competitive Electronic Products Faster ``Use Virtual Prototyping from Specification to Deployment ``Virtualizer Technical Specification
More informationSoftware verification services for aerospace. »» Unit and integration testing. »» Timing analysis and optimization»» System and acceptance testing
Software verification services for aerospace»» Unit and integration testing»» Timing analysis and optimization»» System and acceptance testing»» On-target problem solving»» DO-178C process definition and
More informationAdopting to Agile Software Development
doi: 10.1515/acss-2014-0014 Adopting to Agile Software Development Gusts Linkevics, Riga Technical University, Latvia Abstract Agile software development can be made successful, but there is no well-defined
More informationCPSC 310 Software Engineering. Quality
CPSC 310 Software Engineering Quality Learning Goals By the end of this unit, you will be able to: Describe aspects that affect software quality other than code quality Explain the benefits of high quality
More informationA Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 Skillport
A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 by The International Institute of Business Analysis (IIBA) International Institute of Business Analysis. (c) 2009. Copying
More informationWhat are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs.
What are requirements? Basics of Requirement Engineering Muzaffar Iqbal Farooqi A requirement is a necessary attribute in a system, a statement that identifies a capability, characteristic, or quality
More informationCritical Systems Specification. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 9 Slide 1
Critical Systems Specification Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 9 Slide 1 Objectives To explain how dependability requirements may be identified by analysing the risks faced
More informationCopyright Software Engineering Competence Center
Copyright Software Engineering Competence Center 2012 1 Copyright Software Engineering Competence Center 2012 5 These are mapped categories to the waste categories of manufacturing. An excellent overview
More informationDevelopment of AUTOSAR Software Components with Model-Based Design
Development of AUTOSAR Software Components with Model-Based Design Guido Sandmann Automotive Marketing Manager, EMEA The MathWorks Joachim Schlosser Senior Team Leader Application Engineering The MathWorks
More informationA New Divide & Conquer Software Process Model
A New Divide & Conquer Software Process Model First A. Hina Gull, Second B. Farooque Azam Third C. Wasi Haider Butt, Fourth D. Sardar Zafar Iqbal Abstract The software system goes through a number of stages
More informationIntroduction to Software Life Cycles. CSCI 5828: Foundations of Software Engineering Lecture 06 09/08/2016
Introduction to Software Life Cycles CSCI 5828: Foundations of Software Engineering Lecture 06 09/08/2016 1 Goals Present an introduction to the topic of software life cycles concepts and terminology benefits
More informationAgile Plus Comprehensive model for Software Development
Agile Plus Comprehensive model for Software Development Amit Juyal Umesh Kumar Tiwari Lata Nautiyal Shashidhar G. Koolagudi Assistant Professor Assistant Professor Assistant Professor Professor Graphic
More informationDependability requirements. Risk-driven specification. Objectives. Stages of risk-based analysis. Topics covered. Critical Systems Specification
Dependability requirements Critical Systems Specification Functional requirements to define error checking and recovery facilities and protection against system failures. Non-functional requirements defining
More informationResearch on software systems dependability at the OECD Halden Reactor Project
Research on software systems dependability at the OECD Halden Reactor Project SIVERTSEN Terje 1, and ØWRE Fridtjov 2 1. Institute for Energy Technology, OECD Halden Reactor Project, Post Box 173, NO-1751
More informationAuditing Standards and Practices Council
Auditing Standards and Practices Council PHILIPPINE STANDARD ON AUDITING 315 UNDERSTANDING THE ENTITY AND ITS ENVIRONMENT AND ASSESSING THE RISKS OF MATERIAL MISSTATEMENT PHILIPPINE STANDARD ON AUDITING
More informationPricing with Market Power
Chapter 7 Pricing with Market Power 7.1 Motives and objectives Broadly The model of perfect competition is extreme (and hence wonderfully powerful and simple) because of its assumption that each firm believes
More informationBuild It fast & Build It Right
Build It fast & Build It Right John Watkins International Conference On Software Testing, Analysis & Review November 19-23 Stockholm, Sweden P r e s e n t a t i o n T6 Thursday 22nd November, 2001 Thursday
More informationTHE MOBILE TSUNAMI THREATENS THE COMPETITIVE POSITIONING OF THE ENTERPRISE
THE MOBILE TSUNAMI THREATENS THE COMPETITIVE POSITIONING OF THE ENTERPRISE Abstract: This white paper zooms in on the threat of increasing costs of app-development faced by Enterprises and offers a vision
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 informationhttps://digitalcontentmarket.org/download/solution-manual-for-introduction-to-operations-and-su pply-chain-management-3rd-edition/
Download full Test Bank for Introduction To Operations And Supply Chain Management 3rd Edition Link download full: https://digitalcontentmarket.org/download/test-bank-for-introduction-to-operations-and-supply-c
More informationTESTING THE REQUIREMENTS
build great products TESTING THE REQUIREMENTS Someone once asked me when you can begin testing your software. As soon as you ve written your first requirement, you can begin testing, I replied. It s hard
More informationUniversity of Groningen. Design of a Methodology to Support Software Release Decisions Sassenburg, J.A.
University of Groningen Design of a Methodology to Support Software Release Decisions Sassenburg, J.A. IMPORTANT NOTE: You are advised to consult the publisher's version (publisher's PDF) if you wish to
More informationBeyond Integration: The Challenge of Compositional Assurance
Beyond Integration: The Challenge of Compositional Assurance John Rushby Computer Science Laboratory SRI International Menlo Park, California, USA John Rushby, SR I Compositional Assurance: 1 Assurance
More informationTest Bank For Operations And Supply Chain Management 14th Edition By F. Robert Jacobs, Richard Chase Completed download:
Test Bank For Operations And Supply Chain Management 14th Edition By F. Robert Jacobs, Richard Chase Completed download: https://testbankarea.com/download/operations-supply-chain-management- 14th-edition-test-bank-jacobs-chase/
More informationRequirements Analysis and Design Definition. Chapter Study Group Learning Materials
Requirements Analysis and Design Definition Chapter Study Group Learning Materials 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters to use and modify this
More informationSoftware Assurance Marketplace Use Case
Software Assurance Marketplace Use Case Overview Software Developer May 2013, Revision 1.0 The Software Assurance Marketplace (SWAMP) will support five user communities as shown in the diagram below. This
More informationA lifecycle approach to systems quality: because you can t test in quality at the end.
Systems quality management White paper December 2009 A lifecycle approach to systems quality: because you can t test in quality at the end. Moshe S. Cohen, market/offering manager, quality management,
More informationInformation Technology Project Management, Sixth Edition. Note: See the text itself for full citations. More courses at cie-wc.edu
Management, Sixth Edition Note: See the text itself for full citations. More courses at cie-wc.edu Understand the importance of good project scope management Discuss methods for collecting and documenting
More informationLOGISTICAL ASPECTS OF THE SOFTWARE TESTING PROCESS
LOGISTICAL ASPECTS OF THE SOFTWARE TESTING PROCESS Kazimierz Worwa* * Faculty of Cybernetics, Military University of Technology, Warsaw, 00-908, Poland, Email: kazimierz.worwa@wat.edu.pl Abstract The purpose
More informationThe Realities of Software Testing. [Reading assignment: Chapter 3, pp ]
The Realities of Software Testing [Reading assignment: Chapter 3, pp. 37-50] Software process models are an ideal not reality No software development effort follows a process model perfectly. Why? The
More informationBPMN Guide Quick Start. by Bizagi BPM
BPMN Guide Quick Start by Bizagi BPM Recruitment and Selection 1 Table of Contents Scope... 2 BPMN 2.0 Business Process Modeling Notation... 2 Why Is It Important To Model With BPMN?... 2 Introduction
More informationAutomatedQA Webinar 1
AutomatedQA Webinar 1 AutomatedQA Webinar 2 Today, the tips are not about technology. We won t be covering TestComplete specifically. The focus is on people and communication. 3 What is a successful test
More informationFUNDAMENTAL STAGES IN DESIGNING PROCEDURE OF STATISTICAL SURVEY
FUNDAMENTAL STAGES IN DESIGNING PROCEDURE OF STATISTICAL SURVEY PÉTER PUKLI The mission of National Statistics Institutes (NSIs) is to meet the statistical needs of the different user groups. Consequently,
More informationSignificance of Quality Metrics during Software Development Process
Significance of Quality Metrics during Software Development Process 1 Poornima. U. S., 2 Suma. V 1 Program Manager, MCA Department, Acharya Institute of Management and Sciences 1,2 Research and Industry
More informationThe Importance of Independent Quality Assurance for Patient Safety and Quality Care
The Importance of Independent Quality Assurance for Patient Safety and Quality Care January 2016 Independent quality assurance (iqa) testing is vital to the successful development and deployment of applications
More informationTOWARDS DEFINING SOFTWARE DEVELOPMENT PROCESSES IN DO-178B WITH OPENUP
TOWARDS DEFINING SOFTWARE DEVELOPMENT PROCESSES IN DO-178B WITH OPENUP Christophe Bertrand, Christopher P. Fuhrman Department of Software and IT Engineering, ÉTS (École de technologie supérieure), Montreal,
More informationAyla Architecture. Focusing on the Things and Their Manufacturers. WE RE DRIVING THE NEXT PHASE OF THE INTERNET of THINGS
WE RE DRIVING THE NEXT PHASE OF THE INTERNET of THINGS NOW Ayla Architecture Focusing on the Things and Their Manufacturers Ayla Networks 2015 www.aylanetworks.com The Ayla Internet of Things Platform:
More informationSummary of TL 9000 R4.0 Requirements Beyond ISO 9001:2000
This summary identifies the additional TL 9000 Release 4.0 requirements beyond those stated in ISO 9001:2000. See the TL 9000 R4.0 Handbook for the actual TL 9000 R4.0 requirements. ISO 9001:2000 section
More informationIntermediate Certificate in Software Testing Syllabus. Version 1.4
Intermediate Certificate in Software Testing Syllabus February 2010 Background This document is the syllabus for the intermediate paper which leads to the practitioner level of qualification, as administered
More informationObject-Oriented & Classical Soft Engineering
Object-Oriented & Classical Soft Engineering Seventh Edition Stephen R. Schach Vanderbilt University Higher Education Boston Burr Ridge, IL Dubuque, IA New York San Francisco St. Louis Bangkok Bogota Caracas
More informationVirtualized network function on-boarding
Virtualized network function on-boarding Strategic White Paper Virtualized network function (VNF) on-boarding describes the process by which a VNF is made available to a network functions virtualization
More informationSOFTWARE TESTING REVEALED
SOFTWARE TESTING REVEALED TRAINING BOOK SECOND EDITION BY INTERNATIONAL SOFTWARE TEST INSTITUTE www.test-institute.org COPYRIGHT INTERNATIONAL SOFTWARE TEST INSTITUTE Dedication To all of the International
More informationGuaranteed Value Projects in Legacy Modernization. Michael Oara VP for R&D Relativity Technologies, Inc.
Guaranteed Value Projects in Legacy Modernization Michael Oara VP for R&D Relativity Technologies, Inc. Business Problem Mainframe Applications Key Attributes Millions of lines of code, poorly documented
More information