In the Senior Design Center

Slides:



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

Test process essentials Riitta Viitamäki,
Test Automation Success: Choosing the Right People & Process
1 Software Engineering Lecture 11 Software Testing.
David Woo (dxw07u).  What is “White Box Testing”  Data Processing and Calculation Correctness Tests  Correctness Tests:  Path Coverage  Line Coverage.
Software Testing. “Software and Cathedrals are much the same: First we build them, then we pray!!!” -Sam Redwine, Jr.
Project Documentation and its use in Testing JTALKS.
Software Testing Prasad G.
Introduction to Software Testing
1 CSc Senior Project Software Testing. 2 Preface “The amount of required study of testing techniques is trivial – a few hours over the course of.
Software Quality Assurance and Testing prof. A. C. (Alex) Telea Course description.
What is Software Engineering? the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”
Software Testing. Definition To test a program is to try to make it fail.
Acceptance Testing Senior Design Fall 2013
CMSC 345 Fall 2000 Unit Testing. The testing process.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
Testing Workflow In the Unified Process and Agile/Scrum processes.
Submission System & GIT + Testing Expectations Ignacio X. Domínguez Fall 2015.
From Quality Control to Quality Assurance…and Beyond Alan Page Microsoft.
16 October Reminder Types of Testing: Purpose  Functional testing  Usability testing  Conformance testing  Performance testing  Acceptance.
Software Construction Lecture 18 Software Testing.
1 Legacy Code From Feathers, Ch 2 Steve Chenoweth, RHIT Right – Your basic Legacy, from Subaru, starting at $ 20,295, 24 city, 32 highway.
Confidential Continuous Integration Framework (CIF) 5/18/2004.
Software Testing White Box Testing. Agenda What is White Box Testing Correctness Tests and Path Coverage Correctness Tests and Line Coverage McCabe Cyclomatic.
CPSC 873 John D. McGregor Session 9 Testing Vocabulary.
Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)
Software Quality Assurance and Testing Fazal Rehman Shamil.
PROGRAMMING TESTING B MODULE 2: SOFTWARE SYSTEMS 22 NOVEMBER 2013.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
Testing Integral part of the software development process.
Software Testing. Software Quality Assurance Overarching term Time consuming (40% to 90% of dev effort) Includes –Verification: Building the product right,
Software Testing Kobla Setriakor Nyomi Faculty Intern (Programming II)
In the Senior Design Center
Subject Name: Software Testing Subject Code: 10CS842 Prepared By:
Software Testing.
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
Testing Tutorial 7.
Software Testing Basics
Integration Testing.
Use Cases Discuss the what and how of use cases: Basics Benefits
John D. McGregor Session 9 Testing Vocabulary
Approaches to ---Testing Software
SOFTWARE TESTING OVERVIEW
Software Testing.
Software Testing An Introduction.
Chapter 13 & 14 Software Testing Strategies and Techniques
IS442 Information Systems Engineering
John D. McGregor Session 9 Testing Vocabulary
In the Senior Design Center
John D. McGregor Session 9 Testing Vocabulary
Introduction to Software Testing
A Few Review Questions Dan Fleck Fall 2009.
Testing and Test-Driven Development CSC 4700 Software Engineering
Fundamental Test Process
A Few Review Questions.
In the Senior Design Center
Introducing ISTQB Agile Foundation Extending the ISTQB Program’s Support Further Presented by Rex Black, CTAL Copyright © 2014 ASTQB 1.
CS240: Advanced Programming Concepts
Course: Module: Lesson # & Name Instructional Material 1 of 32 Lesson Delivery Mode: Lesson Duration: Document Name: 1. Professional Diploma in ERP Systems.
CSE 303 Concepts and Tools for Software Development
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Automated test.
Applying Use Cases (Chapters 25,26)
Applying Use Cases (Chapters 25,26)
Java & Testing.
Test Cases, Test Suites and Test Case management systems
Automated test.
Presentation transcript:

In the Senior Design Center Software Testing In the Senior Design Center few easy questions: 1. Why test software? 2. Can you ship untested software in industry?

Senior Design Center - Fall 2015 Software Testing Why now? Development method requires it Create & maintain a test plan as you develop Possible need to design for testing Senior Design Center - Fall 2015

Senior Design Center - Fall 2015 What We Expect Your project includes a test plan Documented in your written reports With updates included in your oral reports What’s a test plan? “Oh, we definitely plan to thoroughly test our project.” “We’ll be using Selenium and JUnit to test our project.” Not a Test Plan Also Not a Test Plan Senior Design Center - Fall 2015

Senior Design Center - Fall 2015 What We Expect Unit testing Usually automated / easily repeatable Usually white-box tests So, you can use metrics like code coverage to show you’ve done a good job reasonably thorough job executing paths that may surface faults, failures, or errors Acceptance testing Usually manual (still repeatable, but with effort) You can automate yours, if you want. Usually black box tests of the whole system You can compare against requirements to show you’ve done a good job. Senior Design Center - Fall 2015

Senior Design Center - Fall 2015 Acceptance Testing A suite of multiple acceptance test cases Usually a few for each functional requirement. Maybe a few supporting non-functional requirements Performance / resource usage? Response Time? These can be written early As you develop requirements Revise and extend as the requirements mature What does a test case look like? Senior Design Center - Fall 2015

(Bad) Acceptance Test Cases Test ID Description Expected Results Actual Results restaurantSearch1 Preconditions: The system is loaded. Jason is a registered user of the system. Jason has authenticated and is at the homepage. Steps: Enter a type of restaurant. System reports all the nearby restaurants of that type. (Even if they are not as expected, or not yet implemented) Unique IDs! Specific Steps and Results?

(Better) Acceptance Test Cases Test ID Description Expected Results Actual Results restaurantSearch1 Preconditions: The system is loaded. Jason is a registered user of the system. Jason has authenticated and is at the homepage. Steps: Enter “sushi” as the restaurant type. System reports all the nearby sushi restaurants. FAIL Why? Still vague. Better

(OK) Acceptance Test Cases Test ID Description Expected Results Actual Results restaurantSearch1 Preconditions: The system is loaded. Jason is a registered user of the system. Jason has authenticated and is at the homepage. Steps: Enter “sushi” as the restaurant type. System reports: Sushi Hut (1 mile away) McSushi (3 miles away) Sushi King (4 miles away) FAIL: The interface does not have an input field that allows a user to indicate restaurant type Good But, how do you know you’ll get this?

Senior Design Center - Fall 2015 Acceptance Testing Acceptance tests are usually supported by test data Created by the team Example users, example accounts, example data Should be simple (so you and anyone else can tell what the right system behavior should be) Acceptance test plan should include Explanation of what you’re testing How to set up for each suite of tests What the test data is (are) like The table of test cases Discussion of test results. Senior Design Center - Fall 2015

Pro-Tip for Acceptance Testing Don’t copy-and-paste From expected to actual results  Senior Design Center - Fall 2015

Pro-Tip for Acceptance Testing Don’t copy-and-paste From expected to actual results  From one test case to another  This creates a maintenance problem. Tests should be independent of each other Senior Design Center - Fall 2015

Pro-Tip for Acceptance Testing Don’t copy-and paste From expected to actual results  From one test case to another  This creates a maintenance problem. Tests should be independent of each other Instead, factor common steps into the test set-up. Senior Design Center - Fall 2015

Senior Design Center - Fall 2015 Unit Testing With unit testing, we take advantage of what we know about the implementation. We have access to the source code We know how it’s organized into components We know the dependency structure We can do things we couldn’t do in acceptance testing We can test individual components (in an order that makes sense) We can measure code coverage (to see if we’ve done a good job reasonably thorough job executing paths that may surface faults, failures, or errors) Senior Design Center - Fall 2015

Senior Design Center - Fall 2015 Unit Testing Coverage expectations The Course Pack says to plan for 70% statement coverage But, the right coverage targets depend on the component under test You could achieve 100% statement coverage … and still have bugs Coverage != Quality Senior Design Center - Fall 2015

Senior Design Center - Fall 2015 Unit Testing Your project will probably have different components Maybe in different languages Maybe requiring different approaches to unit testing This is going to require some explanation Unit test plan should include Explanation of what you’re testing Explanation of your choice of testing tools How to run the unit tests Code coverage report Discussion of test results Senior Design Center - Fall 2015

Testing in OPR 1 You can report on: Testing strategy Testing tools Progress so far A glimpse into your acceptance test plan? Number of tests, how they’re organized, number passing? Preliminary unit test results? Number of tests, how they’re organized, coverage?

Traceability to Requirements The quantity of black-box tests is not important! Instead: are you thoroughly testing against the requirements? A mapping of test cases to requirements can identify areas that need more testing traceability matrix FR 1.1 FR 1.2 UC2-S3 UC3-AF1 testID1 X testID2 testID3 testID4 Senior Design Center - Fall 2015

Testing in Senior Design Every project is different You’ll need to figure out the right way to assure the quality of your project With help from your sponsor … and your technical advisors This may include some additional forms of testing Performance testing? Usability testing? Stress testing? Ask questions and get help early Testing resources on the SDC website Senior Design Center - Fall 2015