The document discusses various techniques for testing software such as black box testing, white box testing, coverage-based testing, model-based testing, property-based testing, and agile testing. It provides details on different types of coverage like code coverage, data coverage, and model-based coverage. It also describes different testing techniques like equivalence partitioning, input domain testing, and syntax generation that can be used with model-based testing. The document emphasizes applying critical thinking skills to testing and considering different perspectives.

1. Thinking like a tester
You are a detective and a scientist
Learn to love solving mysteries!

2. Reflection “Tortoise”
Logical Thinking de-bias get more data solicit
Suspend judgment formal models review
consider alternatives statistical thinking
Reflex “Hare”
Norms habits priming emotions assumptions
coherence “brain-only” heuristics
inattention blindness memorable examples

3. Needed Skills
Ask Useful questions
Observe-describe
Critical thinking
Recognize and manage bias
Design to test
Thinking even if you know, or don't see what you want
Think like new users
Facts are what we believe we know at this moment

4. Testing is about questions ..
posing them and answering them
Huh? You do not understand
the results or the
communication
Really? What you understand
may not be true
And? You may not know
everything that is there
So? You may be setting the
risk to low or too high.
Explicit: can be complete in a
string of bits (software or a
photo)
Knowledge types:
Tacit: unspoken, unwritten,
(like “common
knowledge”)

5. – apply them everywhere.
Stating assumptions might lead to a good test.
Words and Pictures
Causation
The Product
Design and behavior
The project
Schedules
Infrastructure
The test strategy itself
Coverage, oracles and procedures

6. Testing and the Software Life Cycle
Requirements analysis and specifications
Review requirements
for correctness, coverage and testability
Start your test plan!
Criteria and coverage
Software and hardware needed
Outline testing strategy
Create test scenarios

7. Testing and the Software Life Cycle
System and software design
Verify that the design meets the requirements
Develop coverage criteria
Code coverage
Data coverage
Develop acceptance test plan
Design usability tests

8. Testing and the Software Life Cycle
Implementation
Create and run unit test checks and cases
Create automatic test checks and cases, and test the
data
Review and inspect the source code

9. Testing and the Software Life Cycle
Integration
Once the unit test is complete, and the code is stable,
multi-component testing can start
Function
Stress
Scalability
Performance
Create and add automated tests
Update regression tests

10. Testing and the Software Life Cycle
Deployment
Perform Systems Testing
Real-life user scenarios
Validate requirements, both functional and non-
functional
User Acceptance Testing
After System testing
Make sure user needs and criteria are met (Alpha and
Beta)
Usability Testing
Might involve customers as well

11. Testing and the Software Life Cycle
Operations and maintenance
Manage and handle user problem and new requirements
Execute regression testing for any changes
• Code
• System
• Updates and patches of dependencies

12. White Box Testing

13. White- or clear-box testing is where you have access to
the code, and can use that knowledge to write tests or
conduct them on the code itself.
This is a typical activity where developers write their
own tests - automated or manual - to make sure the
units work, and meet the design criteria.

14. Black Box Testing

15. Black-box testing is where tests are written to test that an
input gives a specific output, without the ability to see
the code, or even care about it.
An example is a user assisting with testing – they don't
care how the system is built, rather that it gives
expected responses to inputs.

16. Coverage:
Techniques to consider
while deciding
what to cover
& how well it needs covered

17. Code Coverage
The goal percentage of coverage is in the requirements.
This may include (to reach the goal percentage)
Statement – testing the lines of code
Path coverage – testing the paths the information flows
Branch coverage- testing the logical branches in the code

18. Data Coverage
You cannot reasonably have 100% data coverage- this
would mean testing every possible input.
Test boundary conditions
Maximum and minimum values, 0 positive and negative values
Test Typical data
The most common data, often gotten from customers
Test pre- and post- conditions
Look at code check assumptions made (division by zero error)
Test bad data
Illegal values, no data, too much or too little data, or uninitialized
variables

19. Model-Based Coverage
Uses a model of the system
to derive test cases.
Testers can take these
models to

Find values

Automate tests

Run and evaluate the
tests
Test Requirements
Specific things that should be
tested for
Test Criteria
Rules and processes for Test
Requirements
Part of model-based design, and
uses the model to represent the
desired behavior of a system
under test.
https://en.wikipedia.org/wiki/Model-based_testing

20. Property-Based Coverage
Properties are general rules
that describe a program’s
behavior One single rule
should logically be
applicable to all kinds of
input and output for a given
piece of code. It is operating
at a higher level, generically
describing the expected
outcome of an operation.
Property-based testing forces
the exploration of the
program’s behavior to see
what it can or cannot do.
The underlying assumption is that by
dynamic exploration, "unknown
unknowns" can be discovered.
The test would still show the
presence (and not the absence) of
bugs, but it should find a lot more
bugs.
https://propertesting.com/book_what_is_a_property.html

21. Agile Testing
Individuals and interactions
over processes and tools
Working software over
comprehensive
documentation
Customer collaboration
over contract negotiation
Responding to change over
following a plan
http://softwaretestingfundamentals.com/agile-testing/
We are uncovering better ways of testing software by
doing it and helping others do it.
Through this work we have come to value:

22. Ad Hoc Testing (Monkey Testing)
Normally used during
acceptance test, and the
defects are less likely to
be reproducible
The tester improvises the steps and arbitrarily executes
them (like a monkey typing while dancing) a method
of software testing without any planning and
documentation. The tests are conducted informally and
randomly without any formal expected results.

23. The percentage for each type of coverage is
specified in the Test Requirements.
Decide on the models and methods that will
give you the best coverage with minimal
duplication and maximum efficency.

24. Model techniques: Covering graphs
Graphs might come from:
Control Flow graphs Design structure
Finite State Machines and chart Use cases
They can:
Test path or reachable node coverage
Cover Edge pairs
Cover definition and use pairs

25. Model techniques: Covering Logic
Expressions
These are required in
safety- critical software.
Failure can mean loss of
lives.
This technique chooses a
subset of total truths to
the expressions, cover
predicates, and clauses.
Selecting the section and percentage of coverage is
critical. Exhaustive testing is impractical for even the
simple expressions. Careful selection of values can
minimize test counts while ensuring coverage.

26. Equivalence partitioning
This is a technique for finding the “edges” in your application –
where true and false can be tested quickly, and duplication of
effort minimized (a test for “Is a number between these two
values?” doesn't require testing all values)
As a white-box technique, you can accurately and
efficiently test the application.

27. Model techniques: Input domains
Interface approach:
Test the individual inputs
from parameters. This
can make it easy to
automate.
Function approach:
Test how the system should
behave. The tests are
more difficult to design,
but may be better or
fewer.
Input parameters define the scope of the input domain:
data from files, global variables, and user inputs. At
least one value from each domain should be tested.

28. Model techniques: Syntax generation
Computer languages have
certain rules to follow,
and this technique allows
you to verify that those
rules are followed
https://en.wikipedia.org/wiki/Backus–Naur_form
Tests are created from
syntax in:
Programs
Integration elements
Design documents
Input descriptions