Regression Testing

• designed to establish whether or not a modification will introduce changes elsewhere    
• consists of repeating test runs to check if program activities are altered and if any fixed errors are re-surfacing
• tester chooses the applicable number of test sets necessary to comprehensively investigate a system after a specific change

Reliability Testing

• examines unexpected failure effects (software or hardware) during challenging execution steps (disk failure, database crash or memory failure)
• demonstrates system coherency under stressful situations
• referred to as "destructive testing"

Scenario Based Testing

• objective is to finish the scenario and ensure testing detours re-route to the script documented main user path
• explores alternative inputs or potential side effects not found in the script

Scope Creep

• project expansion beyond planned objectives
• causes a project to be never-ending because expectations keep changing
• often because of poor communication     
• lacks clearly defined and documented end point
• actions must be controlled to regulate project embellishment
• may result in deadline delays and budget shortages
• primary source of project failure when handled inappropriately

Smoke Test

• goal is to expose simple failures serious enough to threaten an upcoming software release  
• additional testing executed only if the test is successful
• if the test fails, then the build is excluded and testing ceases

Strategy Based Testing

• freestyle investigation directed by identified bug-finding methods
• uses written techniques and unwritten characteristics to conduct testing effort

Stress Testing

• emphasizes software robustness, availability, and error handling under atypical heavy loads
• validates application performance beyond peak load conditions
• tests outside of normal operation boundaries
• significant for "mission critical" software
• used for all software varieties

Targeted Infrastructure Testing

• individual layer and/or fragment test in an end to end application configuration

Technical Debt

• result of chaotically designed and disorganized systems
• suggests compromises teams make to a system’s maintainability and adaptability in order to meet release dates
• makes simple changes extremely difficult to implement
• often causes costs to rise and customer satisfaction to diminish
• frequently produces future changes that are expensive and risky

Usability Testing

• testing the human factors of the system
• ability of the user to interface with the system