DOCSLIB.ORG

Quality Assurance in Software Development Qualitätssicherung in Der Softwareentwicklung

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Quality Assurance in Software Development Qualitätssicherung in Der Softwareentwicklung Institute for Software Technology tugraz Quality Assurance in Software Development Qualitätssicherung in der Softwareentwicklung A.o.Univ.-Prof. Dipl.-Ing. Dr. Bernhard Aichernig Institute for Software Technology Graz University of Technology Austria Summer Term 2019 B. Aichernig Quality Assurance in Software Development 1 / 20 Institute for Software Technology tugraz Agenda 1 Organisation 2 Contents 3 Quality of SW B. Aichernig Quality Assurance in Software Development 2 / 20 Institute for Software Technology tugraz Quality Assurance I Lecture: Tue 11:15 – 12:00 (i12) I Exercise: Tue 12:00 – 12:45 (i12) I Optional: Fri 14:15–15:00 (i12) I Registration via tugonline – 8.3. strict! I Student assistants: I Dominik Augustin I Jorrit Stramer B. Aichernig Quality Assurance in Software Development 3 / 20 Institute for Software Technology tugraz Additional Resources I WWW: http://www.ist.tugraz.at/qs.html I Newsgroup: tu-graz.lv.qs I Email: Subject: [QS19] I [email protected] B. Aichernig Quality Assurance in Software Development 4 / 20 Institute for Software Technology tugraz Marking I Marking if registered on 8.3. I Written exam (Klausur) : 25.6. (50 %). I Three practical tasks (groups of 3): I Task 1: 12.3.–2.4. (16 %) I Task 2: 2.4.–7.5. (16 %) I Task 3: 7.5–4.6. (18 %) I Exam and exercises count each 50% I Positive if > 50% total points and I > 30% on exam and I > 30% on exercises in total I Prüfungsabbruch: the registration to a group for the exercises counts as item of work. B. Aichernig Quality Assurance in Software Development 5 / 20 Institute for Software Technology tugraz Marking (cont.) Grading key: 50,01% - 62,50%: genügend 62,51% - 75,00%: befriedigend 75,01% - 87,50%: gut 87,51% - 100,0%: sehr gut Nachklausur: I Date: 9.7., 11:00 I After excused absence at exam I e.g. due to illness with sick certificate (ärztlicher Bestätigung) I work is no excuse (take leave!) I For all negative who have been excused at exam! B. Aichernig Quality Assurance in Software Development 6 / 20 Institute for Software Technology tugraz Plan Datum VO UE Tue 5.3. Organisation, Introduction Tue 12.3. Test Coverage Ausgabe Task 1 Tue 19.3. Symbolic and Concolic Execution Tue 26.3. Specifications 1 Tue 2.4. Tool Demo Abgabe Task 1, Ausgabe Task 2 Tue 9.4. Specifications 2 Osterferien Tue 30.4. Property- & Model-based Testing Tue 7.5. Tool Demo Abgabe Task 2, Ausgabe Task 3 Tue 14.5. Tue 21.5. Input-Output Conformance Tue 28.5. (Model-based) Mutation Testing Tue 4.6. Equivalence Classes and Test- Abgabe Task 3 Sequence Generation Di nach Pfingsten Tue 18.6. Decision Tables, White-box Test- ing, Reviews Tue 25.6. Written exam B. Aichernig Quality Assurance in Software Development 7 / 20 Institute for Software Technology tugraz What we will not cover? Quality management: I Process management, e.g. Scrum I Process improvement, e.g. ISO 9000 I Test management, e.g. IBM Rational Quality Manager I Version control, e.g. svn, git I ... B. Aichernig Quality Assurance in Software Development 8 / 20 Institute for Software Technology tugraz General Aims of the Course I Getting familiar with quality assurance techniques I Raising the awareness for quality of software I Practising fault-based thinking I Being able to distinguish process-oriented and technical quality assurance I Challenging common quality criteria I Realising the relations between the foundations of software engineering and quality assurance. I Learning the use and foundations of advanced testing tools. B. Aichernig Quality Assurance in Software Development 9 / 20 Institute for Software Technology tugraz Specific Learning Targets and Skills I Getting familiar with a professional IDE I Writing good tests :( I Generating good tests :) I Specifying test oracles I Using and understanding state-of-the-art test case generators I Test coverage metrics "Don’t write test cases, generate them!" (John Hughes) B. Aichernig Quality Assurance in Software Development 10 / 20 Institute for Software Technology tugraz Specific Learning Targets and Skills I Getting familiar with a professional IDE I Writing good tests :( I Generating good tests :) I Specifying test oracles I Using and understanding state-of-the-art test case generators I Test coverage metrics "Don’t write test cases, generate them!" (John Hughes) B. Aichernig Quality Assurance in Software Development 10 / 20 Institute for Software Technology tugraz Course Contents I Introduction and motivation I Challenges of software testing I Coverage: Measuring the quality of test cases I Testing with Concolic Execution I Contracts as test oracles I Model-based Testing I Mutation Testing I Reviews I (Proof-based Development) I Tools (exercise): I MS Visual Studio Enterprise 2015 I MS IntelliTest (Pex) I .NET Code Contracts I FsCheck B. Aichernig Quality Assurance in Software Development 11 / 20 Institute for Software Technology tugraz Course Contents I Introduction and motivation I Challenges of software testing I Coverage: Measuring the quality of test cases I Testing with Concolic Execution I Contracts as test oracles I Model-based Testing I Mutation Testing I Reviews I (Proof-based Development) I Tools (exercise): I MS Visual Studio Enterprise 2015 I MS IntelliTest (Pex) I .NET Code Contracts I FsCheck B. Aichernig Quality Assurance in Software Development 11 / 20 Institute for Software Technology tugraz Quality? I Today, often a sufficient level of I correctness I efficiency I costs cannot be guaranteed. I Vision: Development methods for SW with warranty. B. Aichernig Quality Assurance in Software Development 12 / 20 Institute for Software Technology tugraz Quality? I Today, often a sufficient level of I correctness I efficiency I costs cannot be guaranteed. I Vision: Development methods for SW with warranty. B. Aichernig Quality Assurance in Software Development 12 / 20 Marketing with App Institute for Software Technology tugraz Limited Warranties I Cisco: “Cisco does not warrant that the Software will operate uninterrupted or error-free or that all errors will be corrected. In addition, Cisco does not warrant that the Software or any equipment, system or network on which the Software is used will be free of vulnerability to intrusion or attack." Limited Warranty and Disclaimer, (c) Disclaimer; effective: May 22, 2017: (https://www.cisco.com/c/en/us/about/legal/ cloud-and-software/end_user_license_agreement.html) I Skydrop Sprinkler Controller:“This warranty does not cover consumable parts, including batteries, unless damage is due to defects in materials or workmanship of the Product, or software (even if packaged or sold with the product).” (https://www.skydrop.com/warranty/) B. Aichernig Quality Assurance in Software Development 13 / 20 Institute for Software Technology tugraz Limited Warranties I Cisco: “Cisco does not warrant that the Software will operate uninterrupted or error-free or that all errors will be corrected. In addition, Cisco does not warrant that the Software or any equipment, system or network on which the Software is used will be free of vulnerability to intrusion or attack." Limited Warranty and Disclaimer, (c) Disclaimer; effective: May 22, 2017: (https://www.cisco.com/c/en/us/about/legal/ cloud-and-software/end_user_license_agreement.html) I Skydrop Sprinkler Controller:“This warranty does not cover consumable parts, including batteries, unless damage is due to defects in materials or workmanship of the Product, or software (even if packaged or sold with the product).” (https://www.skydrop.com/warranty/) Marketing with App B. Aichernig Quality Assurance in Software Development 13 / 20 Institute for Software Technology tugraz Bugs Part of engineering jargon for many decades: I Moth trapped in relay of Mark II (Hopper 1946) I Little faults and difficulties (Edison 1878): I Software bugs Relay #70 Panel F (moth) in relay. First actual case of bug being found. B. Aichernig Quality Assurance in Software Development 14 / 20 Institute for Software Technology tugraz Bugs Part of engineering jargon for many decades: I Moth trapped in relay of Mark II (Hopper 1946) I Little faults and difficulties (Edison 1878): I Software bugs Relay #70 Panel F (moth) in relay. First actual case of bug being found. B. Aichernig Quality Assurance in Software Development 14 / 20 Institute for Software Technology tugraz Bugs Definition A software bug is the common term Part of engineering jargon for many used to describe an decades: error, flaw, mistake, failure, or Moth trapped in relay of Mark II I I fault in a computer program or (Hopper 1946) system Little faults and difficulties I that produces an incorrect or (Edison 1878): I unexpected result, I Software bugs I or causes it to behave in unintended ways. (Wikipedia 2012) B. Aichernig Quality Assurance in Software Development 14 / 20 Institute for Software Technology tugraz Some Bugs Become Famous! I Ariane 5 test flight (1996) I out of control due to software failure I controlled destruction! I Loss of I money and time I satellites I research (TU Graz) I Dijkstra (EWD 1036): I call it error, not bug I a programmer created it B. Aichernig Quality Assurance in Software Development 15 / 20 Institute for Software Technology tugraz Some Bugs Become Famous! I Ariane 5 test flight (1996) I out of control due to software failure I controlled destruction! I Loss of I money and time I satellites I research (TU Graz) I Dijkstra (EWD 1036): I call it error, not bug I a programmer created it B. Aichernig Quality Assurance in Software Development 15 / 20 Algorithm was proven correct! I Programming Pearls [Bentley86, Bentley00] I assuming infinite integers :( Institute for Software Technology tugraz Some Bugs Hide for a Long Time! Binary search bug in Java 1 public static I JDK 1.5 library (2006) 2 int binarySearch(int[] a,int key) 3 { I out of boundary access of 4 int low = 0; large arrays 5 int high = a.length - 1; 6 7 while (low <= high) { I due to integer overflow 8 int mid = (low + high) / 2; I 9 years undetected 9 int midVal = a[mid]; 10 11 if (midVal < key) 12 low = mid + 1; 13 else if (midVal > key) 14 high = mid - 1; 15 else 16 return mid;// key found 17 } 18 return -(low + 1);// key not found 19 } “Beware of bugs in the above code; I have only proved it correct, not tried it.” [Knuth77] B.
Load more

Recommended publications
  • Testing E-Commerce Systems: a Practical Guide - Wing Lam
    Testing E-Commerce Systems: A Practical Guide - Wing Lam As e-customers (whether business or consumer), we are unlikely to have confidence in a Web site that suffers frequent downtime, hangs in the middle of a transaction, or has a poor sense of usability. Testing, therefore, has a crucial role in the overall development process. Given unlimited time and resources, you could test a system to exhaustion. However, most projects operate within fixed budgets and time scales, so project managers need a systematic and cost- effective approach to testing that maximizes test confidence. This article provides a quick and practical introduction to testing medium- to large-scale transactional e-commerce systems based on project experiences developing tailored solutions for B2C Web retailing and B2B procurement. Typical of most e-commerce systems, the application architecture includes front-end content delivery and management systems, and back-end transaction processing and legacy integration. Aimed primarily at project and test managers, this article explains how to · establish a systematic test process, and · test e-commerce systems. The Test Process You would normally expect to spend between 25 to 40 percent of total project effort on testing and validation activities. Most seasoned project managers would agree that test planning needs to be carried out early in the project lifecycle. This will ensure the time needed for test preparation (establishing a test environment, finding test personnel, writing test scripts, and so on) before any testing can actually start. The different kinds of testing (unit, system, functional, black-box, and others) are well documented in the literature.
    [Show full text]
  • Interpreting Reliability and Availability Requirements for Network-Centric Systems What MCOTEA Does
    Marine Corps Operational Test and Evaluation Activity Interpreting Reliability and Availability Requirements for Network-Centric Systems What MCOTEA Does Planning Testing Reporting Expeditionary, C4ISR & Plan Naval, and IT/Business Amphibious Systems Systems Test Evaluation Plans Evaluation Reports Assessment Plans Assessment Reports Test Plans Test Data Reports Observation Plans Observation Reports Combat Ground Service Combat Support Initial Operational Test Systems Systems Follow-on Operational Test Multi-service Test Quick Reaction Test Test Observations 2 Purpose • To engage test community in a discussion about methods in testing and evaluating RAM for software-intensive systems 3 Software-intensive systems – U.S. military one of the largest users of information technology and software in the world [1] – Dependence on these types of systems is increasing – Software failures have had disastrous consequences Therefore, software must be highly reliable and available to support mission success 4 Interpreting Requirements Excerpts from capabilities documents for software intensive systems: Availability Reliability “The system is capable of achieving “Average duration of 716 hours a threshold operational without experiencing an availability of 95% with an operational mission fault” objective of 98%” “Mission duration of 24 hours” “Operationally Available in its intended operating environment “Completion of its mission in its with at least a 0.90 probability” intended operating environment with at least a 0.90 probability” 5 Defining Reliability & Availability What do we mean reliability and availability for software intensive systems? – One consideration: unlike traditional hardware systems, a highly reliable and maintainable system will not necessarily be highly available - Highly recoverable systems can be less available - A system that restarts quickly after failures can be highly available, but not necessarily reliable - Risk in inflating availability and underestimating reliability if traditional equations are used.
    [Show full text]
  • QA and Testing Have Become More of a Concurrent Process
    Special Feature: SW Testing “QA and testing have become more of a concurrent process rather than an end of lifecycle process” Manish Tandon, VP & Head– Independent Validation and Testing Solutions, Infosys Interview by: Anil Chopra, PCQuest n an exclusive interview with the PCQuest Editor, Manish talks become a software tester? about the global trends in software testing, skillsets required Software testing has evolved into a very special function and Ito enter the field, how technology has evolved in this area to anybody wanting to enter the domain requires two special provide higher ROI, and much more. An IIT and IIM graduate, skillsets. One is deep functional or domain skills to understand Manish is responsible for formulating and executing the business the functionality. Plus, you need specialized technical skills strategy for Independent Validation and Testing Solutions practice as well because you want to do automation, middleware, and at Infosys. He mentors the unit specifically in meeting business performance testing. It’s a unique combination, and we focus goals and targets. In addition, he manages critical relationships very strongly on both these dimensions. A good software tester with client executives, industry analysts, deal consultants, and should always have an eye for detail. So people who have a slightly anchors the training and development of key personnel. Provided critical eye and are willing to dig deeper always make much better here are his expert comments on the subject. testers than people who want to fly at 30k feet. Q> What are some of the global trends in the software Q> You mentioned that software testing is now required testing business? How do you see the market moving? for front-end applications.
    [Show full text]
  • Usage of Prototyping in Software Testing
    Multi-Knowledge Electronic Comprehensive Journal For Education And Science Publications (MECSJ) ISSUE (14), Nov (2018) www.mescj.com USAGE OF PROTOTYPING IN SOFTWARE TESTING 1st Khansaa Azeez Obayes Al-Husseini Babylon Technical Insitute , Al-Furat Al-Awsat Technical University,51015 Babylon,Iraq. 1st [email protected] 2nd Ali Hamzah Obaid Babylon Technical Insitute , Al-Furat Al-Awsat Technical University,51015 Babylon,Iraq. 2nd [email protected] Abstract: Prototyping process is an important part of software development. This article describes usage of prototyping using Question – and – Answer memory and visual prototype diesign to realize Prototyping software development model. It also includes review of different models of software lifecycle with comparison them with Prototyping model. Key word: Question – and – Answer , Prototype, Software Development, RAD model. 1. Introduction One of the most important parts of software development is project design. Software project designing as a process of project creation can be divided in two large parts (very conditional): design of the functionality and design of user interface. To design the functionality, tools such as UML and IDEF0 are used, which have already become industry standards for software development. In the design of the graphical user interface there are no established standards, there are separate recommendations, techniques, design features, traditions, operating conditions for software, etc. At the same time, an important, but not always properly performed, part of this process is prototyping, i.e. the creation of a prototype or prototype of a future system. Prototypes can be different: paper, presentation, imitation, etc., up to exact correspondence to the future program. Most of the modern integrated development environments for software (IDE) allows to create something similar to prototypes, but it is connected with specific knowledge of IDE and programming language.
    [Show full text]
  • Lecturer: Ting Wang (王挺)
    Lecturer: Ting Wang (王挺) 利物浦大学计算机博士 清华大学计算机博士后 电子信息技术高级工程师 上海外国语大学网络与新媒体副教授 浙江清华长三角研究院海纳认知与智能研究中心主任 New Media Product DevelopmentDesign and Dr. Ting WANG School of Journalism and Communication Haina Cognition and Intelligence Research Center Shanghai International Studies University Yangtze Delta Region Institute of Tsinghua University, Zhejiang An overview to Part 01 software testing Testing in the software development Project Manager (Requirement Analyzer) System Analysis Release Structure Designer System Analysis Quality Assurance Engineer Requirement Analyzer Structure Design Testing Structure Design Programmer Structure Designer V-model Coding Coding Programmer Waterfall model Testing Quality Assurance Engineer Release Project Manager What is software testing? Software Testing Definition according to ANSI/IEEE 1059 standard -- A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to evaluate the features of the software item. https://www.softwaretestingmaterial.com/software-testing/ “Testing shows the presence, not the absence of bugs.” —Edsger W. Dijkstra Edsger W. Dijkstra (May 11, 1930 - Aug 06, 2002) was a Dutch systems scientist, programmer, software engineer, science essayist, and pioneer in computing science. Bug Fault (also called “defect” or “bug”) is an erroneous hardware or software element of a system that can cause the system to fail. Reasons why software has bugs human mistakes in software design and coding. The longer a software bug exists throughout the product life-cycle, the more it costs. In 2002, software bugs cost the United States economy approximately $59.5 billion. In 2016, that number jumped to $1.1 trillion. https://dzone.com/articles/api-testing-best-practices 20 reasons for software bugs Reasons in development Reasons in testing #1) Miscommunication or No Communication #11) Not having a proper test setup (test environment) for testing all requirements.
    [Show full text]
  • Automated Testing of Firmware Installation and Update Scenarios for Peripheral Devices
    DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2019 Automated testing of firmware installation and update scenarios for peripheral devices DAG REUTERSKIÖLD KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Automated testing of firmware installation and update scenarios for peripheral devices DAG REUTERSKIÖLD Master in Computer Science Date: August 12, 2019 Supervisor: Hamid Faragardi Examiner: Elena Troubitsyna School of Electrical Engineering and Computer Science Host company: Tobii AB Swedish title: Automatisering av enhetsinstallation, uppdatering och testning med hjälp av virtuella maskiner iii Abstract This research presents an approach to transition from manual to automated testing of hardware specific firmware. The manual approach for firmware test- ing can be repetitive and time consuming. A significant proportion of the time is spent on cleaning and re-installing operating systems so that old firmware does not interfere with the newer firmware that is being tested. The approach in this research utilizes virtual machines and presents an automation framework. One component of the automation framework is an application to imitate con- nected peripheral devices to bypass hardware dependencies of firmware in- stallers. The framework also consists of automation and pipeline scripts with the objective to execute firmware installers and detect errors and abnormalities in the installation and updating processes. The framework can run on locally hosted virtual machines, but is most applicable using cloud hosted virtual ma- chines, where it is part of a continuous integration that builds, downloads, installs, updates and tests new firmware versions, in a completely automated manner. The framework is evaluated by measuring and comparing execution times with manually conducted installation and updating tests, and the result shows that the framework complete tests much faster than the manual approach.
    [Show full text]
  • Software Testing Revealed Training Book Second Edition by International Software Test Institute™
    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 Software Test Institute™ students, thank you for inspiring us, keeping us focused, and making sure we do our best to help you grow in your career with your skills and knowhow. Without you, your engagement and your loyal support, International Software Test Institute™ could not come where it is today. TABLE OF CONTENTS CLICKABLE WELCOME ........................................................................................................................6 ABOUT INTERNATIONAL SOFTWARE TEST INSTITUTE™ .....................................................7 Introduction To Software Testing ............................................................................8 What is Software Quality Assurance? ...................................................................12 What Is Software Testing? .......................................................................................18 Fundamentals of Software Testing ........................................................................21 Software Testing Roles and Responsibilities .......................................................30 Software Testing Methods ......................................................................................36 Software Testing Levels ..........................................................................................38 Software Testing
    [Show full text]
  • Empirical Evaluation of the Effectiveness and Reliability of Software Testing Adequacy Criteria and Reference Test Systems
    Empirical Evaluation of the Effectiveness and Reliability of Software Testing Adequacy Criteria and Reference Test Systems Mark Jason Hadley PhD University of York Department of Computer Science September 2013 2 Abstract This PhD Thesis reports the results of experiments conducted to investigate the effectiveness and reliability of ‘adequacy criteria’ - criteria used by testers to determine when to stop testing. The research reported here is concerned with the empirical determination of the effectiveness and reliability of both tests sets that satisfy major general structural code coverage criteria and test sets crafted by experts for testing specific applications. We use automated test data generation and subset extraction techniques to generate multiple tests sets satisfying widely used coverage criteria (statement, branch and MC/DC coverage). The results show that confidence in the reliability of such criteria is misplaced. We also consider the fault-finding capabilities of three test suites created by the international community to serve to assure implementations of the Data Encryption Standard (a block cipher). We do this by means of mutation analysis. The results show that not all sets are mutation adequate but the test suites are generally highly effective. The block cipher implementations are also seen to be highly ‘testable’ (i.e. they do not mask faults). 3 Contents Abstract ............................................................................................................................ 3 Table of Tables ...............................................................................................................
    [Show full text]
  • Effective Methods for Software Testing
    Effective Methods for Software Testing Third Edition Effective Methods for Software Testing Third Edition William E. Perry Effective Methods for Software Testing, Third Edition Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2006 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN-13: 978-0-7645-9837-1 ISBN-10: 0-7645-9837-6 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 3MA/QV/QU/QW/IN No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copy- right Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no repre- sentations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fit- ness for a particular purpose. No warranty may be created or extended by sales or promo- tional materials.
    [Show full text]
  • Chapter2: Testing Throughout Lifecycle
    ISTQB Certification Preparation Guide: Chapter 1 – Testing Through Lifecycle Chapter2: Testing throughout Lifecycle "What is clear from the Inquiry Team's investigations is that neither the Computer Aided Dispatch (CAD) system itself, nor its users, were ready for full implementation on 26th October 1992. The CAD software was not complete, not properly tuned, and not fully tested. The resilience of the hardware under a full load had not been tested. The fall back option to the second file server had certainly not been tested." Extract from the main conclusions of the official report into the failure of the London Ambulance Service's Computer Systems on October 26th and 27th 1992. 2.1 OVERVIEW This module covers all of the different testing activities that take place throughout the project lifecycle. We introduce various models for testing, discuss the economics of testing and then describe in detail component, integration, system and acceptance testing. We conclude with a brief look at maintenance testing. After completing this module you will: 2.2 OBJECTIVES Ø Understand the difference between verification and validation testing activities Ø Understand what benefits the V model offers over other models. Ø Be aware of other models in order to compare and contrast. Ø Understand the cost of fixing faults increases as you move the product towards live use. Ø Understand what constitutes a master test plan. Ø Understand the meaning of each testing stage. http://www.softwaretestinggenius.com/ Page 1 of 22 ISTQB Certification Preparation Guide: Chapter 1 – Testing Through Lifecycle 2.3 Models for Testing This section will discuss various models for testing.
    [Show full text]
  • Pdf: Software Testing
    Software Testing Gregory M. Kapfhammer Department of Computer Science Allegheny College [email protected] I shall not deny that the construction of these testing programs has been a major intellectual effort: to convince oneself that one has not overlooked “a relevant state” and to convince oneself that the testing programs generate them all is no simple matter. The encouraging thing is that (as far as we know!) it could be done. Edsger W. Dijkstra [Dijkstra, 1968] 1 Introduction When a program is implemented to provide a concrete representation of an algorithm, the developers of this program are naturally concerned with the correctness and performance of the implementation. Soft- ware engineers must ensure that their software systems achieve an appropriate level of quality. Software verification is the process of ensuring that a program meets its intended specification [Kaner et al., 1993]. One technique that can assist during the specification, design, and implementation of a software system is software verification through correctness proof. Software testing, or the process of assessing the func- tionality and correctness of a program through execution or analysis, is another alternative for verifying a software system. As noted by Bowen, Hinchley, and Geller, software testing can be appropriately used in conjunction with correctness proofs and other types of formal approaches in order to develop high quality software systems [Bowen and Hinchley, 1995, Geller, 1978]. Yet, it is also possible to use software testing techniques in isolation from program correctness proofs or other formal methods. Software testing is not a “silver bullet” that can guarantee the production of high quality software systems.
    [Show full text]
  • Beginners Guide to Software Testing
    Beginners Guide To Software Testing Beginners Guide To Software Testing - Padmini C Page 1 Beginners Guide To Software Testing Table of Contents: 1. Overview ........................................................................................................ 5 The Big Picture ............................................................................................... 5 What is software? Why should it be tested? ................................................. 6 What is Quality? How important is it? ........................................................... 6 What exactly does a software tester do? ...................................................... 7 What makes a good tester? ........................................................................... 8 Guidelines for new testers ............................................................................. 9 2. Introduction .................................................................................................. 11 Software Life Cycle ....................................................................................... 11 Various Life Cycle Models ............................................................................ 12 Software Testing Life Cycle .......................................................................... 13 What is a bug? Why do bugs occur? ............................................................ 15 Bug Life Cycle ............................................................................................... 16 Cost of fixing bugs .......................................................................................
    [Show full text]