Software testing techniques Software testing techniques Testing based on specifications Presentation on the seminar Kaunas University of Technology.

Slides:



Advertisements
Similar presentations
Object Oriented Analysis And Design-IT0207 iiI Semester
Advertisements

Testing Coverage Test case
Defect testing Objectives
Test process essentials Riitta Viitamäki,
Testing and Quality Assurance
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Objectives Understand the basic concepts and definitions relating to testing, like error, fault, failure, test case, test suite, test harness. Understand.
Testing an individual module
Software Testing. “Software and Cathedrals are much the same: First we build them, then we pray!!!” -Sam Redwine, Jr.
Software Testing Prasad G.
 What is Software Testing  Terminologies used in Software testing  Types of Testing  What is Manual Testing  Types of Manual Testing  Process that.
Types and Techniques of Software Testing
Software Testing & Strategies
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
1 Functional Testing Motivation Example Basic Methods Timing: 30 minutes.
Test Design Techniques
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
Terms: Test (Case) vs. Test Suite
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Verification and Validation Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Testing. What is Testing? Definition: exercising a program under controlled conditions and verifying the results Purpose is to detect program defects.
Objectives Understand the basic concepts and definitions relating to testing, like error, fault, failure, test case, test suite, test harness. Explore.
CPIS 357 Software Quality & Testing
Class Specification Implementation Graph By: Njume Njinimbam Chi-Chang Sun.
Introduction Telerik Software Academy Software Quality Assurance.
CMSC 345 Fall 2000 Unit Testing. The testing process.
Chapter 8 – Software Testing Lecture 1 1Chapter 8 Software testing The bearing of a child takes nine months, no matter how many women are assigned. Many.
SOFTWARE TESTING Scope of Testing  The dynamic Indian IT industry has always lured the brightest minds with challenging career.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Introduction to Software Testing. Types of Software Testing Unit Testing Strategies – Equivalence Class Testing – Boundary Value Testing – Output Testing.
Software testing techniques Software testing techniques Equivalence partitioning Presentation on the seminar Kaunas University of Technology.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
Black-box Testing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Project Management All projects need to be “managed” –Cost (people-effort, tools, education, etc.) –schedule –deliverables and “associated” characteristics.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Evaluating Requirements
Dynamic Testing.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
Information Technology Project Management, Seventh Edition.
Software Testing. Software Quality Assurance Overarching term Time consuming (40% to 90% of dev effort) Includes –Verification: Building the product right,
Software Testing.
PREPARED BY G.VIJAYA KUMAR ASST.PROFESSOR
Equivalence partitioning
Equivalence partitioning
Testing Tutorial 7.
Software Testing.
SOFTWARE TESTING OVERVIEW
Software Testing.
Chapter 8 – Software Testing
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Strategies For Software Test Documentation
Lecture 09:Software Testing
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
Software testing.
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Software Verification and Validation
Software Verification and Validation
Software Verification and Validation
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Presentation transcript:

Software testing techniques Software testing techniques Testing based on specifications Presentation on the seminar Kaunas University of Technology

Testing based on specifications The specification based tester checks the product's conformance with every statement in one or more reference documents. The documents might be formal specifications, user manuals, advertisements.

Reviewing a specification We can approach a spec from many different angles: What is it saying about the product? What claims does it make? Do you have enough information to understand the claims? Is some information missing? Are the claims accurate? Would all stakeholders understand the claims in the same way? Should the specified product be changed? Will the specified product be testable?

Features of testing based on specifications Refers to the process of testing a program based on what its specification says its behavior should be. In particular, we can develop test cases based on the specification of the program's behavior, without seeing an implementation of the program. We can develop test cases before the program even exists!

Testing based on specifications Quality of the system is compliance with the requirements specification. This course does not cover automated extraction of test ideas from specifications, nor the use of program comprehension tools. Instead, we assume the existence of a natural language specification that is analyzed by a human.

The human does such tasks as: identifying a set of reference documents; developing test ideas based on ambiguities or contradictions in the reference documents; developing lists of items or claims to be tested based on assertions in the reference document, and then associating test ideas with each; creating traceability matrices that list items or assertions to test, and test cases that tie to those.

,,Black box” testing A testing method when a program is viewed as a,,black box” disregarding it’s structure: only the input and output is know, not the actual code;,,Black box” testing is a method of software testing that tests the functionality of an application. Test cases are based on requirements specifications;

,,Black box” testing The plans for testing can be made in the early stages of the software development;,,Black box” testing usually performed by a separate person outside the development process, rather than the developer. This method of test can be applied to all levels of software testing: unit, integration, functional, system and acceptance.

,,Black Box” testing techniques: 1.Decision table testing 2.All-pairs testing 3.State transition table 4.Equivalence partitioning 5.Boundary value analysis

,,Black Box” testing techniques 1.Decision table testing - is the method where test cases are designed to execute the combinations of inputs. 2.All-pairs or pairwise testing - is a combinatorial software testing method that, for each pair of input parameters to a system, tests all possible discrete combinations of those parameters. 3.State transition table - is a systematic method of exploring or analyzing the behavior of an object that exhibits history dependent behavior.

,,Black Box” testing techniques 4.Equivalence partitioning - is the method, witch input data ​ divides into data classes and test cases are obtained from these classes. 5.Boundary value analysis - is the method that focuses on the boundary input values ​​.

,,Black box” testing scheme I O System Inputs Outputs Input, causing abnormal behavior. Outputs that indicate the presence of defects.

Examples illustrate the use of specification based tests The unifying feature of this work is that we start with the reference document and base our tests and testing strategy on what we read in the documents. Examples: MS Paint’s Undo function OpenOffice’s Zoom in function

MS Paint In this example we do Specification Based Testing by picking a piece of MS Paint’s specifications (the user manual) and making sure that the application conforms to it. We are going to focus on the specification of the Undo function. The specifications claim that the application can undo up to 3 changes, but that is not always true. If the user is editing graphics, there are cases when it can undo only 2 changes. If the user is editing text in a text box, it can undo only 1 change (the last letter).

OpenOffice In this example we perform Specification Based Testing by making sure that the specifications for the Zoom In function in OpenOffice are satisfied. OpenOffice is an open source multi-platform office suite. Its presentation component has a function Zoom In, which according to specifications, doubles the size of the current window. In reality, it requires the user to select the part that will be enlarged.

Strengths and blind spots Strengths Critical defense against warranty claims, fraud charges, loss of credibility with customers. Reduces support costs, customer complaints by ensuring that no false or misleading representations are made to customers. Blind spots Any issues not in the specification or treated badly in the specification.

Questions 1.Witch documents might be used for specifications based testing? 2.What are the features of testing based on specifications? 3.Witch level of software testing uses,,black box” testing? 4.What the techniques are for,,black box” testing?

Thank you for your attention!