New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Informatics 43 week 7 notes

by: Apurva

Informatics 43 week 7 notes IN4MATX

Marketplace > University of California - Irvine > IN4MATX > Informatics 43 week 7 notes
GPA 3.9

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Topics covered in week 7- testing, failure, design, etc
Class Notes
25 ?





Popular in Department

This 47 page Class Notes was uploaded by Apurva on Monday May 16, 2016. The Class Notes belongs to IN4MATX at University of California - Irvine taught by NAVARRO, E. in Fall 2015. Since its upload, it has received 8 views.


Reviews for Informatics 43 week 7 notes


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 05/16/16
Informatics 43 LECTURE 7-2 EMILY NAVARRO Last Time • We use HCI/UCD methods… • Interviews/observations, personas, scenarios, storyboards, swimminglane diagrams, site maps, mockups, design guidelines, heuristic evaluation, user testing • …for good reasons • Sales double • Performance doubles • Traffic counts increase • It’s all about the user! Today’s lecture • Failures: a second look • Quality assurance • Testing • Quiz 4 study guide Today’s lecture • Failures: a second look • Quality assurance • Testing • Quiz 4 study guide What do these have in common? • Airbus 320 • Toyota • Mariner 1 launch • AT&T telephone network • Ariane 5 • Mars Polar Landing • Radiation therapy machine • NSA • Y2K They all failed! • Airbus 320 • • Toyota • “unintended” acceleration problem • Mariner 1 launch • • AT&T telephone network • Ripple effect, from switch to switch, network down/dark for 2 -3 days • Ariane 5 • • Mars Polar Landing • /spacenews/ releases/2000/mpl/mpl_report_1.pdf • Radiation therapy machine • • Y2K Toyota Failure • Overly complex spaghetti code • Violated standards set by the industry • Single-point failures • No peer code reviews • System threw away error codes Toyota  did  not  follow  good  quality  assurance  practices Y2K Facts • Bug description • Date formats were MM/DD/YY, e.g., 01/01/98, 02/02/99, 03/03/00 • Does 00 mean 2000 or 1900? • Does 1999 turn to 19100? • Effects • Relatively minor • Cost: $300 billion! Impact of Failures • Not just “out there” • Space shuttle • Rocket • Mars Polar Landing • But also “at home” • Your car • Your call to your mom • Your wireless network, social network, mobile app • Your homework • Your hospital visit Peter  Neumann’s  Risks Today’s lecture • Failures: a second look • Quality assurance • Testing • Quiz 4 study guide QA Goals: Verification and Validation • Quality Assurance = All activities designed to measure and improve quality in a product Validation • Verification:“Implementthe idea properly” • Validation: “Implementthe proper idea” Why do we need QA? Ideal world scenario: Complete   formal  specification of  problem  to  be  solved Correctness -­‐preserving  transformation Design,  in  formal  notation Correctness -­‐preserving  transformation Code,  in  verifiable  language Correctness -­‐preserving  transformation Executable  machine  code Correctness -­‐preserving  transformation Execution  on   verified  hardware Why do we need QA? Real world scenario: Mixture  of  formal  and informal  pecifications Manual  transformation Design,  in  mixed  notation Manual  transformation Code,  in  C++,  Java,  Ada,  … Compilation  by  commercial  compiler (Intel  Pen-­‐based)  machine  code Commercial  firmware Execution  on   commercial  hardware Why is QA so difficult? (I) Real  needs Actual “Correct” Specification Specification Why is QA so difficult? (II) Reliability Why is QA so difficult? (III) • Complexdata communications • Electronic fund transfer • Distributed processing • Web search engine • Stringent performance objectives • Air traffic control system • Complexprocessing • Medical diagnosis system Why is QA so difficult? (IV) Project Management QualiGroup Assurance DeGroupment Why is QA so difficult? (V) • Quality assurance lays out the rules • You will check in your code every day • You will comment your code • You will… • Quality assurance also uncoversthe faults • Taps developers on their fingers • Creates image of “competition” • Quality assurance is viewed as cumbersome, “heavy” • “Just let me code” QA Techniques • Formal methods • Static analysis of program properties • Reviews and inspections • Testing Use  a  mixture  of  techniques! Today’s lecture • Failures: a second look • Quality assurance • Testing • Quiz 4 study guide Testing – Basic Process • Detect and correcterrors in a software product • Exercise a module, collectionof modules, or system • Devise test case (input) • Create expected output • Run test case • Capture actual output • Compare actual output to expected output Actual output = expected outputctual output ≠ expected output Test casSUCCEEDS Test caseFAILS (report failure) • (Lather, rinse, and repeat) Testing Terminology Error  (human  mistakeprogrammer’s  mind) Fault  or  dt   iscrepancyin  code) Failure(  external  behaexecution/output  is  incorrect) Poor Mrs. Null… “I feel likeI still haveto do things the old-fashioned way.” – Jennifer Null Source: /future/story/20160325-the-names-that-break-computer-systems Testing Goals • Find and fix f ailures/faults/errors • Improve confidencethat the system performs as specified(verification)and as desired (validation) • All in a manner that is • Accurate • Complete Thorough • Repeatable • Systematic Program  testing  can  be  used  to  show  the  presence of  bugs,  but  never  to  show  their  absence  [Dijkstra] Who does the testing? • Programmers • Testers • Users Levels of Testing • Unit testing • Testing of a single code unit • Functional/integration testing • Testing of interfaces among integrated units • System/acceptance testing • Testing of complete system for satisfactionof requirements Levels of Testing Logic HMM Ticket Database Matcher Int:  id List<Ticket>:   openTickets UI String: description List<TA>:  availableTAs Customer: customer Logic TA:ta match() setTA() getId() Unit  testing Functional/integration  testingSystem/acceptance  testing Ticket.setTA() Matcher.match() Create  ticket Pay  ticket Login How to choose test cases? • There are usually an infinite number of possibletest cases, so we must take a small sample int mureturn a * b;a, int b) { } Ways to choose test cases • Intuition • Specification(black-box testing) • Equivalence class partitioning • Boundary-value analysis • Code (white -box testing) • Path analysis • Existing test cases (regression testing) • Faults Test Oracles • A mechanism for deciding whether a test case execution succeeds or fails • Difficult to automate Oracle Example: Cosine • Your test executionshows cos(0.5) = 0.87758256189 • Oracles? • Drawing a triangle and measuring the sides • A cosine table in a book • A website • Computing the value using Taylorseries expansion • Calculator Two Overall Testing Approaches • Black box testing • Specification-based testing • White box testing • Structural testing All software has bugs! "All nontrivial code has defects , and the probability of nontrivial defects increases with code size. The more code you use to solve a problem, the harder it gets for someoneelse to understand what youdid and to maintain your code whenyou have movedon to write still larger progra”s. - Code Inflation, Holzmann(IEEE SW 2015) All software has bugs! Q: What is the required period of failure-free operation for conventional takeoffs and landings of the F35 Joint Strike Fighter? A) 6,000 years B) 600 years C) 60 years D) 6 hours All software has bugs! Q: What is the required period of failure-free operation for conventional takeoffs and landings of the F35 Joint Strike Fighter? A) 6,000 years B) 600 years C) 60 years D) 6 hours AND a recent governmentreportstated that this target had not yet been realized! Some bugs are bizarre… Source: Some bugs are long- lived… Source: /2015/09/thanks-google-tcp-team-for-open-source.html Some bugs are not bugs… Source: /show_bug.cgi?id=362178 How do we know when we are done testing? • Aim to reveal as many faults as possible in afixed period of time with a budget • Target specific areas of the system • Aim to meet the quality requirements established for the project How do we know when we are done testing? Could  stop  testing  when  the   problem  find  rate  stabilizes  to   Number  of   near  zero problems   found  per   hour Time Day Day Day Day Day 1 2 3 4 5 How do we know when we are done testing? -­‐-­‐ 100% in  module   being  tested Sweet  spot?   Number  of  test  cases  with  correct  outputs How do we know when we are done testing? • Pepper thecode with defects and observe how many of the seeded defects are discovered • From this, infer how many bugs are left to find • This techniqueassumes thatnonseeded defects are similar to the seeded ones Summary • Many failures are caused by a lack of good quality assurance (QA) practices • QA = All activities designed to measure and improve quality in aproduct • Validation & verification • Testing is the most common QA activity • Different levels: unit/functional/system • Goal: find and fix failures/faults/errors • Can never be exhaustive • Can never prove a system’s correctness • All software has bugs! Today’s lecture • Failures: a second look • Quality assurance • Testing • Quiz 4 study guide Quiz 4 – Topics (1) • Designs/models/notations • Approaches to software design • Purposes of the different types of diagrams presented • For UML, only classdiagrams • User orientation • Understand the 10 user-centered design methods • Understand all the Nielsen heuristicsDiscussionexercise) Quiz 4 – Topics (II) • Testing • Validation/verification • Error, fault, failure • Levels of testing • Oracles • Readings - know main idea of: • LinkedIn story • “GoodUX” article • Toyota article Next Time • Black box testing • Attend discussion tomorrow (user orientation)


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."

Janice Dongeun University of Washington

"I used the money I made selling my notes & study guides to pay for spring break in Olympia, Washington...which was Sweet!"

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.