Performance and Security Basics Interview Questions for Software Testing

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.

Measuring speed and stability: load (expected users), stress (beyond limits), spike (sudden surge), endurance (long duration) and scalability testing.

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.

A performance baseline is a set of measurements of the current system under a known load, such as response times, throughput, error rate and resource usage. Every new build or release is compared with it to spot regressions. For example, if the checkout API had p95 of 800 milliseconds at 200 users last release and now shows 1.5 seconds, the change needs investigation. A benchmark compares against an industry or competitor standard.

Explain that daily users are not concurrent users. Of 50,000 users a day, only a fraction are active at the same moment, and even they pause between actions because of think time. Use analytics to find the real peak concurrency and request rate, for example 1,500 concurrent users at peak hour, and model that with a safety margin. Running 50,000 users clicking at once tests a load that never happens and wastes effort.

A bottleneck is the component that limits the whole system's performance, so adding load beyond it increases response times or errors. Common places are slow database queries or missing indexes, too few database connections or threads, CPU or memory limits on servers, slow third-party APIs, large uncompressed files and chatty code that makes many small calls. Monitoring each layer during a test shows which resource saturates first.

Collect details from affected users: location, device, browser, network and time. Try to reproduce with similar conditions using browser network throttling. Use the browser developer tools network tab to find slow requests, large files or failing calls, and compare with a fast user. Check whether those users have more data, like a long order history. Share the slow request, timing and conditions in the bug for the developers.

The OWASP Top 10 is a widely used list of the most critical web application security risks, published by an open community project. It includes broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components and authentication failures. Testers use it as a checklist to include basic security checks in their testing and to speak the same language as security teams.

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.

XSS is a vulnerability where an attacker's script is injected into a page and runs in other users' browsers, which can steal session data or change the page. It occurs when user input is shown without proper encoding. Testers enter a harmless script tag or an image tag with an onerror alert in comments, profile names and search boxes, then check if it executes when the page is displayed. Output encoding prevents it.

Check that a new session ID is created after login, and that the session expires after the defined idle time. Verify logout invalidates the session on the server, so pressing back or reusing the old cookie does not work. Check that cookies use Secure, HttpOnly and SameSite flags. Test concurrent logins if they are limited, and that changing the password ends other sessions. Session IDs must not appear in URLs.

Check that responses return only needed fields, with no passwords, password hashes, full card numbers, full ID numbers or internal keys. Verify personal data is masked where required, for example only the last four digits of a phone number. Look at application and browser console logs for tokens or personal data. Check error responses do not expose stack traces, SQL or server versions. Raise any leak as a high-severity bug.

Treat it as a high-severity security defect, because storing full card numbers in logs breaks payment card security rules and creates a data leak risk. Do not copy the card numbers into the bug; use masked examples and the log location instead. Log the bug with restricted visibility and inform your lead and the security contact right away. After the fix, verify new logs are masked and confirm old logs are cleaned.

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.

Check SQL injection, brute-force lockout, password masking, session timeout, HTTPS, cookie flags, error messages not revealing users and password reset flow.

Model answer: Situation: a new fresher on my team was writing very long, unclear bug reports. Task: help her improve quickly. Action: I reviewed five of her bugs with her, showed a simple template, paired with her on two exploratory sessions and gave weekly feedback. Result: within a month developers stopped asking her for clarification, and she later found and reported a major session bug on her own.

A workload model describes the realistic load to simulate: which user journeys run, their mix in percentages, the number of concurrent users, request rates, think times, data volumes and the ramp-up pattern. For example, 60 percent browse, 25 percent search, 10 percent add to cart and 5 percent checkout at a peak of 2,000 concurrent users. It is built from production analytics and business forecasts, and wrong models produce meaningless results.

The result is a failure, not a pass. Failed requests often return quickly, so they make response times look better than they are. Check which requests fail and with which errors, such as 500, 503 or timeouts, and when errors started relative to the load level. Look at server logs, connection pool and thread limits. Also confirm the script is not wrong, for example expired tokens or bad test data.

Cross-site request forgery tricks a logged-in user's browser into sending an unwanted request to a site, such as changing their email, because the browser automatically includes cookies. Prevention includes anti-CSRF tokens in forms, SameSite cookie settings and re-authentication for sensitive actions. Testers check that state-changing requests fail when the token is missing or reused, and that such actions are not done through GET requests.

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.

Vulnerability scanning uses automated tools to look for known weaknesses, such as outdated libraries, missing security headers or open ports. It is fast, repeatable and can run in the pipeline, but gives false positives. Penetration testing is a deeper, mostly manual exercise by security experts who try to exploit weaknesses and chain them like a real attacker. Teams scan regularly and run penetration tests before major releases or yearly.

Start with low-cost steps. Add an OWASP-based security checklist to the definition of done for stories touching login, payments or personal data. Train testers on access control, injection and session checks. Add automated dependency and vulnerability scans to the CI pipeline. Include negative authorization tests in API suites. Arrange a penetration test before major releases and track security bugs separately with clear severity rules.

A memory leak happens when an application keeps holding memory it no longer needs, so usage grows the longer it runs. A manual tester may notice the app getting slower over a long session, a browser tab using more and more memory in Task Manager or the browser's memory panel, or a mobile app crashing after repeatedly opening and closing a screen. Report the steps, duration and memory readings over time.

Clickjacking tricks a user into clicking something on your site while it is hidden inside a frame on an attacker's page, for example a hidden Transfer button under a fake Play button. A tester checks whether sensitive pages can be loaded in an iframe on another site, and inspects response headers for Content-Security-Policy frame-ancestors or X-Frame-Options set to DENY or SAMEORIGIN. If the page loads in the frame, log it.

Apache JMeter is an open-source load testing tool, mainly for HTTP APIs and web pages. A basic test plan has a Thread Group that sets the number of virtual users, ramp-up time and loop count; samplers such as HTTP Requests; config elements like headers and CSV data; timers for think time; assertions on responses; and listeners or reports showing response times, throughput and errors. Run real load in non-GUI mode.