11 01 16 static testing (e.g., code inspection, static analysis)

Read "Head First" chapters 7-8.
Read Ron Patton "Software Testing" chapter 6.

How to select testing inputs

• equivalence partitions
• boundary cases
• forcing a statement or branch or error handler to archive coverage

all concern with input

Test oracle

The code checks whether the output is correct is called "test oracle".

• assertion
• regular code
• know the correct outputs look like
• compute the right output value for test, but the code itself may have bugs
• In some application domains (machine learning, data mining, simulation, optimization, search), it may not know the outputs in advance, or it may too expensive or impractical to compute on the fly.(NP problem). We call these "non-testable programs". There are various approaches to testing them not rely on oracle.
• Some time there is an oracle but the tester doesn't know what it is as they are not written in Req. or incomplete.

Test-to-pass vs. test-to-fail

initial testing is test-to-pass. Assume the SW minimally works.

most testing is test-to-fail, trying to find bugs in development lab before deployment.

That all concern about dynamic tests or plan tests.

static test

• static analysis: use static analysis tool to find code smells, resource leaks, simple bugs or code that is suspicious in some way.
• manual static testing, ala code review and code inspection. Informal code review happens on the fly by pair programming.

formal code review

• Why?
  • Find problems earlier
  • Find problems that dynamic testing can not find, such as unreachable code.
  • Helps cross-train developers in code written by other people
• Essential elements
  • find problem in code, not author
  • follow rules: length of time and code, predefined roles: moderator, recorders, authors
  • prepare: every one read in advance
  • write reports afterward: summarize how many problems, why, what, how to solve
• Basic idea of meeting
  • read code line by line
  • explain and discuss by developers or author
  • attendees include author, moderator, recorder, customer representatives, end user, customer, QA, tester
• goal

Find problems/ not fix

code should pass static analysis, clean

• problem classification
  • minor: author fix on own
  • moderate: moderator checks
  • severe: need another meeting

Test for web/mobile

• work for the past, current, future version of browser
• mobile devices for arbitrary screen size
• screen reading works? accessibility options

bug reports and change requests post on where?

• No email
• perhaps taskboard
• Yes!! Issue tracker

model for issue tracker

create -- open --> inprogress --> resolved -->closed --> possibly reopend

assign to someone

time spend

priority

answer who which when