Quality & Test Level

• Completion of work with quality is possible only if work is flowing at a truly sustainable pace. 
• Finding and maintaining that pace is possible only if active work in process (WIP) is less than the capacity of those doing the work
• Cramming things in before deadlines will almost always result in breaking your WIP limit thus impeding quality

Exploratory

UX, Usability, Security, Maintainability, Configurability, Branding

• Manually done via an inspection
• Interact with the system only through its user interface
• Is the UI configured to their liking? It is easy to use and understand?
• Did we put the customer branding in all the right places?
• Is this what the customer really needs?
• How we will deliver software updates/patches.
• How the customer can modify the system to suit their needs.
• Conducted in a "production-like" environment, on hardware that is the same as, or close to, what a customer will use.
• Sometimes a customer will hire an outside firm to do a security audit and/or intrusion testing.

Acceptance

Story, Functional, System, End-to-end, Edge-to-edge, UI

• Does the whole system work? 
• Did we build the right thing? 
• Should exercise the system end-to-end without directly calling its internal code (black box testing) 
• Interact with the system only from the outside: through its user interface, by sending messages as if from third-party system, by invoking its web services, by parsing reports, and so on. 
• Conducted in a "production-like" environment, on hardware that is the same as, or close to, what a customer will use. 
• Executable specification 
• Bound intimately to User Stories. They are the means whereby the users convince themselves that the stories are correctly implemented.
• Acceptance test can cover “non functional” validation as well.
• This include the following aspects:

1. Reliability, Scalability: Validated via a load test (volume testing, longevity testing). 
2. Efficiency: Validated via a performance test.
3. Recoverability: Validated via a stress test.
4. Usability: Validated via an inspection and demonstration to the customer. Is the UI configured to their liking? It is easy to use and understand?

Integration

• Does our code work against code we can`t change? 
• Code we can’t change = code from outside the team. example: public API such as persistence mapper, library from another team within our organisation, etc.. 
• Make sure that any abstraction we build over third-party code work as we expect. 
• Help tease out configuration issues with the external packages and give quicker feedback than acceptances tests 
• Test inter-dependencies with other subsystems, including other project and third party libraries, tools, etc.

Component test

• Similar to unit test but for an association of class instances
• Test a specific context of the application

Unit 

• The most granular level, usually test a single class instance 
• Do our objects do the right thing, are they convenient to work with? 
• Should run fast and frequently. Can be executed during the build. 
• Provides a sort of living documentation of the system 
• Find problems early 
• Should be independent from each other