Skip to content

Software Testing Interview Questions for Telecom Companies

40 questions weighted to the interview style of telecom companies — 10 easy, 28 medium, 2 hard.

How telecom companies interview for Software Testing

Telecom and network companies handle huge volumes of customer and network data. Interviews focus on fundamentals, practical skills, and scenario questions about reliability, large datasets and customer-facing systems.

This set focuses on Testing Types (6), Manual Testing Basics (6), Bug Life Cycle and Jira (5), Test Case Design (4).

HR round Online assessment (aptitude + technical) Managerial round Technical interview Technical interview 1
Solved — telecom companiesStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
3 questions free Unlock the rest in seconds
01

How do you test password policy and account lockout?

Save to ▾
Show answer
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.
02

What is the testing pyramid?

Save to ▾
Show answer
A model with many fast unit tests at the base, fewer API or integration tests in the middle and a small number of UI tests at the top.
03

What is defect removal efficiency?

Save to ▾
Show answer
Defect removal efficiency shows how many defects the team found before release. DRE = defects found before release divided by (defects found before release plus defects found after release), multiplied by 100. If QA found 90 bugs and users reported 10, DRE is 90 percent. A falling DRE means testing is missing more defects, and the escaped bugs should be analysed to improve test coverage.
04

What is a test basis?

Save to ▾
Show answer
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.
05

What is state transition testing?

Save to ▾
Show answer
Testing how a system moves between states based on events, for example an order going from placed to paid to shipped to delivered.
06

How do you plan testing for a two-week sprint?

Save to ▾
Show answer
In sprint planning, review each story's acceptance criteria and estimate test effort, including test data and regression. Write test cases in the first days while development starts. Ask for early builds so testing is spread across the sprint, not crowded at the end. Keep time for regression and bug retesting in the last two or three days. Track progress on the board and raise risks in stand-up.
07

How do you decide the priority of test cases?

Save to ▾
Show answer
By business criticality, usage frequency, defect history, risk and dependencies, running high-priority cases first.
08

What is a bug triage meeting?

Save to ▾
Show answer
A regular review where QA, development and product assess new bugs and decide severity, priority, owner and target release.
09

A feature passed all your test cases, but users say it is confusing. What went wrong?

Save to ▾
Show answer
The tests verified the specification but did not validate the user experience. The test cases probably checked only functional outcomes and missed usability: unclear labels, too many steps or poor error messages. Next time, add usability heuristics to reviews, do exploratory sessions as a real user persona and involve users in UAT or demos. Log the current feedback as improvement items with clear examples.
10

What is the difference between statement coverage and branch coverage?

Save to ▾
Show answer
Statement coverage measures the percentage of code statements executed by tests. Branch coverage measures whether every decision outcome, true and false, has been executed. Branch coverage is stronger: for 'if (amount > 1000) applyDiscount()', one test with 1500 gives 100 percent statement coverage, but you need a second test with 500 to cover the false branch. 100 percent branch coverage implies 100 percent statement coverage, not the other way round.
11

What are latent defects and masked defects?

Save to ▾
Show answer
A latent defect exists in the software but has not caused a failure yet because the needed conditions have not occurred, such as a leap-year bug that appears only on 29 February. A masked defect is hidden by another defect, for example a broken discount calculation you cannot reach because the cart page crashes first. After the first bug is fixed, the masked one appears, which is one reason regression and retesting matter.
12

How do you handle a bug found late in a release cycle?

Save to ▾
Show answer
Assess impact and risk, discuss with product and dev, decide to fix, defer with a workaround or delay release, and document the decision.
13

What is accessibility testing?

Save to ▾
Show answer
Checking that people with disabilities can use the product, using screen readers, keyboard navigation, colour contrast and WCAG guidelines.
14

How do you break a requirement into testable conditions?

Save to ▾
Show answer
Read the requirement and identify inputs, outputs, business rules, user roles and states. Turn each rule into a condition with an expected result, then add negative and boundary conditions. For example, 'users can withdraw up to 10,000 per day' becomes: withdraw below the limit, exactly at the limit, above the limit, multiple withdrawals adding up to the limit, and the limit resetting the next day. Each condition then becomes one or more test cases.
15

You change the order ID in a URL and see another customer's order. What is this and what do you do?

Save to ▾
Show answer
This is an insecure direct object reference, a form of broken access control and a critical security bug, because any user can read other users' data. Stop exploring further beyond what is needed to confirm it, record the request, accounts used and evidence, and log it as a critical bug with restricted visibility. Inform the lead and security contact immediately. The fix is a server-side ownership check on every request.
16

What automated accessibility tools exist and what are their limits?

Save to ▾
Show answer
Common tools are axe DevTools, Lighthouse in Chrome, WAVE and accessibility linters in CI. They quickly catch missing alt text, low contrast, missing labels and invalid ARIA. Their limit is that they find only roughly a third of WCAG issues. They cannot judge whether alt text is meaningful, focus order is logical, error messages make sense or a custom widget works with a screen reader, so manual testing is still required.
17

Write a CSS selector and an XPath for a Login button that has the attribute data-testid='login-btn' and the text Login.

Save to ▾
Show answer
/* CSS selector using the test id */ button[data-testid='login-btn'] // XPath using the test id //button[@data-testid='login-btn'] // XPath using the visible text //button[normalize-space()='Login']
18

The UI shows the correct order total, but the database has a different value. What do you check?

Save to ▾
Show answer
Note the order ID and compare the UI value, the API response and the database value to find where they differ. Check if the UI calculates the total on the screen instead of using the saved value, whether taxes, discounts or rounding are applied at different layers and whether a later update job changed the record. Log the bug with all three values, because invoices and reports will use the database figure.
19

How is back-end database testing different from front-end UI testing?

Save to ▾
Show answer
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.
20

How do you test database integrity using SQL?

Save to ▾
Show answer
Verify inserted, updated and deleted rows match UI actions, check constraints, duplicates, NULLs and totals with COUNT and SUM queries.
21

What are the characteristics of a good test case?

Save to ▾
Show answer
Clear, concise, independent, repeatable, traceable to a requirement, with precise expected results and tested data.
22

What is a bug bash and how do you run one?

Save to ▾
Show answer
A bug bash is a short, time-boxed session where people from across the team, including developers, product and support, test the product together to find as many issues as possible before a release. To run one, share a build, scope and test accounts, assign focus areas, give a simple bug template and a shared board, then triage findings at the end. It brings fresh eyes and finds usability issues formal tests miss.
23

What is the difference between retesting and regression testing?

Save to ▾
Show answer
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.
24

How do you plan testing for a feature that depends on a third-party service?

Save to ▾
Show answer
Identify the integration points and the service's sandbox, limits and test data. Plan to test with a mock or stub early for our logic and error handling, then against the real sandbox for integration. Include failure scenarios: timeout, slow responses, invalid data and the service being down. Add the dependency to the risk list, with contacts and a fallback plan, and confirm production credentials and monitoring before go-live.
25

What are test data and how do you prepare them?

Save to ▾
Show answer
The inputs used in tests. Prepare using valid, invalid and boundary values from production-like but masked data, spreadsheets or generators.
26

What is boundary value analysis?

Save to ▾
Show answer
Testing at the edges of input ranges, such as 17, 18 and 19 for an age limit of 18, since errors cluster at boundaries.
27

What is a test case and its components?

Save to ▾
Show answer
A set of steps with inputs and expected results. Components: ID, title, preconditions, steps, test data, expected result, actual result and status.
28

How would you test a web page you have never seen before in 30 minutes?

Save to ▾
Show answer
Spend five minutes understanding its purpose and main user flows. Then run a quick smoke check of the main flow end to end, test key inputs with valid, invalid and boundary values, check links, buttons and error messages, and try the page on a second browser and a mobile width. Keep short notes and take screenshots as you go. Report the top issues by risk at the end, not every small cosmetic point.
29

Why are stable locators like data-testid or roles preferred over position-based XPath?

Save to ▾
Show answer
A position-based XPath such as /html/body/div[3]/div[2]/button breaks whenever a developer adds a wrapper div or reorders the layout, even though the feature still works. That creates false failures and maintenance work. Locators based on a dedicated data-testid attribute or the accessible role and name, like a button named Submit, stay valid through design changes and describe intent clearly. Testers should ask developers to add test IDs.
30

Tell me about a time exploratory testing helped you find a critical bug.

Save to ▾
Show answer
Model answer: Situation: a new leave management module had passed all scripted cases. Task: I had a one-hour exploratory session. Action: I applied leave, then changed my manager in the profile while the request was pending. Result: the request disappeared for both managers and could never be approved. It was fixed before release, and the team added role-change scenarios to the regression suite.
31

What is colour contrast ratio and what values does WCAG require?

Save to ▾
Show answer
Contrast ratio compares the brightness of text and its background, from 1:1 to 21:1. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text, which is about 18 point or 14 point bold. User interface parts such as input borders and icons need 3:1. AAA raises text to 7:1. Testers check this with a contrast checker or browser developer tools, including placeholder, disabled and hover states.
32

What is a sprint planning meeting and what does QA contribute?

Save to ▾
Show answer
The team selects stories for the sprint. QA helps estimate testing effort, clarifies acceptance criteria and flags dependencies and risks.
33

What is WCAG and what are its conformance levels?

Save to ▾
Show answer
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.
34

How do you do cross-browser testing and choose which browsers to cover?

Save to ▾
Show answer
Use analytics to pick browsers and versions that most real users have, plus the ones listed in the requirement, usually the latest two versions of major desktop and mobile browsers. Run the main flows on each and check layout, fonts, forms, date pickers, file upload and JavaScript errors in the console. Use responsive mode for screen sizes, and real devices or a cloud device lab for mobile browsers.
35

Why is orientation and screen size testing important?

Save to ▾
Show answer
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.
36

What are the levels of testing?

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

What is the difference between a story, epic, task and bug in JIRA?

Save to ▾
Show answer
An epic is a large body of work; stories are user-facing slices of it; tasks are technical work items; bugs are defects.
38

What does POUR mean in accessibility?

Save to ▾
Show answer
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.
39

What is SQL injection and how can a tester check for it at a basic level?

Save to ▾
Show answer
SQL injection happens when user input is added directly into a database query, letting an attacker change the query to read or modify data. A tester can enter inputs like a single quote or ' OR '1'='1 in login, search and URL parameters and watch for database errors, unexpected results or a login bypass. Only test in approved environments. The real fix is parameterised queries, not input filtering alone.
40

What is the difference between path parameters, query parameters and the request body?

Save to ▾
Show answer
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.

Telecom companies (5)

Frequently asked questions

How are Software Testing interviews at telecom companies different?

Telecom and network companies handle huge volumes of customer and network data. Interviews focus on fundamentals, practical skills, and scenario questions about reliability, large datasets and customer-facing systems.

Which telecom companies are covered?

This page links to 5 telecom companies, including Airtel, Jio Platforms, Ericsson, Nokia, Vodafone Idea. Each has its own page with rounds and a separate practice set.

What rounds should I expect?

Common rounds at these companies include: HR round; Online assessment (aptitude + technical); Managerial round; Technical interview; Technical interview 1. The exact process varies by company and role.