Test tools: Selenium, JMeter and Postman

In short

Selenium, Apache JMeter and Postman are the three open-source tools that cover the bulk of practical software testing: Selenium drives a real browser to test the user interface, JMeter generates concurrent load to measure performance, and Postman exercises HTTP/REST APIs at the service layer. All three are free (Selenium and JMeter under the Apache License 2.0; Postman is a commercial product with a free tier), which is why Indian service companies (TCS, Infosys, Wipro, Cognizant, Accenture, LTIMindtree, HCLTech) and product firms (Zoho, Freshworks, Razorpay, Flipkart) list them in almost every QA job description. University syllabi examine them under "Software Testing and Automation" / "Software Testing Tools" labs, and placement rounds ask for locators, waits, a thread-group calculation and a collection-with-assertions walkthrough. The examinable skill is not clicking the GUI but knowing what each tool can and cannot test, and the numbers behind a load test.

Explained

Where each tool sits in the test pyramid

• Test pyramid: many fast unit tests (JUnit/TestNG) at the base, fewer service/API tests in the middle, fewest UI tests on top. Selenium belongs on top, Postman and REST Assured in the middle, JMeter cuts across (it can load either layer).
• Why the shape matters: a UI test is 100-1,000 times slower and far more brittle than a unit test, so an all-Selenium suite becomes the classic "ice-cream cone" anti-pattern - slow, flaky, expensive to maintain.
• Functional vs non-functional: Selenium and Postman verify *correctness* (does it do the right thing); JMeter verifies *performance* - response time, throughput, scalability, stability under load. A tool cannot substitute across that line.
• Classification of tools generally examined: record-and-playback, data-driven, keyword-driven, hybrid frameworks; test management (Jira/Zephyr, TestRail), defect tracking (Jira, Bugzilla), CI servers (Jenkins, GitHub Actions), coverage (JaCoCo), static analysis (SonarQube), mobile (Appium - which reuses the Selenium/W3C WebDriver protocol).

Selenium: architecture and components

• Selenium is a suite, not one program. Components: Selenium IDE (browser extension, record and playback, good for quick smoke scripts, poor for maintainable suites), WebDriver (programmatic browser control - the core), Selenium Grid (distribute tests across machines/browsers), and the retired Selenium RC (replaced by WebDriver from Selenium 2; mentioned in exams only historically).
• How WebDriver works: your test code calls language bindings (Java, Python, C#, JavaScript, Ruby) → commands are sent as W3C WebDriver protocol JSON over HTTP → a browser driver (chromedriver, geckodriver, msedgedriver) → the browser executes and returns a response. Selenium 4 is fully W3C compliant; Selenium 3 and earlier used the older JSON Wire Protocol.
• Selenium Manager (bundled from Selenium 4.6) downloads the matching driver automatically, replacing manual driver paths and the WebDriverManager library for most cases.
• Selenium 4 additions: relative locators (above, below, toLeftOf, toRightOf, near), the Chrome DevTools Protocol (CDP) / BiDi access for network interception, console logs, geolocation and basic-auth, a new Grid (standalone, hub-node, fully distributed), and WebDriver.BiDi as the emerging cross-browser standard.
• Limitations (asked often): Selenium automates web browsers only - no desktop apps (use WinAppDriver/AutoIt), no mobile native apps (use Appium), no image/captcha/OTP handling, no built-in reporting or assertions (TestNG/JUnit + ExtentReports/Allure supply those), and it does not do load testing - 1,000 browsers is not a load test, it is 1,000 problems.

Selenium: locators, waits and the Page Object Model

• Eight locators: id, name, className, tagName, linkText, partialLinkText, cssSelector, xpath. Preference order: id → name → css → xpath (css is faster and more readable; xpath alone can traverse to a parent and supports text()).
• XPath types: absolute (/html/body/div[2]/..., brittle) vs relative (//input[@id='user'], preferred). Axes: parent, child, ancestor, descendant, following-sibling, preceding-sibling. Functions: contains(), starts-with(), text(), normalize-space(), last(), position().
• Three waits: implicit wait (one global polling timeout for element location), explicit wait (WebDriverWait + ExpectedConditions for a specific condition - the recommended one), fluent wait (explicit wait with custom polling interval and ignored exceptions). Thread.sleep() is an unconditional pause and a code smell. Mixing implicit and explicit waits can produce unpredictable total timeouts - avoid.
• Common exceptions: NoSuchElementException (locator wrong or element not yet present), ElementNotInteractableException (present but hidden/overlapped), StaleElementReferenceException (DOM re-rendered after the reference was taken - re-locate), TimeoutException, SessionNotCreatedException (driver-browser version mismatch).
• Handling the awkward bits: switchTo().frame() for iframes, switchTo().alert() for JS alerts, getWindowHandles() for new tabs, Select class for dropdowns, Actions class for hover/drag-drop/keyboard, JavascriptExecutor for scroll and forced clicks, TakesScreenshot for failure evidence.
• Page Object Model (POM): one class per page holding locators and page actions; tests call page methods, so a UI change is fixed in one place. Page Factory uses @FindBy annotations. A hybrid framework = POM + TestNG + data-driven (Excel/CSV via Apache POI) + testng.xml grouping + Maven + Jenkins.
• TestNG features examined: annotations (@BeforeSuite, @BeforeClass, @BeforeMethod, @Test, @AfterMethod...), priority, groups, dependsOnMethods, @DataProvider (data-driven), invocationCount, parallel execution in testng.xml, assertions (Assert.assertEquals) and soft assertions.

Apache JMeter: performance testing

• What it is: a pure-Java desktop tool that simulates many concurrent users against HTTP(S), REST/SOAP, JDBC, JMS, FTP, SMTP/POP3, LDAP and TCP endpoints (gRPC and similar protocols only via plugins). It is protocol-level, not browser-level: it does not render pages or execute JavaScript, so client-side rendering time is invisible to it.
• Test plan elements (standard exam list):
  1. Thread Group - number of threads (virtual users), ramp-up period, loop count; or Ultimate/Concurrency thread groups from plugins for staged load.
  2. Samplers - the request itself (HTTP Request, JDBC Request, FTP, SMTP; SOAP is sent with the HTTP Request sampler, the old SOAP/XML-RPC sampler having been removed).
  3. Logic Controllers - flow: Loop, If, Transaction, Throughput, Module, Once Only.
  4. Config Elements - HTTP Cookie Manager, Header Manager, CSV Data Set Config (parameterisation), User Defined Variables, HTTP Request Defaults.
  5. Pre-processors / Post-processors - e.g. JSON Extractor, Regular Expression Extractor, XPath Extractor for correlation (capturing a token/session id from one response and feeding the next).
  6. Assertions - Response, Duration, Size, JSON, XPath - these make it a *test*, not just traffic.
  7. Timers - Constant, Uniform Random, Gaussian, Constant Throughput Timer - model user think time.
  8. Listeners - View Results Tree, Summary/Aggregate Report, Backend Listener (InfluxDB + Grafana).
• Execution order within a scope: Config elements → Pre-processors → Timers → Sampler → Post-processors → Assertions → Listeners.
• Types of performance test: load (expected peak), stress (beyond peak, to find the breaking point), soak/endurance (hours, to find memory leaks), spike (sudden surge - an IPL-match or exam-result spike), volume (large data), scalability (does adding servers help linearly), breakpoint.
• Metrics: average, median, 90th/95th/99th percentile response time, throughput (requests/sec), error %, latency vs connect time vs elapsed time, standard deviation. Percentiles matter because an average hides the slow tail; SLAs in Indian contracts are usually written on the 90th or 95th percentile.
• Correct practice: run in non-GUI (CLI) mode - jmeter -n -t plan.jmx -l result.jtl -e -o report/ - because the GUI and listeners consume heap and distort results; use the GUI only to build and debug. Disable View Results Tree for real runs. Use distributed testing (master + slaves) when one load generator saturates. Watch the generator's own CPU/network before blaming the server.
• Limitations: no JavaScript execution, high memory per thread compared with event-driven tools (Gatling, k6, Locust), scripting in Groovy via JSR223 rather than a full language, and correlation must be done by hand.

Postman: API testing

• Scope: build, send and automate HTTP requests - methods GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS; bodies as JSON, form-data, x-www-form-urlencoded, raw, binary, GraphQL; also WebSocket and gRPC.
• Building blocks: request → collection (folder of requests, the unit of automation) → environment and variables (global, collection, environment, local/data, scoped by precedence - local wins) → pre-request script and test script (JavaScript, pm.* API) → Collection Runner (run a collection with a CSV/JSON data file for data-driven runs) → Newman (the Node.js CLI that runs the same collection in Jenkins/GitHub Actions) → monitors, mock servers and auto-generated documentation.
• Tests look like: pm.test("status is 200", () => pm.response.to.have.status(200)); and pm.expect(pm.response.json().data.id).to.eql(7); - Chai-style assertions. Chaining: extract a token in one test with pm.environment.set("token", pm.response.json().token) and use it in the next request's header as a variable.
• Auth types supported: Basic, Bearer token, API key, OAuth 1.0/2.0, AWS Signature, Digest, NTLM, JWT bearer.
• Status codes to know cold: 200 OK, 201 Created, 204 No Content, 301/302 redirect, 400 Bad Request, 401 Unauthorised (not authenticated), 403 Forbidden (authenticated, not permitted), 404 Not Found, 405 Method Not Allowed, 409 Conflict, 415 Unsupported Media Type, 422 Unprocessable, 429 Too Many Requests (rate limit), 500/502/503/504 server-side.
• Idempotency: GET, PUT, DELETE, HEAD, OPTIONS are idempotent; POST and PATCH are generally not - a favourite interview question, and the reason a payment API is retried with an idempotency key.
• Limitations: not a load-testing tool (its performance feature is for light checks, not a replacement for JMeter), not a UI tool, cloud sync of collections raises a data-handling question for client APIs - keep secrets in environment variables and never commit them.

Fitting them into CI/CD and the Indian delivery context

• Pipeline: commit → unit tests → build → deploy to test → Newman API suite → Selenium regression on key journeys → JMeter CLI performance gate (fail the build if 95th percentile > target) → report.
• Selenium Grid / cloud grids (BrowserStack - an Indian-founded company - LambdaTest, Sauce Labs) give real device and browser coverage without an in-house lab; cost is per parallel session.
• Shift-left and shift-right: API tests run earliest (cheapest to fix); JMeter also runs post-release as production-like soak tests.
• Standards and documents an Indian QA engineer meets: ISO/IEC/IEEE 29119 (software testing - processes, documentation, techniques), the former IEEE 829 test documentation standard (superseded by 29119), ISO/IEC 25010 product quality model (performance efficiency, usability, security as explicit characteristics), ISO 9001:2026 for the quality management system, CMMI for process maturity, and ISTQB Foundation Level as the usual certification. Security testing of Indian web applications is commonly guided by OWASP Top 10 and, for government projects, STQC (Standardisation Testing and Quality Certification, MeitY) web-application security audit and empanelled auditor requirements. Under the IT Act, 2000 s.43A and the SPDI Rules, reasonable security practices apply to sensitive personal data in test data too; the Digital Personal Data Protection Rules, 2025 bring the Data Fiduciary duties into force only from 13 May 2027 - so the practical rule today is still to mask or synthesise personal data in test environments rather than copying production data.

Key points

• Selenium - open-source browser automation via the W3C WebDriver protocol; functional/regression testing of web UIs only.
• Selenium components - IDE (record-playback), WebDriver (core), Grid (parallel/distributed); RC is obsolete.
• Browser driver - a separate executable per browser translating WebDriver commands; Selenium Manager fetches it automatically since 4.6.
• Locator preference - id > name > cssSelector > xpath; relative XPath over absolute.
• Explicit wait - waits for a named condition on one element; the correct fix for flakiness, unlike Thread.sleep().
• StaleElementReferenceException - the reference points to a DOM node replaced by a re-render; re-locate the element.
• Page Object Model - locators and actions per page class; one edit fixes every test when the UI changes.
• **TestNG @DataProvider** - supplies multiple data sets to one test method (data-driven testing).
• JMeter Thread Group - threads = virtual users, ramp-up = time to start them all, loops = iterations each.
• Correlation - extracting a dynamic value (token, session id) from a response for the next request; without it, load scripts fail at login.
• Percentile response time - the 95th percentile is the value 95% of requests beat; averages hide the slow tail.
• Non-GUI mode - the only valid way to run a real JMeter load test; the GUI distorts results.
• Stress vs load vs soak - beyond peak to find the break point / at expected peak / long duration to expose leaks.
• Postman collection - the automation unit; run with the Collection Runner interactively or Newman in CI.
• Postman variable scopes - global < collection < environment < data < local, narrowest wins.
• 401 vs 403 - not authenticated vs authenticated but not authorised.
• Idempotent methods - GET, PUT, DELETE, HEAD, OPTIONS; POST and PATCH are not.
• Tool boundaries - Selenium cannot load test, JMeter cannot see client-side rendering, Postman cannot test the UI.

Formulas and examples

Example 1 - Thread group arithmetic. A test plan has 200 threads, ramp-up 100 s, loop count 5, and each iteration fires 4 HTTP requests (login, search, view, logout). The steady-state run lasts 10 minutes.

• Ramp-up rate = 200/100 = 2 users per second.
• Total samples = 200 × 5 × 4 = 4,000 requests.
• If all 4,000 complete in 600 s, throughput = 4,000/600 = 6.67 requests/second = 400 requests/minute.

Example 2 - Little's law sizing for a results portal. A university results page must serve 9,000 page views per minute at peak. Measured server response time is 0.8 s and realistic user think time between pages is 7 s.

• Target throughput X = 9,000/60 = 150 requests/second.
• Required virtual users N = X × (R + Z) = 150 × (0.8 + 7) = 150 × 7.8 = 1,170 threads.
• At ~8 MB heap-equivalent cost per thread, 1,170 threads need ≈ 9.4 GB - well beyond a 4 GB heap - so split across 3 load generators ≈ 390 threads each (≈ 3.1 GB each) in distributed mode.
• Sanity check with Little's law in reverse: 1,170/7.8 = 150 req/s. Correct.

Example 3 - Percentiles from a sample. Twenty sorted response times (ms): 120, 130, 140, 150, 160, 170, 180, 190, 200, 210, 220, 230, 240, 260, 280, 300, 350, 500, 900, 1,400.

• Sum = 6,330 ms → average = 316.5 ms.
• Median (10th and 11th values averaged) = (210 + 220)/2 = 215 ms.
• 90th percentile (nearest-rank, ceil(0.90 × 20) = 18th value) = 500 ms.
• 95th percentile (ceil(0.95 × 20) = 19th value) = 900 ms.
• Reading: the average (316.5 ms) suggests a healthy system, but 1 in 20 users waits almost a second - which is why the SLA is written on the 95th percentile.

Example 4 - Apdex. 1,000 samples with threshold T = 1.0 s: 820 under 1.0 s (satisfied), 140 between 1.0 s and 4T = 4.0 s (tolerating), 40 above 4.0 s or failed.

• Apdex = (820 + 0.5 × 140)/1,000 = (820 + 70)/1,000 = 890/1,000 = 0.89 - "good" on the usual scale, below an "excellent" 0.94.

Example 5 - Suite cost: why the pyramid. A regression pack of 600 cases: as Selenium UI tests at 45 s each → 600 × 45 = 27,000 s = 7.5 hours sequentially; with Grid at 10 parallel sessions → 45 minutes. The same 600 checks as Postman/Newman API tests at 0.4 s each → 240 s = 4 minutes. Keeping only the 80 true journey tests in Selenium (80 × 45 = 3,600 s = 1 hour sequential, 6 minutes at 10× parallel) and the rest at API level gives a ~10-minute pipeline instead of 7.5 hours.

Where it is used

• IT services and QA delivery (TCS, Infosys, Wipro, Cognizant, Accenture, LTIMindtree, Capgemini India): "Automation Test Engineer - Selenium/Java/TestNG" and "Performance Test Engineer - JMeter/LoadRunner" are among the highest-volume fresher QA roles.
• Banking, payments and fintech (HDFC, ICICI, Razorpay, PhonePe, Paytm): JMeter soak and spike tests on payment APIs before festive or salary-day peaks; Postman suites for UPI/NPCI-style API contracts; idempotency and retry testing.
• Government and public digital services (IRCTC, income-tax and GST portals, university result portals, UIDAI-linked services): spike testing for result-day or return-filing deadlines; STQC security-audit requirements for government web applications.
• E-commerce and consumer products (Flipkart, Myntra, Swiggy, Zomato, Zoho, Freshworks): cross-browser Selenium Grid regression on checkout journeys and large JMeter sale-event rehearsals.
• Roles: SDET / automation engineer (Selenium + API), performance engineer (JMeter, Grafana, APM tools like Dynatrace/New Relic), API developer using Postman for contract and documentation work, DevOps engineer wiring all three into Jenkins or GitHub Actions.
• Testing-services and tool companies: BrowserStack and LambdaTest (both Indian-founded) sell cloud Selenium/Appium grids; Qualitest, Indium and Cigniti deliver outsourced testing from India.

Interview questions

• Q: What is the difference between Selenium IDE, WebDriver and Grid? A: IDE is a record-and-playback browser extension for quick scripts; WebDriver is the programmable API that drives a browser through its driver; Grid distributes tests across machines and browsers for parallel execution.
• Q: Why is an explicit wait better than an implicit wait or Thread.sleep()? A: An explicit wait polls for a specific condition on a specific element and continues as soon as it is met, so it is both reliable and fast; an implicit wait applies one blunt timeout everywhere and Thread.sleep() always wastes the full duration.
• Q: What causes StaleElementReferenceException and how do you fix it? A: The element reference was taken before the DOM was re-rendered or the page navigated, so the node no longer exists; re-locate the element (ideally inside a wait or a retry) instead of reusing the old reference.
• Q: CSS selector or XPath - which do you prefer and why? A: CSS is usually faster and more readable, so it is the default; XPath is needed when you must traverse upwards to a parent, use text(), or use axes such as following-sibling.
• Q: Can Selenium be used for performance testing? A: No - each thread needs a full browser, so it cannot generate meaningful concurrency; use JMeter, Gatling or k6, and use Selenium only to measure single-user client-side timings.
• Q: In JMeter, what do threads, ramp-up and loop count mean? A: Threads are virtual users, ramp-up is the time over which they all start, and loop count is how many times each thread repeats the test plan; 100 threads with 50 s ramp-up start 2 users per second.
• Q: What is correlation in JMeter and why is it unavoidable? A: Capturing a dynamic server value such as a CSRF token or session id from one response (with a Regular Expression or JSON Extractor) and sending it in the next request; hard-coded recorded values fail on replay, so the script would break at login.
• Q: Why must a real JMeter load test run in non-GUI mode? A: The GUI and graphical listeners consume CPU and heap on the load generator, reducing the load it can produce and skewing the measured response times.
• Q: Average response time is 300 ms but users complain. What do you check? A: The percentiles and error rate - a 95th percentile of 900 ms and a long tail mean a slice of users is slow, and averages hide that; also check whether the load generator itself was saturated.
• Q: What is the difference between load, stress and soak testing? A: Load applies the expected peak to verify SLAs, stress pushes beyond it to find the break point and failure behaviour, and soak runs for hours at moderate load to expose memory leaks and resource exhaustion.
• Q: How do you chain API requests in Postman? A: Extract the value in the first request's test script with pm.environment.set("token", pm.response.json().token) and reference it as a variable in the next request's header or body.
• Q: What is the difference between 401 and 403, and which methods are idempotent? A: 401 means not authenticated, 403 means authenticated but not permitted; GET, PUT, DELETE, HEAD and OPTIONS are idempotent, POST and PATCH are not.
• Q: How does Newman differ from the Collection Runner? A: Both run a collection, but the Collection Runner is interactive inside the Postman app while Newman is the Node.js CLI that runs the exported collection headlessly in a CI pipeline and produces machine-readable reports.

Common mistakes

• Writing Thread.sleep() everywhere, or mixing implicit and explicit waits, and then calling the resulting flakiness a "Selenium bug".
• Using absolute XPath copied from browser dev tools - it breaks on the first layout change.
• Treating Selenium as an all-purpose tool: attempting load tests, desktop apps, mobile native apps, captcha or OTP flows with it.
• Running a JMeter load test from the GUI with View Results Tree enabled, then reporting the inflated response times as the application's performance.
• Quoting only the average response time, with no percentile, error rate or denominator ("tested with 500 users" - for how long, how many requests, how many failed?).
• Skipping correlation and cookie/header managers, so every virtual user reuses one recorded token and the test measures an error path, not the application.
• Hard-coding URLs, credentials or tokens inside Postman requests and committing them, instead of using environment variables - and copying real production personal data into test environments.
• Not verifying that the load generator (CPU, memory, network) was itself healthy before blaming the server.

Related topics

Software testing: levels, types and test case design · Software quality assurance: metrics, reviews and standards · CI/CD and DevOps pipelines · REST API design and HTTP · Web technologies and the DOM · Software architecture: monoliths and microservices