A quick overview of some common types of testing: what they are used for, when they are done, and the errors that may be discovered.

1. Testing In The The Real
World
Testing types, reporting,
& why doing the
unexpected can be great.

2. The Pareto principle:
80 % of the important errors come from 20% of the code
All the tests should meet the customer requirements for risks.
Software testing should be performed by third party, to minimize
bias.
Exhaustive testing is not possible - we need the optimal amount of
testing, based on the risk assessment of the application.
All the test areas and coverages should be planned before
beginning.
Start testing with small parts and extend it to large parts.
You should strive for quality work, and be proud of it.

3. Smoke Testing
Testing for unstable software: not often sent to third parties
Verifies critical function
Does it start?
Does the interface function?
New systems
Before functional test
Before regression tests
Reject something badly broken

4. Sanity Testing (Tester Acceptance)
Does the fix seem to be rational?
Often unscripted and exploratory, to determine if the
fix/build is suitable for further testing.
Bundled with Smoke Testing in many cases, for time and
testing efficiency.

5. Unit Testing
Goal is to find errors, insure design, & all requirements are met
In a program, we are checking if the unit works as intended
Checks for misunderstood or incorrect arithmetic precedence
Avoids incorrect initialization
Needs to be independent
Focus is on the smallest units:
– functions
– loops
– classes

6. Unit Testing
The more code you have to
touch, the greater the
chances that you may miss
something - good automated
unit test cases help. Once
you make your changes, you
run all the unit tests for that
whole component where you
made the change.
A well-written unit test can
prove that changes did not
cause unexpected errors
Tests should:
Run quickly
Be repeatable
Test all the executable code
in that unit
Break logic into small
chunks

7. Regression Testing
Does old code work with new changes?
In addition to unit testing
Change in requirements
New fixture
Defect or performance fix
– Areas that have frequent defect or are visible to
users
– Boundary, Success and Failure tests

8. Integration Testing
Top- Down:
Some of the modules may not be available to test, or
they may represent an external system. The modules
are tested in relationship to each other, then touch the
'stubs'

9. Integration Testing
Bottom – up:
The lowest-level components are tested first to insure
they work, then the next 'layer' is added, using drivers
where needed. Can narrow down error locations.

10. Functional (End-to-End) Testing
This is what most think of
as “testing.”
All the individual parts
have been tested, and
they work together.
Does the system work as a
user would expect it to?
You test for requirements,
as well as business-based
scenarios.
Be careful when writing
your tests! Duplication is
easy, and logical errors
might be missed.

11. System Testing
Mostly Black-box “Does this give expected results?”
External interfaces
Multi-program/complex functions
Security and recovery
Installability and usability
Documentation
In other words:
Does this work for the user?

12. Load (Performance) Testing
Tests normal workload conditions
Does not break the system
Ensures that errors are trackable
May test rollover to a new client once a certain limit is
passed

13. Stress (Performance) Testing
Stress Testing: Extreme Conditions until failure
Application Stress: Finding locks and blocks, network
issues, and bottlenecks
Transactional Stress: Fine tuning the system between two
applications
Systemic Stress: What happens when one system blocks
another?
Exploratory Stress: One in a million scenarios – like the
database going offline when being accessed

14. Stress (Performance) Testing
Stress Testing: Extreme Conditions until failure
Manage and handle user problem and new requirements
Execute regression testing for any changes
• Code
• System
• Updates and patches of dependencies

15. Alpha Testing
Does the product work?
Focus is finding bugs and getting ready for Beta
Typically starts in the 60 -80% complete range
1 to 2 weeks per test cycle
Employee involvement for launch
Lots of bugs and crashes
Severe issues, and features may change

16. Beta Testing
Do customers like the product?
80 – 90% complete
3-6 week testing, normally no more than 2 cycles
Strangers testing the product
Mostly complete – small bugs, and missing things
Critical issues fixed – future plans made
Do your users find this useful, and are happy?

17. Field Testing
Done on real devices, away from the tester's lab or the
software development area.
This is a typical user in typical conditions that the
software is designed to assist with.
Field testing makes sure that the program works, under
typical user conditions:
Make sure you know what those are!