A set of actions or steps designed to verify if a specific feature or functionality in an application works as expected. Each test case typically includes inputs, conditions, and expected results. Think of it as a “recipe” for checking functionality.
2. Test Plan
This is your blueprint for testing. It outlines the scope, approach, resources, and schedule of intended test activities. Essentially, it’s a roadmap of how you’ll perform testing on a product or feature.
3. Test Suite
A collection of test cases grouped together for easy execution. These test cases usually target a specific feature or module of the application.
4. Bug/Defect
An error, flaw, or fault in the software that causes it to produce incorrect or unexpected results. Bugs are the main reason QA exists — to catch and fix these issues before users encounter them.
5. Regression Testing
This ensures that recent changes or new build of additions haven’t broken any existing functionality. It’s like re-checking your work to make sure everything still functions properly after updates on project.
6. Smoke Testing
A high-level, quick set of tests to ensure the basic functionalities of an application are working. It’s often referred to as a “sanity check,” testing the waters before deeper testing.
7. Sanity Testing
Performed after receiving a build to verify if specific functionality or bug fixes are working. Unlike smoke testing, which checks basic features, sanity testing focuses on small areas of concern.
8. User Acceptance Testing (UAT)
The final testing phase before the software application is released to the live production. Here, real-world users verify whether the software meets their needs and expectations.
9. Test-Driven Development (TDD)
A development methodology where test cases are written before the actual code. Developers write a test, ensure it fails (since the code doesn’t exist yet), and then write the code to make the test pass.
