8/9/2021

role of tester
l1 headlight of the project
test is done to find information
l2 your mission drivers everything u do
l3 you serve many clients
project manager
programmer
technical writer
technical support
martketing
top management, stockholders
user
l4 you discover things that will bug whose opinion matters
l5 find important bugs fast
test things that are changed before things that are the same
test core functions before contributing functions
test capability before reliability
test common situations before esoteric situations
test common threats before exotic threats
test high-impact problems before low-impact problem
test most wanted areas before areas not requested
l6 run with programmers
l7 question everything
l8 you focus on failure, so your clients can focus on success
l9 u will not find all the bug
l10 beware of testing completely
l11 u dont assure quality by testing
l12 never be a gatekeeper
l13 beware of the not-my-job theory of testing
l14 beware of becoming a process improvement group
l15 dont except anyone to understand testing or what u need to do it well
think like a tester
l16 testing is applied epistemology
l17 studying empistemology helps you test better
l18 testing is grounded in cognitive psychology
l19 testing is in your head
l20 testing requires inference, not just comparison of output to expected results
l21 good testers think technically, creatively, critically and practically
l22 black box testing is not ignorance-based testing
l23 a tester is more than a tourist
l24 all tests are an attempt to answer some question
l25 all testing is based on models
l26 intuition is a fine beginning, but a lousy conclusion
l27 to test, u must explore
l28 exploring involves a lot of thinking
forward thinking
backward thinking
lateral thinking
l29 use the logic of abductive inference to discover conjectures
abductive inference: reasoning to the best explanation
l30 use the logic of conjecture and refutation to evaluate a product
l31 a requirement is a quality or condition that matters to someone who matters
l32 u discover requirement by conference, inference and reference
l33 use implicit as well as explicit specifications
l34 " it works" really means it appears to meet some requirement to some degree
l35 In the end, all u have is an impression of the product
l36 dont confuse the test with testing
the testing is anything that involves at least these four activities
configure prepare the product to test, put it into the right starting state
operate feed the product data, give it commands, interact with it in some way
observe collect information about how the product behave, output data, the st
evaluate apply rules, reasoning, or mechanisms that will detect bugs in the dat
l37 when testing a complex product: plunge in and quit
l38 use heuristics to quickly generate ideas for tests

8/10/2021
l39 you cant avoid bias, but u can manage it
assimilation bias
confirmation bias
availability bias
primacy bias
recency bias
framing effect
prominence bias
representativeness bias
l40 u are harder to fool if u know u are fool
l41 when u miss a bug, check wether the miss is surprising or just the natural outcome of your strategy
l42 confusion is a test tool
l43 fresh eyes find failure
l44 avoid following procedures unless they followed you first
l45 when u create test procedures, avoid 1287
l46 one important outcome of a test process is a better, smarter tester
l47 u cant master testing unless u reinvent it
reason to reinvent to adapt it to new context
learn how it work
the way to learn testing take thing apart
ponder how they work
put them back together in new ways
 t starting state
ract with it in some way
have, output data, the state of the system as a whole...
ill detect bugs in the data u observe

ome of your strategy

testing techniques
l48 testing combines techniques that focus on testers, coverage, potential problems, activities, evaluation
testers who does the testing
coverage what gets tested
potential problem why u are testing (what risk u testing for)
activities how your test
evaluation how to tell whether the test passed or failed
l49 people-based techniques focus on who does testing
user testing testing with the types of people who typically would use you
alpha testing in-house testing performed by the test team
beta testing testing with tester who arent part of your organization and w
bug bashes in-house testing using anyone who is available
subject-matter expert testing
pair testing two tester work together to find bugs
eat your own dogfood your company uses prerelease versions of its own software
l50 coverage-based techniques focus on what gets test
function testing test every function, one by one
feature or function integration testing test several function together
menu tour walk through all of the menus and dialogs in a G
domain testing domain is a set that includes all possible value o
equivalence class analysis equivalence class is a set of values for a variabl
boundary testing the boundary values are smallest, smallest-1 an
best representative testing a best representative of an equivalence class is
input field test catalog or matrices
map and test all the way to edit a field
logic testing attempts to check every logical relationship in th
state-based testing walk the program through a large set of state an
path testing involves testing most or all subpath of a certain
statement and branch coverage design your test to achieve a high percentage of
configuration coverage measures the percentage of configuration test u
specification-based testing
requirements-based testing
combination testing
l51 problems-based techniques focus on why u testing ( the risk u are testing for)
l52 activity-based techniques focus on how u test
regression testing involves reuse of the same tests, so u can retest after chan
bug fix regression prove that the fix no good
old bug regression prove that a change the software has
side-effect regression involve retesting of substantial parts
prove that the change has caused so
smoke testing are often automate and standardized from one build to the
script testing manual testing, done by a junior tester
exploratory testing throughout the project, tester learns about the product, its m
guerilla testing a fast and vicious attack on the program
scenario testing
installation testing
load testing
long squence testing duration testing, endurance testing, reliability testing
 performance testing
l53 evaluation-base techniques focus on how to tell whether the test passed or failed
self-verifying data
comparison with saved results typicallly regression testing
comparison with a specification or other authoritative document
heuristic consistency
consistent with history
consistent with image
consistent with comparable products
consistent with claims
consistent with user s expectations
consistent within product
consistent with purpose
oracle-based testing
l54 classification of a technique depends on how you think about it
when any testing comes time to test, u still have same 5 five dimesions of decision
who will do the testing
what aspects of the program are u testing
what tpye of problems are u looking for
what task, specifically, will u do
how will u tell whether a test passed or failed
s, activities, evaluation

ho typically would use your product

of your organization and who are members of your product's target market
o is available

rsions of its own software

black box whitte box

menus and dialogs in a GUI product

cludes all possible value of a variable of a function
set of values for a variable that u consider equivalent
re smallest, smallest-1 and largest, largest+1 members of the class
of an equivalence class is a value that is at least as likely as any other value in class to expoxe an error in the software

y logical relationship in the program

ugh a large set of state and check the results carefully, every time
r all subpath of a certain type (the basic paths)
ieve a high percentage of line and branch coverage
age of configuration test u have run compared to the total number of configuration tests that u plan to run

so u can retest after change

he fix no good
a change the software has caused an old bug fix become unfixed
sting of substantial parts of the product
he change has caused something that used to work to now be broken
zed from one build to the next. Prove the new build is not worth testing

ns about the product, its market, its risk, the way in which it has failed previous test

g, reliability testing
ons of decision
or in the software