What kinds of software testing do you know? I've heard about Test-Driven Development, Unit tests etc, but can't understand their importance and difference. For example, why are we using regression tests or acceptance tests. What advantage they provide?
closed as not a real question by Martin Wickman, Walter, JeffO, Mark Trapp Jul 18 '11 at 20:55
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.
Regression testing is performed to ensure that new changes to a system didn't break any existing functionality that was not supposed to have been affected by the changes.
Acceptance testing is usually done by the customer/client/business users, it's often more high-level than other forms of testing and it's performed so that the people who requested the changes are happy with them and will allow you to promote the changes into your production system.
Broad categories to my mind would be:
Black box testing. You don't get to see the code and are just testing blindly to some extent as what is in the application or system is hidden from you. Thus in this case people don't know all the error cases and have to guess with various boundary conditions that may or may not be obvious to find all the cases.
White box testing. You do get to see the code and can verify what code pathways are being used so that code coverage could be used as a metric to ensure that all the logic is being used in the system. The idea here is to know what the code looks like to help guide the tests so that it isn't quite as mysterious as black box testing.
Gray box testing is a hybrid of the previous two.
Boundary cases tend to be something that one can see in white box testing as there are various conditions to see in the code that one writes tests to hit,e.g. if you had a program that asks for a number and someone enters X how this is handled should be seen somewhere in the code.
General classifications of testing would be:
Unit tests. These are generally the smallest tests that test something rather specific,e.g. does this method handle this boundary case? Note that dependency injection may be used here for cases involving mock objects to reduce any dependencies for the tests.
Integration tests. These are tests where a couple of components are connected and tests are run to ensure that the components do work together well. Note that while the unit tests may work independently, this is where the test of how well do things come together is done as there may be miscommunication between layers that cause these tests to be useful in catching various gotchas. The term End-to-End tests is used for integration tests where a full chain of components is tested from "one endpoint of the application to another" (whatever that means).
Regression tests. These would be tests done in the past that are done again to ensure that what was fixed is staying fixed and bugs aren't being re-introduced to the code.
Usability tests. These would be tests done to see how well can end users work with the software to complete various tasks. Where could something be automated to make something quicker or adjusting the UI so that something is easier to use.
User acceptance tests. These would be tests done by end users so that they can see first hand how something works and agree that the software does meet the business need that requested it in the first place.
Functional tests are all kind of tests based on the functional specification of the software under test. These are always black box tests.
Performance tests. These would be tests done to ensure a system can handle a certain amount of load without getting too slow. For example, testing out a new web farm of servers could handle 100 users hitting a site all at the same time would be an example of a performance test. These may also be called "load tests" or "stress tests" as generally the idea here is to either push the system to its limit or verify that the system can handle some projection from another department. The rationale for these tests is that often there are numerous configuration settings to optimize that can take more than a little work to discover bottlenecks and address issues with this. The bottleneck here could be memory, I/O, CPU or network bandwidth that causes the system to not be as responsive as expected. This generally requires tools on both simulating the load as well as monitoring the system to identify the bottlenecks.
Test Driven Development is a methodology and doesn't refer to a specific kind of test but rather that tests are written before the code so that the tests are what drives the development rather than behavior, domain, or feature being some other examples in terms of process.
Continuous Integration is a practice of running some tests such as unit, integration and regression tests regularly so that if a change breaks a test this is caught as early as possible.