Software Testing Interview Questions and Answers

If your objects are tightly coupled to your data layer, it is difficult to do proper unit testing. Your objects should be persistent ignorant. You should have a data access layer, that you would make requests to, that would return objects. Then mock out your calls to the database. This way, you can leave that DB dependants part out of your unit tests, test them in isolation or write integration tests.

Load testing measures system performance as the workload increases. That workload could mean concurrent users or transactions.The system is monitored to measure response time and system staying power as workload increases. That workload falls within the parameters of normal working conditions.

**Profiling **measures how long various parts of the code take to run. Profilers are implemented a lot like

debuggers too, except that rather than allowing you to stop the program and poke around, they simply let it run and keep track of how much time gets spent in every part of the program. This is particularly useful if you have some code that is running slower than you need it to run, as you can figure out exactly where all the time is going, and concentrate your efforts on fixing just that bottleneck.

Functional testing: This is a

verification activity;

did we build a correctly working product? Does the software meet the business requirements? A functional test verifies that the product actually works as you (the developer) think it does. Acceptance testing: This is a

validation activity;

did we build the right thing? Is this what the customer really needs? Acceptance tests verify the product actually solves the problem it was made to solve. This can

best be done by the user (customer), for instance performing his/her tasks that the software assists with.

Some of the performance testing steps are: Identify the testing environment Identify performance metrics Plan and design performance tests Configure the test environment Implement your test design Execute tests Analyze, report, retest

Mocking is primarily used in unit testing. An object under test may have dependencies on other (complex) objects. To isolate the behavior of the object you want to replace the other objects by mocks that simulate the behavior of the real objects. This is useful if the real objects are impractical to incorporate into the unit test. In short, **mocking **is creating objects that simulate the behavior of real objects.

A load test is usually conducted to understand the behaviour of the system under a specific expected load. This load can be the expected concurrent number of users on the application performing a specific number of transactions within the set duration. This test will give out the response times of all the important business critical transactions. A stress testing instead is performed to understand the upper limits of capacity within the system. This kind of test is done to determine the system's robustness in terms of extreme load and helps application administrators to determine if the system will perform sufficiently if the current load goes well above the expected maximum.

Throughput - is calculated as requests/unit of time. The time is calculated from the start of the first sample to the end of the last sample. This includes any intervals between samples, as it is supposed to represent the load on the server. Throughput = (number of requests) / (total time). Connect Time - Measures the time it took to establish the connection, including SSL handshake, Response time - is the elapsed time from the moment when a given request is sent to the server until the moment when the last bit of information has returned to the client Average response time - To get the average response time you should sum all samplers response time and devide to number of samplers. Sampler means user, request, hit, the meaning is the same. Min - the minimal response time in all samplers. Differently we may say the fastest response. Max - opposite of Min, the slowest response. Median - is a number which divides the samples into two equal halves. Half of the samples are smaller than the median, and half are larger. Error % - This column indicated the percentage of error HTTP response codes. Elapsed time - Measures the elapsed time from just before sending the request to just after the last chunk of the response has been received, Latency - Measures the latency from just before sending the request to just after the first chunk of the response has been received, 90% Line (90th Percentile) - The elapsed time below which 90% of the samples fall Standard Deviation - Measure of the variability of a data set. This is a standard statistical measure

Elapsed Time / Connect Time / Latency - should be as low as possible, ideally less than 1 second. Amazon found every 100ms costs them 1% in sales, which translates to several millions of dollars lost, Median - should be close to average elapsed response time, XX% line - should be as low as possible too. When it’s way lower than average elapsed time, it indicates that the last XX% requests have dramatically higher response times than lower ones,

Standard Deviation - should be low. A high deviation indicates discrepancies in responses times, which translates to response time spikes.

**Fake **objects actually have working implementations, but usually take some shortcut which makes them
not suitable for production
**Stubs **provide canned answers to calls made during the test, usually not responding at all to anything

outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

**Mocks **are what we are talking about here: objects pre-programmed with expectations which form a

specification of the calls they are expected to receive.

Unit test: Specify and test one point of the contract of single method of a class. This should have a very narrow and well defined scope. Complex dependencies and interactions to the outside world are stubbed or mocked. Integration test: Test the correct inter-operation of multiple subsystems. There is whole spectrum there, from testing integration between two classes, to testing integration with the production environment. Smoke test (aka Sanity check): A simple integration test where we just check that when the system under test is invoked it returns normally and does not blow up. Smoke testing is both an analogy with electronics, where the first test occurs when powering up a circuit (if it smokes, it's bad!)... ... and, apparently, with plumbing, where a system of pipes is literally filled by smoke and then checked visually. If anything smokes, the system is leaky. Regression test: A test that was written when a bug was fixed. It ensures that this specific bug will not occur again. The full name is "non-regression test". It can also be a test made prior to changing an application to make sure the application provides the same outcome. To this, I will add: Acceptance test: Test that a feature or use case is correctly implemented. It is similar to an integration test, but with a focus on the use case to provide rather than on the components involved. System test: Tests a system as a black box. Dependencies on other systems are often mocked or stubbed during the test (otherwise it would be more of an integration test). Pre-flight check: Tests that are repeated in a production-like environment, to alleviate the 'builds on my machine' syndrome. Often this is realized by doing an acceptance or smoke test in a production like environment.

Canary test is an automated, non-destructive test that is run on a regular basis in a LIVE environment, such that if it ever fails, something really bad has happened. Examples might be: Has data that should only ever be available in DEV/TEST appeared in LIVE. Has a background process failed to run Can a user logon

Adding testing (especially automated testing) makes it much easier to keep the project working in the future, and it makes it significantly less likely that you'll ship stupid problems to the user. In the long run, it will take more time and cost more money to fix bugs after the fact than write tests upfront. Period. Although adding tests to existing code is valuable, it does come at a cost. It comes at the cost of not building out new features. How these two things balance out depends entirely on the project, and there are a number of variables.

• How long will it take you to put all that code under test? Days? Weeks? Months? Years?
• Who are you writing this code for? Paying customers? An open-source project?
• What is your schedule like? Do you have hard deadlines you must meet? Do you have any deadlines at all? The problem with retrofitting unit tests is you'll realise you didn't think of injecting a dependency here or using an interface there, and before long you'll be rewriting the entire component. If you have the time to do this, you'll build yourself a nice safety net, but you could have introduced subtle bugs along the way. If the code is split up reasonably well from the beginning, it's fairly easy to test it. The problem comes when you've got code that is messily all stitched together and where the only test points exposed are for full integration tests.

Q7: Why would you conduct Volume Testing? ☆☆☆☆☆

**Topics:** Software Testing
### Answer:
**Volume testing** determines how efficiently software performs with a large, projected amounts of data.

It is also known as flood testing because the test floods the system with data.

Q8: Could you name some common Performance Testing fallacies? ☆☆☆☆☆

**Topics:** Software Testing
### Answer:
* Performance testing is the last step in development
* More hardware can fix performance issues
* The testing environment is close enough
* What works now, works across the board
* One performance testing scenario is enough
* Testing each part equals testing the whole system

* Software developers are too experienced to need performance testing
* Test scripts are actual users

Q9: Is Unit Testing worth the effort? ☆☆☆☆☆

**Topics:** Software Testing Unit Testing
### Answer:
* Unit Tests allows you to make big changes to code quickly. You know it works now because you've run the

tests, when you make the changes you need to make, you need to get the tests working again. This saves hours.

* TDD helps you to realise when to stop coding. Your tests give you confidence that you've done enough

for now and can stop tweaking and move on to the next thing.

* The tests and the code work together to achieve better code. Your code could be bad / buggy. Your TEST

could be bad / buggy. In TDD you are banking on the chances of both being bad / buggy being low. Often it's the test that needs fixing but that's still a good outcome.

* TDD helps with coding constipation. When faced with a large and daunting piece of work ahead writing

the tests will get you moving quickly.

* Unit Tests help you really understand the design of the code you are working on. Instead of writing

code to do something, you are starting by outlining all the conditions you are subjecting the code to and what outputs you'd expect from that.

* Unit Tests give you instant visual feedback, we all like the feeling of all those green lights when

we've done. It's very satisfying. It's also much easier to pick up where you left off after an interruption because you can see where you got to - that next red light that needs fixing.

* Contrary to popular belief unit testing does not mean writing twice as much code, or coding slower.

It's faster and more robust than coding without tests once you've got the hang of it. Test code itself is usually relatively trivial and doesn't add a big overhead to what you're doing. This is one you'll only believe when you're doing it :)

* I think it was Fowler who said: "Imperfect tests, run frequently, are much better than perfect tests

that are never written at all". I interpret this as giving me permission to write tests where I think they'll be most useful even if the rest of my code coverage is woefully incomplete.

* Good unit tests can help document and define what something is supposed to do
* Unit tests help with code re-use. Migrate both your code and your tests to your new project. Tweak the

code till the tests run again.

Spike testing is a type of stress testing that evaluates software performance when workloads are substantially increased quickly and repeatedly. The workload is beyond normal expectations for short amounts of time.

There are also some mistakes that can lead to less-than-reliable results when performance testing:

1. Not enough time for testing.
2. Not involving developers.
3. Not using QA system similar to production system.
4. Not sufficiently tuning software.
5. Not having a troubleshooting plan.

Big-time investment + knowledge required of knowing how to write testable code.. For the simple case, you lose about 20% of the actual implementation, but for complicated cases, you lose much more. Where you have a large number of tests, changing the system might require re-writing some or all of your tests, depending on which ones got invalidated by the changes. This could turn a relatively quick modification into a very time-consuming one. You might start making design decisions based more on TDD than on actually good design principles. As a result, you now have a much more complex system that is actually more prone to mistakes (and other devs and devs after you shall know how to support it). Complexity of code (DI, IoC, MVC/MVP__) + Design Impacts. When you start using mocks, after a while, you will want to start using Dependency Injection (DI) and an Inversion of Control (IoC) container. To do that you need to use interfaces for everything (which have a lot of pitfalls themselves). At the end of the day, you have to write a lot more code, than if you just do it the "plain old way". Instead of just a customer class, you also need to write an interface, a mock class, some IoC configuration and a few tests. Prototyping can be very difficult with TDD. Continuous Tweaking of tests in the exploration phase of the project. For data structures and black-box algorithms, unit tests would be perfect, but for algorithms that tend to be changed, tweaked or fine-tuned, this can cause a big-time investment that one might claim is not justified. Every time you change the design of a class, now you have to also change the test cases.

Integration tests tell what's not working. But they are of no use in guessing where the problem could be. Unit tests are the sole tests that tell you where exactly the bug is. To draw this information, they must run the method in a mocked environment, where all other dependencies are supposed to correctly work. Consider: A single bug will break several features, and several integration tests will fail.

On the other hand, the same bug will break just one unit test.

It's absolutely worth it. Our app has complex cross-validation rules, and we recently had to make significant changes to the business rules. We ended up with conflicts that prevented the user from saving. I realized it would take forever to sort it out in the application (it takes several minutes just to get to the point where the problems were). I'd wanted to introduce automated unit tests and had the framework installed, but I hadn't done anything beyond a couple of dummy tests to make sure things were working. With the new business rules in hand, I started writing tests. The tests quickly identified the conditions that caused the conflicts, and we were able to get the rules clarified. If you write tests that cover the functionality you're adding or modifying, you'll get an immediate benefit. If you wait for a re-write, you may never have automated tests.

You shouldn't spend a lot of time writing tests for existing things that already work. Most of the time, you don't have a specification for the existing code, so the main thing you're testing is your reverse-engineering ability. On the other hand, if you're going to modify something, you need to cover that functionality with tests so you'll know you made the changes correctly. And of course, for new functionality, write tests that fail, then implement the missing functionality.

Code coverage is great, but functionality coverage is even better. I don't believe in covering every single line I write. But I do believe in writing 100% test coverage of all the functionality I want to provide (even for the extra cool features I came with myself and which were not discussed during the meetings). I don't care if I would have code which is not covered in tests, but I would care if I would refactor my code and end up having a different behaviour. Therefore, 100% functionality coverage is my only target.

Test as early as possible in development. Conduct multiple performance tests to ensure consistent findings and determine metrics averages. Test the individual software units separately as well as together Baseline measurements provide a starting point for determining success or failure Performance tests are best conducted in test environments that are as close to the production systems as possible Isolate the performance test environment from the environment used for quality assurance testing Keep the test environment as consistent as possible Calculating averages will deliver actionable metrics. There is value in tracking outliers also. Those extreme measurements could reveal possible failures.

Response time - Total time to send a request and get a response. Wait time - Also known as average latency, this tells developers how long it takes to receive the first byte after a request is sent. Average load time - The average amount of time it takes to deliver every request is a major indicator of quality from a user’s perspective. Peak response time - This is the measurement of the longest amount of time it takes to fulfill a request. A peak response time that is significantly longer than average may indicate an anomaly that will create problems. Error rate - This calculation is a percentage of requests resulting in errors compared to all requests. These errors usually occur when the load exceeds capacity.

Concurrent users - This the most common measure of load — how many active users at any point. Also known as load size. Requests per second - How many requests are handled. Transactions passed/failed - A measurement of the total numbers of successful or unsuccessful requests. Throughput - Measured by kilobytes per second, throughput shows the amount of bandwidth used during the test. CPU utilization - How much time the CPU needs to process requests. Memory utilization - How much memory is needed to process the request.

During performance testing of software, developers are looking for performance symptoms and issues. Speed issues — slow responses and long load times for example — often are observed and addressed. But there are other performance problems that can be observed: Bottlenecking — This occurs when data flow is interrupted or halted because there is not enough capacity to handle the workload. Poor scalability — If software cannot handle the desired number of concurrent tasks, results could be delayed, errors could increase, or other unexpected behavior could happen that affects: Disk usage CPU usage Memory leaks Operating system limitations Poor network configuration Software configuration issues — Often settings are not set at a sufficient level to handle the workload. Insufficient hardware resources — Performance testing may reveal physical memory constraints or low- performing CPUs.

Scalability testing is used to determine if software is effectively handling increasing workloads. This can be determined by gradually adding to the user load or data volume while monitoring system performance. Also, the workload may stay at the same level while resources such as CPUs and memory are changed.

Endurance testing — also known as soak testing — is an evaluation of how software performs with a normal workload over an extended amount of time. The goal of endurance testing is to check for system problems such as memory leaks. (A memory leak occurs when a system fails to release discarded memory. The memory leak can impair system performance or cause it to fail.)

Stress testing — also known as fatigue testing — is meant to measure system performance outside of the parameters of normal working conditions. The software is given more users or transactions that can be handled. The goal of stress testing is to measure the software stability. At what point does software fail, and how does the software recover from failure?

Load testing - measures system performance as the workload increases. Stress testing - measure system performance outside of the parameters of normal working conditions. Spike testing - evaluates software performance when workloads are substantially increased quickly and repeatedly. Endurance testing - an evaluation of how software performs with a normal workload over an extended amount of time. Scalability testing - used to determine if software is effectively handling increasing workloads. Volume testing - determines how efficiently software performs with a large, projected amounts of data.