QA & Software Testing Top 50 Q&A

Verification is checking if the product is built according to specs (Are we building the product right?). Validation is checking if the product meets user needs (Are we building the right product?).

A sequence of specific activities conducted during the testing process: Requirement Analysis -> Test Planning -> Test Case Development -> Test Environment Setup -> Test Execution -> Test Closure.

QA is process-oriented (preventing defects). QC is product-oriented (identifying defects).

A set of conditions or variables under which a tester determines whether a system under test satisfies requirements.

A document describing the scope, approach, resources, and schedule of intended testing activities.

White Box: Testing based on internal structure/code knowledge. Black Box: Testing based on requirements/functionality without code knowledge.

Testing individual components or modules of the software, usually done by developers.

Testing how different modules or services work together.

Testing the complete and integrated software as a whole to evaluate its compliance with specified requirements.

Rerunning functional and non-functional tests to ensure that previously developed and tested software still performs after a change.

Using software tools to execute tests automatically. Best for repetitive tasks, regression testing, and large-scale data testing.

A popular tool for automating web browsers. Components: Selenium IDE, Selenium WebDriver, and Selenium Grid.

A design pattern that creates an object repository for web elements, making the code more readable and maintainable.

Implicit wait tells the driver to wait for a certain amount of time for all elements. Explicit wait tells the driver to wait for a specific condition on a specific element.

A modern, fast automation framework by Microsoft that supports cross-browser testing and has built-in auto-waiting and tracing.

BDD is a process where teams write tests in plain English (Gherkin). Cucumber is a tool that executes these tests.

A set of guidelines and tools used to design and develop test cases efficiently (e.g., Data-driven, Keyword-driven, Hybrid).

By using partial attributes (contains, starts-with), relative XPaths, or using unique parent elements.

Integrating automated tests into the build pipeline so that every code change is automatically tested before deployment.

An open-source tool for automating mobile applications (iOS, Android).

Testing the application programming interfaces directly to ensure they meet expectations for functionality, reliability, performance, and security.

200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorized), 404 (Not Found), 500 (Internal Server Error).

GET retrieves data from a server. POST sends data to a server to create/update a resource.

A popular API platform for developers and testers to design, build, and test APIs.

Testing the speed, scalability, and stability of an application under various workloads.

Load testing checks performance under expected load. Stress testing checks performance under extreme load to find the breaking point.

An open-source tool used for load and performance testing of web applications.

Testing to identify vulnerabilities and ensure that data and resources are protected from unauthorized access.

A testing technique where test cases are designed at the boundaries of the input domain (e.g., if a field takes 1-100, test 0, 1, 100, 101).

Dividing input data into classes that are expected to behave similarly, and testing one value from each class.

A deviation from the expected behavior of the software.

New -> Assigned -> Open -> Fixed -> Pending Retest -> Retest -> Reopen/Closed.

Severity is the technical impact of the bug (e.g., system crash). Priority is the business urgency of fixing the bug.

Title, Description, Steps to Reproduce, Expected Result, Actual Result, Severity, Priority, Environment, and Screenshots/Logs.

When a bug is missed by the testing team and found by the end-user in production.

Releasing the software with known non-critical bugs, usually due to time constraints, documented in the release notes.

An informal type of testing where the tester "explores" the app without pre-defined test cases to find defects.

Testing done without any planning or documentation, usually after formal testing is complete.

A subset of regression testing that checks if a specific part of the app is working after a bug fix.

A quick set of tests to ensure the most critical functions of the build are working (e.g., can the user login?).

Check positive cases (valid credentials), negative cases (wrong pwd, empty fields), security (SQL injection), and UI (responsiveness).

I refer back to the requirement documentation and discuss it with the Product Owner for clarification.

By following testing blogs (Ministry of Testing), attending webinars, and learning new AI tools for testing.

AI for generating test cases, self-healing automation scripts, visual testing, and predicting bug hotspots in the code.

The practice of starting testing as early as possible in the development lifecycle to find bugs earlier and cheaper.

Testing that happens in production (e.g., A/B testing, monitoring, canary deployments) to gather real-world data.

Mention your passion for quality, your specific testing skills, and your interest in their product's reliability.

Choose one (e.g., Selenium, Postman, Jira) and explain how it helps you deliver quality software.

By prioritizing risk-based testing (testing critical paths first) and communicating any potential risks to stakeholders.

Ask about their automation strategy, the dev-to-QA ratio, or the biggest quality challenge they face.