Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

7 Ways to Find Software Defects by Matt Heusser by Mind Map: 7 Ways to Find Software
      Defects by Matt
5.0 stars - 1 reviews range from 0 to 5

7 Ways to Find Software Defects by Matt Heusser

#2: Equivalence & Boundary Conditions

Behavior & criteria rules

Insurance example

Ages 0-91 (do you really want to do 92 test cases?)

Each test case, Multiplied by number of points on license, Variety of available discounts, Types of coverage, Other varables, Lots of test cases! Combinatorial explosion

Boundary testing, Instead of 92 test cases, put ages into groups of 8 columns, Table,, Test each column once, Data within a column might be equal or equivalent, Designed to catch off-by-one errors, Program used "greater than" to compare two numbers, Should have used "greater than or equal to", Catches "age 45 problem" (see doc), Test every transition, both before & after, All cases are covered, A technique to reduce an infinite test set into something manageble, Shows that requirements are covered, Look out for other hidden classes that may exist

#7: Regression & High-volume Test Techniques

Prove out new functionality

Make sure nothing broke previous version

Make sure software did not regress (something worked yesterday but fails today)


Record input & output data

Send input data to old/new versions of app

Gather/compare output (recorded output)

If output is different, possible bug

#6: Code-based Coverage Models

Statement Coverage

Turn on when you start testing

Turn off when testing finished

See which lines of code are untested (red)

Improve testing of red functions & branches

Tools that record every line of code executed

#5: Use case & Soap Opera Tests

Use cases

Who, what, why behaviors of users


How someone might use system

Soap opera tests

Crazy, wild combos of improbable scenarios

Can provide a quick, informal estimate of software quality

If succeeds, lesser test may work too

#4: State-transition Diagrams

Map through application

List places/pages

Links between places/pages

Tests for every transition thru application

Work w/team for "hidden" states

Compare other diagrams w/yours for differences, Can indicate gaps in requirements, Defects in software, Different expectations among team


#3: Common Failure Mode

Lose coverage

Many applications open at same time w/low memory device

#1: Quick Attacks


Little or no prior knowledge of system

Do not know the requirements

Attack system to send it into a state of panic by filling in the wrong thing


Leave required field blank

Different workflow than implied

Number field, Type alpha chars, Number too large for system to handle, If expects whole number, use decimal

Alpha field, Type numerics, Start > Run > charmap, French-Canadian & Spanish chars

Combine things programmers did not expect w/common failure modes of platform

Web app, Resize browser window, Flip back/forth quickly between tabs

Submit buttons should submit

Other, Test Heuristics Cheat Sheet (E. Hendrickson),, How to Break Web Software (Andrews/Whittaker),

Strengths/Weaknesses: Techniques 1-7

Combine techniques

What can be automated?

Which are business facing (human being uses)?

Which overlap?

Which are completely unrelated?


How many sets of possible inputs & transformations?

Limit ideas to ones that will provide the most information right now

Balance single tests we could automate in an hour vs. the 50 we could run by hand in that hour

Figure out what we learned in that hour & how to report it