Ericsson Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Ericsson hiring for Software Testing roles
Ericsson is a Swedish telecommunications company that provides network equipment, software and services for mobile operators, including 4G and 5G radio, core networks and network management. In India it supports major telecom operators with network deployment and managed services, and runs research and development centres. It hires telecom engineers, software engineers, testers and network engineers.
For Software Testing roles, this Ericsson practice set focuses most on Test Case Design (9), Manual Testing Basics (5), Bug Life Cycle and Jira (4), Agile, SQL and API Testing (4). It has 17 easy, 23 medium questions, so you can start easy and work up to the harder ones.
Company type
Telecom
Headquarters
Stockholm, Sweden
Main India offices
Gurugram, Bengaluru, Chennai, Noida, Kolkata
Ericsson Software Testing interview process
Online assessment (aptitude + technical)
Technical interview
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for EricssonStart 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
When should you reopen a bug and when should you log a new one?
Reopen the bug when the same issue, with the same steps and expected result, still fails after the fix. Log a new bug when the fix works but a different problem appears, even in the same screen, or when the original bug has already been closed in a past release. Link the new bug to the old one. Mixing different problems in one reopened ticket confuses tracking and metrics.
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.
05
What is a test scenario for the login functionality at a high level?
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.
07
How do you handle it when a reviewer criticises your test cases?
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.
08
Tell me about a device-specific bug you found and how you reported it.
Model answer: Situation: users of one budget phone model reported that the camera upload screen was black. Task: reproduce it. Action: I borrowed the same model, found the issue only appeared when the battery saver was on, and logged the bug with the device model, OS version, logs and a video. Result: the developer fixed the camera initialisation, and we added that model to our device matrix.
Check the state list is empty or disabled until a country is selected. Select a country and verify the correct states load. Change the country and confirm the old state selection is cleared and the new list loads. Test countries with no states, a long list with scrolling and search, and default values on page load. Submit the form and verify the saved values, then reload and check both dropdowns keep the saved selection.
11
What is test automation and what problems does it solve?
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.
SELECT status, COUNT(*) AS total
FROM orders
WHERE created_at >= CURRENT_DATE
AND created_at < CURRENT_DATE + INTERVAL '1 day'
GROUP BY status
ORDER BY total DESC;
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.
Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.
18
A report shows duplicate rows after a new release. How do you investigate in the database?
Run the report query with GROUP BY on the business key and HAVING COUNT(*) > 1 to find which records repeat. Then check whether the duplicates exist in the base table or are created by the query, usually a new join to a one-to-many table such as addresses. Compare the query before and after the release. Include the duplicate keys, the count and the suspected join in the bug report.
19
What is the difference between alpha and beta testing?
Verify notifications arrive when the app is in foreground, background and closed. Check title, text, icon and that tapping opens the right screen with the correct data. Test with notifications disabled at OS level and inside app settings. Check behaviour after logout, reinstall and on multiple devices with the same account. Test grouping of many notifications, time-sensitive ones, and that no notification shows private data on the lock screen.
21
Write a simple Playwright test in TypeScript that logs in and checks the dashboard heading.
Entry criteria are conditions that must be met to start testing (build ready, environment set); exit criteria define when testing can stop (pass rate, no critical defects).
-- Business rule: at most one ACTIVE subscription per user
SELECT user_id, COUNT(*) AS active_count
FROM subscriptions
WHERE status = 'ACTIVE'
GROUP BY user_id
HAVING COUNT(*) > 1;
-- Expected result: no rows
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.
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.
It means that finding and fixing many defects does not guarantee success if the system itself does not meet user needs. A bug-free product built on wrong or misunderstood requirements is still a failure. For example, a perfectly working report that shows the wrong business metric is useless to the client. This is why testers validate against real user expectations, not just the written specification.
28
What is the role of a manual tester in a software team?
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.
Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.
30
Why is orientation and screen size testing important?
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.
Shift-left means starting testing activities earlier in the life cycle: reviewing requirements, joining design discussions and writing tests before code is complete. A defect found in requirements may cost a short conversation to fix, while the same defect found in production may need a hotfix, data correction and customer support. Testers shift left by asking questions in grooming, defining acceptance criteria and reviewing designs.
Scalability testing checks how well the system handles growing load by adding resources, such as more servers or bigger machines, and whether performance improves in proportion. For example, if two servers handle 1,000 users, do four servers handle about 2,000 at the same response time? It finds limits that resources cannot fix, such as a single database bottleneck, and helps plan capacity for future growth.
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).
34
Why do performance reports use percentiles like p90 and p95 instead of averages?
An average hides slow requests. If 90 requests take 1 second and 10 take 10 seconds, the average is 1.9 seconds, which looks fine, but one user in ten waits 10 seconds. The p95 value means 95 percent of requests were faster than it, so it shows what most users actually experience, including the slow tail. Service level targets are usually written as percentiles, such as p95 under 2 seconds.
Both are temporary pieces of code used in integration testing when some modules are not ready. A stub replaces a called lower-level module and returns fixed responses, used in top-down testing; for example, a stub payment service that always returns success. A driver replaces a calling higher-level module and sends inputs to the module under test, used in bottom-up testing. In API testing, mock servers play the role of stubs.
37
What are focus order and visible focus, and how do you test them?
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.
Apply a valid coupon and check the discount and final amount. Test invalid, expired and not-yet-active coupons. Check minimum order value, maximum discount cap and category restrictions. Verify one-time-use coupons cannot be reused and that only one coupon applies if stacking is not allowed. Check case sensitivity and leading or trailing spaces. Remove the coupon and confirm the total resets. Change cart items after applying and verify the discount is recalculated.
Tips to crack the Ericsson Software Testing interview
Revise computer networks, TCP/IP, and basics of mobile communication such as LTE and 5G architecture before interviews.
Practise programming in C, C++, Java or Python, and be ready to solve simple coding and debugging problems.
Learn about Ericsson's role in 5G rollouts in India to discuss the industry and your interest in telecom.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; Ericsson interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Ericsson Software Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + technical); Technical interview; Managerial round; HR round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the Ericsson Software Testing interview?
This practice set leans on Test Case Design (9), Manual Testing Basics (5), Bug Life Cycle and Jira (4), Agile, SQL and API Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Ericsson interviewers ask you to walk through real work.
Are these the exact questions asked at Ericsson?
No. These are curated practice questions that match the skills and difficulty usually tested in telecom interviews like Ericsson's. They are not a leaked or verified list of past questions.
Where does Ericsson hire Software Testing professionals in India?
Ericsson has large teams in Gurugram, Bengaluru, Chennai, Noida, Kolkata. Openings and locations change often, so check the Ericsson careers page and filter by city and experience.