Easy Software Testing Interview Questions

Verification: are we building the product right? (reviews, walkthroughs — no code run). Validation: are we building the right product? (actual testing against user needs).

A language to query databases. Testers use it to verify data saved by the application, prepare test data and check backend results.

Smoke testing checks that the critical features of a new build work (broad and shallow). Sanity testing checks that a specific fix or area works after a change (narrow and deep).

For a field accepting 1–100: valid class 1–100 (test 50), invalid below 1 (test −5), invalid above 100 (test 150). One value represents each class.

Alpha is done in-house by internal teams before release; beta is done by a limited group of real users in their own environment.

Testing that is continuous and collaborative within each sprint, with testers working alongside developers and product owners from the start.

Evaluating software to find defects and confirm it meets requirements. It reduces risk, protects users and saves the cost of fixing bugs after release.

A scenario is a high-level thing to test (user logs in); test cases are the detailed steps and data that verify it.

A document defining scope, approach, resources, schedule, entry and exit criteria, risks and deliverables of testing.

SDLC is the full software development life cycle; STLC is the testing life cycle: requirement analysis, test planning, test design, environment setup, execution and closure.

New → Assigned → Open → Fixed → Retest → Verified → Closed, with Reopened, Rejected, Deferred and Duplicate as side paths.

Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).

A set of steps with inputs and expected results. Components: ID, title, preconditions, steps, test data, expected result, actual result and status.

Valid login, invalid login, forgot password, locked account and session handling are the main scenarios to cover.

Unit, integration, system and acceptance testing, moving from individual components to the complete product in front of users.

User Acceptance Testing — end users or the client verify that the system meets business needs in a production-like environment before go-live.

Test 17, 18, 19, 59, 60 and 61.

Moves to the chosen floor, doors open and close, door sensor stops closing on obstruction, overload alarm, emergency button, behaviour in a power cut, max capacity and the floor display.

Valid login, wrong password, empty fields, case sensitivity, max length, SQL-injection strings, password masking, 'remember me', lock-out after N attempts and the forgot-password link.

The hardware, software, data and configuration where testing happens, set up to mirror production as closely as practical.

Severity = impact on the system. Priority = urgency to fix. Logo misspelt on the homepage → low severity, high priority. Crash in a rarely used report → high severity, low priority.

Black box tests behaviour without code knowledge; white box tests internal logic and paths; grey box uses partial knowledge of the internals.

A human error causes a defect in the code, and when that defect is executed it produces a failure visible to users.

A final document summarising what was tested, defects found and open, metrics, lessons learned and the recommendation for release.

A clear title, steps to reproduce, expected vs actual result, environment/build, severity and priority, and evidence (screenshot, video, logs).

Quality assurance is process-oriented and preventive: it sets standards, reviews and checklists so defects are not introduced in the first place. Quality control is product-oriented and detective: it checks the actual build through testing and inspection to find defects. For example, introducing a requirement review checklist is QA, while executing test cases on a release build is QC. Software testing is one activity inside quality control.

Exhaustive testing means trying every possible input, path and combination, which is practically infinite for real software. Even a single text field accepting 20 characters has more combinations than you could ever run. So testers use risk and techniques like equivalence partitioning and boundary value analysis to select a small set of tests that give high confidence. The goal is enough coverage of important risks, not every possible case.

A manual tester understands requirements, writes test scenarios and test cases, prepares test data, executes tests on each build, logs clear bug reports and retests fixes. They also do exploratory testing, join stand-ups and reviews, and give a quality status before release. Beyond finding bugs, a good manual tester represents the end user and raises usability or requirement gaps early, when they are cheap to fix.

Model answer: To me quality means the product does what users need, reliably, and is easy to use, not just that test cases pass. In my final-year project I tested a library app; all features worked, but students struggled to find the search option. I reported it as a usability issue and the team moved search to the home screen. That taught me to test from the user's point of view as well.

A build is a compiled version of the software created from the latest code, often many times a day, and given to QA for testing. A release is a tested, approved version delivered to customers or production, usually with release notes and a version number. Many builds can go through testing before one of them is promoted as a release. Testers always note the build number in bug reports.

Waterfall is a sequential model: requirements, design, development, testing and deployment happen one after another. Testing starts only after development is complete, so defects in requirements or design are found late and are costly to fix. It suits small projects with stable, well-defined requirements. Its weakness for testers is the late feedback, which is why most teams now use Agile or the V-model.

Manual testing is better for exploratory testing, usability and look-and-feel checks, features that change often, one-time tests and early testing of new functionality. Automation pays off for stable, repetitive tests such as regression suites, data-driven checks and smoke tests run on every build. Most teams combine both: manual for discovery and judgement, automation for speed and repeatability.

Login is a blocker because no other testing can proceed. Confirm it quickly: retry with valid test accounts, check another browser and confirm the right environment and build number. Then log a blocker bug with steps, screenshot and console or network errors, inform the developer and lead immediately, and mark the build as rejected in smoke testing. Meanwhile, prepare test data or review test cases until a fixed build arrives.

Model answer: I enjoy finding how things break and thinking like a user. During my internship I tested a college fee portal and found that a refund was shown twice on the receipt, which the team fixed before launch. Manual testing gives me a strong base in requirements, test design and bug reporting. I plan to add SQL, API and automation skills on top of it as I grow.

The test basis is the set of documents and knowledge from which test cases are derived. It includes requirement specifications, user stories with acceptance criteria, design documents, wireframes, API contracts, business rules and even existing system behaviour. A good test basis lets you trace each test case back to a requirement. If the test basis is weak or missing, testers must clarify it before or while testing.

A high-level test case states what to test without detailed steps or exact data, for example 'Verify user can reset password using registered email'. A low-level test case gives exact steps, test data and expected results for each step. High-level cases are quick to write and suit experienced testers or changing features. Low-level cases suit regulated projects, new team members and cases that will later be automated.

Verify reset with a registered email sends a link. Verify an unregistered email shows a generic message without revealing whether the account exists. Check the link opens the reset page and expires after the defined time. Check the link works only once. Validate new password rules and that confirm password must match. Verify login works with the new password and fails with the old one. Check resend limits and that other sessions are logged out.

Verify a valid date is accepted and saved in the right format. Check the minimum age rule, such as 18 years, using boundary dates of exactly 18 today and one day short. Reject future dates and impossible dates like 30 February. Test leap year dates like 29 February 2004. Check manual typing and the picker give the same result, the field is mandatory if required, and the date displays correctly after saving.

First ask what type of pen and who the users are. Functional: it writes smoothly, ink flows without leaking, the cap or click mechanism works and the ink colour matches the label. Non-functional: comfort of grip, writing length before ink runs out, performance at different temperatures and on different paper. Negative: dropping it, pressing hard, leaving it uncapped. Safety: the cap is non-toxic and has an air hole. This shows structured thinking, not just a list.

A test condition is an item or event of the system that can be verified by one or more test cases, derived from the test basis. For example, for a login requirement, conditions include valid login, wrong password, locked account and remember me. Test conditions answer what to test, while test cases describe how to test it with steps, data and expected results. Listing conditions first helps check coverage before writing detailed cases.

Model answer: Situation: in my training project, a registration form had age, state and course fields, and my first draft had over 60 test cases. Task: cut effort without losing coverage. Action: I applied equivalence partitioning and boundary values to age and pairwise combinations for state and course. Result: I covered the same rules with 18 cases, my mentor approved them, and execution finished in half the time.

A deferred bug is valid, but the team decides to fix it in a later release because of low priority, time limits or low impact. It stays in the backlog with a target version. A rejected bug is one the developer or triage team considers invalid: working as designed, not reproducible, a duplicate or caused by wrong test data. Testers should check the reason for rejection and challenge it with evidence if they disagree.

A duplicate bug is a new report for a problem that is already logged. Before raising a bug, search the tracker by key words, module, error message and recent open bugs, and ask teammates working on the same area. If a similar bug exists, add your extra information, such as another browser or data set, as a comment instead of a new ticket. This keeps the backlog clean and saves triage time.

Save filters for common views such as my open bugs, bugs ready for retest, blockers in the current sprint and bugs by fix version. Add them to a dashboard with gadgets like pie charts by priority, created versus resolved trend and a sprint bug list. Share the dashboard with the team so status is visible without manual reports. Testers start their day from the ready-for-retest filter.

Components are fixed sub-parts of a project, such as Payments or Login, often with a default owner. Labels are free-text tags, such as regression or ui, that anyone can add for grouping. Fix version is the release in which the issue is planned to be fixed, while affects version is where the bug was found. Testers use these fields to filter bugs and to build release-wise reports.

First confirm you are testing the right build, which contains the fix, and clear the cache. Repeat the exact steps and data from the bug. If it still fails, reopen the bug with a comment stating the build number, what you did and the actual result, with a fresh screenshot or video. Talk to the developer directly if the steps differ from what they tested, so the fix is not tested on a different scenario.

A user story describes a feature from the user's view, usually as: As a role, I want a goal, so that a benefit. Acceptance criteria are the specific conditions the story must meet to be accepted, often written as Given, When, Then. For example, given a registered user, when they enter a wrong password three times, then the account is locked for 15 minutes. Testers use acceptance criteria as the base for test cases.

Model answer: Situation: in my first project, testers had to verify orders in the database, and I knew only basic SELECT. Task: become useful within a week. Action: I practised joins on a copy of the test database every evening and asked a senior to review my queries. Result: by the second sprint I was validating order data on my own and caught a missing tax column bug.

Scrum works in fixed sprints with planned scope, roles and ceremonies, so the tester plans testing for the sprint and aims to finish all stories by the sprint end. Kanban is a continuous flow with work-in-progress limits and no fixed sprints, so testing happens as each item reaches the test column. In Kanban, a tester watches that the testing column does not become a bottleneck and raises it when limits are hit.

PUT replaces the whole resource with the data sent, so fields you leave out may be cleared or reset. PATCH applies a partial update and changes only the fields sent. For example, to change only a user's phone number, PATCH with just the phone field is enough, while PUT expects the complete user object. Testers check that PUT and PATCH behave as documented and that missing fields are handled correctly.

401 Unauthorized means the request has no valid authentication, such as a missing, expired or wrong token, so the client should log in again. 403 Forbidden means the user is authenticated but does not have permission for that resource, such as a normal user calling an admin API. Testers verify both: call without a token to expect 401, and call with a low-privilege token to expect 403.

Path parameters identify a specific resource and are part of the URL, as in /users/42. Query parameters filter, sort or paginate and come after a question mark, as in /users?city=Pune&page=2. The request body carries data for creating or updating, usually JSON, in POST, PUT or PATCH. Testers check invalid values in each: a wrong ID in the path, unknown query parameters and missing body fields.

Retesting, or confirmation testing, checks that a specific bug that was fixed now works, using the same steps as the original bug. Regression testing checks that the fix or a new change has not broken other, previously working features. Retesting is planned for failed cases only, while regression covers a wider set of passing cases. Retesting usually comes first, then regression around the changed area.

Ad hoc testing is informal testing without test cases, done by a tester who understands the application and tries likely weak areas based on experience. Monkey testing gives random inputs and actions, often without knowing the application, to see if it crashes. Ad hoc testing is targeted and good at finding logical bugs, while monkey testing is good at finding stability issues and is often automated.

End-to-end testing checks a complete business flow from the user's first action to the final result, across all connected parts: UI, APIs, database, third-party services and notifications. For example, in online shopping: search a product, add to cart, pay, receive the confirmation email and see the order in the account. It finds integration issues that module-level testing misses, but it is slower and needs stable environments.

Integration testing checks that modules or services work correctly together, focusing on interfaces and data flow. Approaches: big bang, where all modules are combined at once and testing is simple to plan but defects are hard to locate; top-down, where high-level modules are tested first using stubs for lower ones; bottom-up, using drivers for higher ones; and sandwich, which mixes both. Incremental approaches make it easier to find which interface failed.

System testing tests the complete, integrated application against the requirements in an environment close to production. It is done by the testing team after integration testing and before UAT. It covers functional testing of all features plus non-functional aspects such as performance, security, usability and compatibility. It is black box testing, so the tester checks behaviour from the user's point of view without looking at the code.

Model answer: I follow testing communities and blogs, practise on public demo sites and read release notes of the tools I use. Last month I learned API schema validation from an online course and tried it on a practice API. I also share one new idea in our team chat each week. This keeps me improving and helps the team pick up useful practices without waiting for formal training.

Check alignment, spacing, fonts, colours and images against the design. Verify text is not cut off or overlapping, buttons and links look clickable and show hover and disabled states, and error messages appear in the right place. Check responsive behaviour on different screen widths and zoom levels. Confirm icons and images load and have alt text. Compare with the design file and take screenshots for any differences.

In requirement analysis, the testing team studies the requirements to understand what needs to be tested. They identify testable requirements, clarify doubts with the business analyst or client, decide test types needed, note automation candidates and look at environment needs. The outputs are a list of questions, a requirement traceability matrix draft and an automation feasibility note. Problems found here are the cheapest to fix.

Include the date, build or release, and planned versus executed test cases with pass, fail, blocked and not run counts. List new bugs by severity, open critical bugs with owners, retests done and any blockers such as environment downtime or missing data. Add a short note on risk and the plan for the next day. Keep it to one page so managers can read it in two minutes.

Test deliverables are the documents and artefacts produced during testing and shared with stakeholders. Before testing: test plan, test strategy and estimates. During testing: test scenarios, test cases, test data, traceability matrix, execution logs and bug reports. After testing: test summary report, closure report, metrics and lessons learned. The test plan should list which deliverables are expected so nothing is missed at sign-off.

Re-run the test once to confirm the failure and rule out wrong data or environment issues. Capture evidence such as screenshots, logs and the build number. Check for an existing bug, then log a new one with clear steps and link it to the test case. Mark the test as failed, and mark dependent tests as blocked if they cannot run. After the fix, retest and run related regression.

Execution progress = test cases executed divided by total planned test cases, multiplied by 100. Pass rate = test cases passed divided by test cases executed, multiplied by 100. For example, if 200 cases are planned, 150 are executed and 120 passed, progress is 75 percent and pass rate is 80 percent. Report blocked cases separately because they are neither passed nor failed.

Native apps are built for one platform and use device features fully, so testing focuses on OS versions, device features, install and update. Hybrid apps wrap web code in a native shell, so you test both the web view rendering and the native bridges like camera access. Mobile web apps run in a browser, so testing is closer to cross-browser and responsive testing. All three need network, screen size and performance checks.

An emulator imitates both the hardware and software of a device, as with the Android emulator, so it behaves close to a real phone. A simulator imitates only the software environment, as with the iOS simulator, and does not reproduce the hardware. Both are free and fast for early testing. Real devices are needed for camera, battery, sensors, actual performance, network behaviour and final sign-off.

Interrupt testing checks how the app behaves when something interrupts it: an incoming call, SMS, notification, alarm, low battery warning, network change, plugging in a charger or switching to another app. The app should pause correctly, keep the user's data and resume where the user left off. For example, a call during a payment must not cause a double charge or lose the transaction state.

Mobile users have many screen sizes, resolutions, notches and foldable screens, and they rotate their phones. Rotation can recreate the screen and lose entered data if not handled. Test portrait and landscape on key screens, small and large phones and tablets, and check text does not cut off, buttons stay reachable and the keyboard does not hide input fields. Check entered form data survives rotation.

Install a fresh build and verify first-launch screens and permissions. Test install with low storage. Update from the previous production version and check that login, settings, saved data and offline content are kept and migrations work. Test a forced update prompt if the app has one. Uninstall and reinstall, and confirm local data is cleared while server data returns after login. Check the app size is reasonable.

Model answer: Most users in India now use services first on their phones, so mobile quality directly affects customers. In my project I tested a college event app on four phones and found that the registration button was hidden by the keyboard on small screens. Fixing it raised sign-ups. I enjoy the variety of devices, networks and real-life situations that mobile testing involves.

Switch the device to dark mode and check every screen: text must remain readable, icons and images visible, and no white flashes during navigation. Switch back while the app is open. Then increase the system font size to the largest setting and confirm text does not overlap or get cut off and buttons remain usable. Also test display size or zoom settings and both orientations.

Response time is the total time from sending a request to receiving the complete response, as the user experiences it. Latency is the delay before the first byte of the response arrives, mostly network and waiting time. Throughput is how many requests or transactions the system handles per unit of time, such as 500 requests per second. Good performance usually means low response time at the required throughput.

Think time is the pause a real user takes between actions, such as reading a product page before adding it to the cart. Performance scripts add think time, often with random variation, so virtual users behave realistically. Without think time, a few virtual users generate a load equal to many real users, which gives misleading results. Think time values are usually taken from analytics or production logs.

Open developer tools and use the network tab with cache disabled to see each request's size and time, and the total load time. Look for very large images or scripts, slow API calls and requests that fail or repeat. Use throttling to simulate slow 3G or 4G. Run the built-in performance audit tool to get scores for load speed and suggestions. Record the numbers so you can compare with later builds.

Authentication checks who you are, for example by password, OTP or biometrics. Authorization checks what you are allowed to do after you are identified, such as whether you can view reports or delete users. Authentication comes first. Testers check authentication with wrong credentials and expired sessions, and authorization by trying actions with a lower-privilege account or by calling restricted URLs and APIs directly.

Check every page and API uses HTTPS, and plain HTTP redirects to HTTPS. Verify the certificate is valid, not expired, and matches the domain, with no browser warnings. Look for mixed content, where an HTTPS page loads scripts or images over HTTP. Check login and payment forms submit only over HTTPS and that cookies holding session data have the Secure flag.

Try passwords that break each rule: too short, no digit, no special character and common passwords, and check clear messages. Verify the password is masked and not shown in the URL or logs. Enter the wrong password up to the limit and confirm the account locks for the defined time or until reset. Check that the error message does not reveal whether the username exists and that the lockout counter resets after a successful login.

Client-side validation improves user experience by giving quick feedback, but anyone can bypass it by disabling JavaScript or sending requests directly with tools like Postman. The server must validate every input again for type, length, format and business rules. Testers check this by sending invalid data straight to the API, such as a negative quantity or a very long name, and confirming the server rejects it.

Database testing checks that the data an application stores and reads is correct, complete and safe. It covers schema checks (tables, columns, data types), constraints and keys, data integrity after create, update and delete actions, stored procedures, triggers and views, transactions, and basic performance of heavy queries. For example, after placing an order in the UI, a tester queries the orders and order_items tables to confirm every value was saved exactly as entered.

UI testing checks what the user sees and does: screens, buttons, messages and flows. Database testing checks what happens underneath: whether the right rows are inserted, updated or deleted, whether constraints hold and whether data stays consistent across tables. A screen can show a success message while the database saved a wrong amount or nothing at all. So testers combine both, using SQL to confirm that every important UI action leaves the database in the expected state.

A view is a saved query that behaves like a virtual table, often used for reports or to hide sensitive columns. When testing it, compare its output with the same query run on the base tables, check filters and joins return the right rows, confirm hidden columns such as salary are really absent, check behaviour when base data changes and verify that users without permission on the base tables can still read the view if intended.

Data masking replaces real sensitive values with realistic but fake ones, for example changing real phone numbers to valid-looking dummy numbers and real names to generated names. It lets teams test with production-like data volume and patterns without exposing customer information. It also supports compliance with India's Digital Personal Data Protection Act. Testers should check that masked data still passes validation rules and keeps relationships between tables intact.

1. Correct current password and valid new password: success, old password stops working. 2. Wrong current password: error, no change. 3. New password same as current: rejected if policy says so. 4. New and confirm fields do not match: error. 5. New password below minimum or above maximum length: error. 6. Missing digit or special character: policy message. 7. Other active sessions are logged out. 8. Confirmation email or alert is sent. 9. Password fields are masked.

Focus on impact, not internals. Say who is affected, what they cannot do, how often it happens and what it may cost, for example: 'About one in twenty users paying by UPI see a failure message even though money is debited, which will raise refund complaints.' Then give the options and a recommendation. Avoid jargon like null pointer or race condition unless asked. A short screen recording often helps.

WCAG, the Web Content Accessibility Guidelines from the W3C, is the main standard for making web content usable by people with disabilities. The current version is WCAG 2.2. It has three conformance levels: A is the minimum, AA is the usual legal and contract target, and AAA is the highest and rarely required for a whole site. Each level adds success criteria, such as colour contrast at AA.

POUR is the four principles behind WCAG. Perceivable: users can see or hear the content, for example images have alt text and videos have captions. Operable: everything works with a keyboard and users have enough time. Understandable: text is clear and forms explain errors. Robust: content works with assistive technologies such as screen readers. Every WCAG success criterion sits under one of these four principles.

Accessibility testing checks that people with disabilities can use the product, often against WCAG criteria, using keyboards, screen readers, zoom and contrast tools. Usability testing checks how easily typical users complete tasks, by watching real users and measuring success, time and errors. They overlap, since clear labels help everyone, but a page can pass WCAG and still be confusing, or be easy for most users yet unusable with a screen reader.

Put the mouse away. Press Tab and Shift+Tab to move through every link, button and field, and check that the order is logical and the focus outline is always visible. Use Enter and Space to activate buttons and links, arrow keys for menus, radio groups and sliders, and Escape to close dialogs. Check that nothing traps focus, hidden items do not receive focus and a skip to main content link works.

A screen reader is software that reads screen content aloud or sends it to a braille display, used mainly by blind and low-vision people. Common ones are NVDA, a free Windows reader, JAWS, a paid Windows reader common in enterprises, VoiceOver, built into macOS and iOS, and TalkBack, built into Android. Testers usually cover NVDA with a desktop browser plus VoiceOver or TalkBack on mobile.

Alt text gives a text alternative for images so screen reader users get the same information. Check that informative images have short, meaningful alt text, such as 'Bar chart showing sales doubled in 2025', that decorative images have empty alt so they are skipped, and that image buttons describe the action, such as 'Search', not the picture. Inspect the alt attribute in developer tools and listen with a screen reader.

Focus order is the sequence in which keyboard focus moves through interactive elements; it should follow the visual reading order. Visible focus means the focused element clearly shows a ring or highlight. Test by pressing Tab through the page and watching where focus goes. Common bugs are focus jumping to the footer, focus going behind an open dialog and designers removing the outline with CSS, leaving keyboard users lost.

A keyboard trap is when focus moves into a component and the user cannot move out using the keyboard, for example an embedded video player or date picker that captures Tab forever. Mouse users never notice, but keyboard and screen reader users are stuck and must reload the page. It fails WCAG criterion 2.1.2. Test every widget by tabbing in and out, and check that Escape closes popups and returns focus.

Visibility of system status: after clicking Pay, show a progress indicator so users do not click again. Error prevention: disable the Submit button until required fields are valid, or ask for confirmation before deleting an account. Recognition rather than recall: show recently searched items and saved addresses instead of making users remember them. Other heuristics include consistency, user control with undo, and clear help for recovering from errors.

This relies on colour alone to give information, which fails WCAG criterion 1.4.1. Users with red-green colour blindness, which affects a noticeable share of men, cannot tell the states apart, and screen readers announce nothing. Recommend adding text or icons such as a tick and a cross with labels like 'Passed' and 'Failed', and accessible names for the dots. Test with a colour blindness simulator in browser developer tools.

1. Open and close by click and keyboard. 2. Select one, then several options; all show as chips or a count. 3. Deselect an option. 4. Select all and clear all, if available. 5. Search inside the list filters options. 6. Maximum selection limit is enforced with a message. 7. Required field shows an error if none selected. 8. Saved selection persists after refresh. 9. Long option names do not break layout. 10. Screen reader announces selected state.

A test harness is the setup of drivers, stubs, test data, scripts and tools needed to run tests on a component and collect results, especially when the full system is not available. For example, to test a pricing module, a harness can feed it input files, stub the tax service and compare outputs with expected values. In automation, the framework, runner and reporting together are often called the harness.

A regression bug is a feature that worked before but broke after a new change, such as login failing after a profile page update. It is usually treated with higher priority because it affects existing users. In Jira, add a label such as regression, set the affected version and link it to the story or change that caused it. Tracking these labels over time shows where regression coverage is weak.

I treat review comments as free help. I ask for specifics if a comment is unclear, fix valid points quickly and explain my reasoning if I disagree, with the requirement in hand. For example, a senior once said my cases missed negative paths; I added them and also made a personal checklist for future reviews. Repeated comments show me a skill gap I should work on, not a personal attack.

Test automation means using scripts and tools to run tests, compare results and report them without a person doing each step. It solves slow and repetitive regression, gives fast feedback on every code change in CI, runs the same checks exactly the same way every time and covers many data combinations. It does not replace thinking: exploratory testing, usability judgement and new feature testing still need manual testers.

Good candidates are stable, repeatable and high value: smoke tests, regression of core flows such as login and checkout, data-driven checks with many inputs, API tests and cross-browser runs of the same flow. Poor candidates are features still changing every sprint, one-time tests, tests needing human judgement like look and feel, and flows that are hard to make reliable, such as real OTP or CAPTCHA. Start with what runs most often.

A locator tells the automation tool how to find an element on the page so it can click, type or check it. Common types are ID, name, CSS selector, XPath, link text, and in modern tools role-based locators such as a button with name Login, plus label, placeholder and test ID locators. A good locator is unique, readable and unlikely to change when the page design changes.

A fixed sleep, such as waiting five seconds, is either too long, which makes the suite slow when the page loads in one second, or too short, which makes the test fail when the server is slow. Both waste time and cause flaky results. Instead, wait for a real condition: an element to appear, a network response to finish or a loading spinner to disappear. Modern tools do much of this automatically.

An assertion is the check in an automated test that compares the actual result with the expected result and fails the test if they differ, like the expected result column in a manual test case. A good assertion checks the outcome that matters to the user, such as the order confirmation number appearing, not just that a page loaded. It should be specific, give a clear failure message and avoid fragile details like exact timestamps.

Start with: git clone to copy the test repository; git pull to get the latest changes; git checkout -b feature/login-tests to create a branch; git status and git diff to see changes; git add and git commit -m to save work with a message; and git push to send the branch so you can raise a pull request for review. Also learn to resolve simple merge conflicts and never commit passwords.

Situation: our regression took three days every release. Task: I wanted to help but knew only manual testing. Action: I spent an hour daily learning Python and Playwright, automated the login and search smoke cases first and asked a developer to review my code each week. Result: in two months my scripts ran in CI on every build, saving about a day per release, and I moved into a hybrid QA role.

An environment in Postman is a set of variables, such as base_url and token, that you switch to run the same requests against QA, staging or production-like setups without editing each request. The Collection Runner executes all requests in a collection in order, runs their test scripts and can repeat them with data from a CSV or JSON file. Together they give manual testers a first step into repeatable API automation.