Software Testing Terminology List: 60 Basic Terms and Definitions

If you are starting your software testing journey, learning the right terminology is one of the smartest first steps. In interviews, recruiters often test your fundamentals before they ask about tools or project experience. This glossary gives you clear and practical definitions of the most commonly asked testing terms, so you can understand concepts properly and explain them with confidence.

These essential software testing terms have been written in simple, practical language. It is useful for interview preparation and for building a strong testing foundation.

1. Software Testing

Software testing is the process of checking whether an application works as expected under different conditions. It helps identify defects before users face them in production. Good testing improves product quality, user trust, and release confidence.

2. Quality Assurance (QA)

QA focuses on improving the process used to build software so defects can be prevented early. It is process-oriented and proactive in nature. QA ensures quality is planned from the beginning, not inspected only at the end.

3. Quality Control (QC)

QC focuses on evaluating the actual product to detect defects. It includes activities like test execution, review, and inspection. While QA prevents defects, QC helps find and fix them before release.

4. Verification

Verification checks whether development work products follow specifications and standards correctly. It is usually done through reviews, walkthroughs, and inspections. It answers: “Are we building the product correctly?”

5. Validation

Validation checks whether the final product meets user and business needs. It is often done through functional testing and UAT. It answers: “Are we building the right product?”

6. SDLC (Software Development Life Cycle)

SDLC is the complete software lifecycle from planning to maintenance. It includes requirement gathering, design, coding, testing, deployment, and support. Testing is one important phase within SDLC.

7. STLC (Software Testing Life Cycle)

STLC is the testing-specific lifecycle followed by QA teams. It includes requirement analysis, planning, test design, environment setup, execution, and closure. It ensures testing happens in a structured and measurable way.

8. Requirement Analysis

Requirement analysis is the phase where testers study requirements to understand what should be tested. It helps identify gaps, ambiguities, and dependencies early. Strong analysis reduces rework during execution.

9. Test Plan

A test plan is a formal document that defines testing scope, approach, schedule, resources, and risks. It provides a roadmap for the QA team. A clear plan keeps testing focused and predictable.

10. Test Strategy

Test strategy is a high-level testing approach that defines standards, methods, and quality goals. It is broader than a test plan and often applies across releases. It ensures consistency in testing practices.

11. Test Scenario

A test scenario is a high-level statement of what functionality should be tested. It describes coverage areas without detailed steps. Scenarios help ensure broad feature-level test completeness.

12. Test Case

A test case is a detailed document with preconditions, steps, test data, and expected results. It is used to verify one specific behavior. Well-written cases improve execution consistency and traceability.

13. Test Data

Test data is the input used while executing test cases. It should include valid, invalid, boundary, and role-specific values. Good test data quality directly improves defect detection quality.

14. Expected Result

Expected result is the intended output according to requirements or business rules. It acts as a reference for pass/fail decisions. Clear expected results reduce tester interpretation errors.

15. Actual Result

Actual result is the real system behavior observed during test execution. It is compared with expected behavior to identify defects. Any mismatch should be logged and tracked.

16. Defect / Bug

A defect (or bug) is a deviation between expected and actual behavior. It may occur due to coding, design, requirement, or integration issues. Defects are logged, prioritized, fixed, and retested.

17. Defect Life Cycle

Defect life cycle is the path a defect follows from discovery to closure. Common stages include New, Assigned, Fixed, Retest, and Closed. It helps teams track bug progress and accountability.

18. Severity

Severity indicates how badly a defect affects system functionality. It is a technical impact measure. For example, system crash defects are usually high severity.

19. Priority

Priority indicates how urgently a defect should be fixed from business perspective. A low-severity issue can still be high-priority if it affects release/demo. Priority helps decide fix order.

20. Retesting

Retesting means executing a previously failed test again after bug fix. It confirms whether that specific defect is resolved. It is focused and defect-specific.

21. Regression Testing

Regression testing checks whether new code changes broke existing working functionality. It is critical in frequent release cycles. Strong regression reduces production surprises.

22. Smoke Testing

Smoke testing is a quick broad check of core functionalities after a new build. It confirms if build is stable enough for detailed testing. It saves time by identifying major blockers early.

23. Sanity Testing

Sanity testing is focused testing after a minor fix or small change. It verifies the changed area and nearby impact quickly. It is narrow in scope but deeper than smoke in that specific area.

24. Exploratory Testing

Exploratory testing is unscripted, where learning, design, and execution happen together. It relies on tester experience and critical thinking. It is excellent for finding hidden and edge-case defects.

25. Ad-hoc Testing

Ad-hoc testing is informal testing without prewritten test cases. It is useful for quick checks and fast defect discovery. However, it should support, not replace, systematic testing.

26. Positive Testing

Positive testing validates behavior using valid inputs and expected user actions. It confirms normal workflow success. It is essential for baseline functionality confidence.

27. Negative Testing

Negative testing validates behavior using invalid input or unexpected actions. It checks validation logic and error handling quality. It improves product robustness and stability.

28. Black-box Testing

Black-box testing validates application behavior without checking internal code. Tester focuses on requirement-based input/output behavior. Most manual functional testing uses this method.

29. White-box Testing

White-box testing validates internal code structure, logic, and execution paths. It is typically done by developers or automation engineers. It helps detect logic-level defects not visible from UI.

30. Gray-box Testing

Gray-box testing combines black-box behavior testing with partial internal knowledge like APIs or DB schema. It enables stronger integration and data flow validations. This approach is common in modern agile teams.

31. Boundary Value Analysis (BVA)

BVA is a test design technique focused on edge values where defects frequently occur. For a 1–100 range, tests include 0,1,2 and 99,100,101. It gives high defect detection with fewer cases.

32. Equivalence Partitioning

This technique divides input data into groups expected to behave similarly. One representative value from each group is tested instead of every value. It reduces effort while maintaining coverage quality.

33. Decision Table Testing

Decision table testing is used when outcomes depend on combinations of rules. A table maps condition combinations to expected actions. It prevents missing important logic combinations.

34. State Transition Testing

This method tests behavior when a system moves between different states. It checks allowed and blocked transitions and expected outputs in each state. Useful for workflows like account lock, order status, or subscription lifecycle.

35. Use Case Testing

Use case testing validates complete user goals from start to finish. It focuses on business process success, not isolated fields. It helps ensure the product supports real user tasks.

36. Integration Testing

Integration testing verifies interactions between modules, services, or systems. It identifies interface, contract, and data flow defects. It is critical in API-driven and microservice applications.

37. System Testing

System testing validates the complete integrated application against requirements. It is done in a production-like environment. It ensures modules work together correctly as one system.

38. End-to-End (E2E) Testing

E2E testing validates full business workflows across connected systems. Example: login to checkout to payment to confirmation. It confirms real-world user journey reliability.

39. UAT (User Acceptance Testing)

UAT is performed by business users or clients to confirm software meets business needs. It is typically the last major validation before go-live. Successful UAT indicates practical business readiness.

40. Test Environment

A test environment is the setup used for testing, including app build, database, integrations, and configurations. Stable environments improve test reliability. Environment issues often cause delays and false failures.

41. Build

A build is a packaged version of application code provided for testing. New builds may include fixes, features, or configuration updates. Smoke testing is usually done first on each build.

42. Entry Criteria

Entry criteria are conditions that must be satisfied before testing begins. Examples are approved requirements and stable build availability. They ensure testing starts on a reliable baseline.

43. Exit Criteria

Exit criteria are conditions required to close testing phase. Examples include critical defects resolved and target pass rate achieved. They support objective release recommendations.

44. RTM (Requirement Traceability Matrix)

RTM maps requirements to test cases and often linked defects. It ensures every requirement is tested and traceable. RTM is highly useful in audits and impact analysis.

45. Test Coverage

Test coverage shows how much of the requirement or feature scope is tested. Higher meaningful coverage usually lowers release risk. Coverage should focus on quality, not only quantity.

46. Test Execution

Test execution is the phase where test cases are run and outcomes are recorded. It includes pass/fail status, defect logging, and evidence capture. Execution quality directly affects defect quality.

47. Test Summary Report

This is a closure document summarizing tested scope, results, defect status, and quality risks. It helps stakeholders understand release readiness. A clear summary supports informed Go/No-Go decisions.

48. Blocker Defect

A blocker defect prevents further testing or major business flow execution. It requires immediate resolution to continue progress. Example: application crash on login.

49. Critical Defect

A critical defect causes severe functional failure with high business impact. It can affect key user journeys and release decisions. Such defects are treated as top priority in most projects.

50. Defect Leakage

Defect leakage means bugs missed in testing but found in production. It reflects test effectiveness and risk control quality. Reducing leakage is a key QA improvement goal.

51. Defect Reopen

A reopened defect is one marked fixed but failing again during retest. Frequent reopen cases indicate weak fix quality or unclear defect understanding. Reopen rate is an important QA metric.

52. Root Cause Analysis (RCA)

RCA is the process of finding the underlying reason behind a defect. It helps teams fix process gaps, not just symptoms. Good RCA reduces repeated failures over time.

53. Compatibility Testing

Compatibility testing validates software behavior across different devices, OS versions, resolutions, and networks. It ensures consistent user experience. This is especially important for web and mobile applications.

54. Cross-browser Testing

Cross-browser testing verifies that a web app works correctly on multiple browsers. Different rendering engines can cause UI and script differences. This testing prevents browser-specific production issues.

55. Usability Testing

Usability testing checks how easy and intuitive the product is for users. It reviews navigation clarity, workflow simplicity, and user effort. Better usability improves adoption and satisfaction.

56. Accessibility Testing

Accessibility testing ensures users with disabilities can access and use the application. It includes keyboard navigation, screen-reader labels, and contrast checks. It improves inclusiveness and often supports compliance.

57. API Testing

API testing validates backend service behavior, request/response structure, authentication, and business rules. It catches major issues before they appear in UI. API-level checks are essential in modern systems.

58. Performance Testing (Basic Idea)

Performance testing checks speed, response time, and stability under expected or high load. It identifies bottlenecks in code, database, or infrastructure. Good performance testing protects user experience at scale.

59. Security Testing (Basic Idea)

Security testing checks vulnerabilities such as weak authentication, access control flaws, and data exposure risks. It helps protect user privacy and business data. Even basic security checks can prevent major incidents.

60. Test Closure

Test closure is the final stage where execution is completed and results are documented. It includes summary reporting, lessons learned, and sign-off recommendations. Proper closure improves future release planning.

Conclusion

Strong fundamentals always create long-term success in QA careers. Once you clearly understand these basic terms, it becomes much easier to design better test cases, report defects effectively, and contribute meaningfully in real projects. Keep this list as your quick revision guide, and you will notice steady improvement in both interview performance and day-to-day testing quality.